From alsa-devel-owner@alsa.jcu.cz  Tue Feb  9 17:14:05 1999
Received: from thudson1.cygnus.com (thudson1.cygnus.com [205.226.144.45])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id RAA04021
	for <alsa-devel@alsa.jcu.cz>; Tue, 9 Feb 1999 17:12:22 +0100
Received: from cygnus.com (thudson@localhost [127.0.0.1])
	by thudson1.cygnus.com (8.8.7/8.8.7) with ESMTP id UAA15993
	for <alsa-devel@alsa.jcu.cz>; Mon, 8 Feb 1999 20:32:43 -0500
Message-ID: <36BF903B.1CADC0D3@cygnus.com>
Date: Mon, 08 Feb 1999 20:32:43 -0500
From: Thomas Hudson <thudson@cygnus.com>
MIME-Version: 1.0
To: alsa-devel@alsa.jcu.cz
Subject: Re: MIDI / Sequencer stuff (was:Re: Writing Article Re: Linux audio)
References: <199902090014.BAA05265@obelix.vande-pol.demon.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Frank van de Pol wrote:
> An ability to name individual channels would help for those who have a setup
> with daisy chained devices.
> 
Yes. This was what I had in mind. I've just been toying with the idea of
a high-level C++ interface sitting on top of ALSA seq. If I fire up a
SysEx Editor Librarian for my TSR24, it would be nice for it to query
for the port and channel that the device lives at, without having to
send the sysex to every port.

In addition, for a MIDI sequencer, instead of each track having a box
to select port and another for channel, I would prefer it simply had
a combobox to select named channels:

+-----------------+---+
|  TSR-24         | V |
+-----------------+---+
|  E64 Channel 1      |
|  E64 Channel 2      |
|  ...                |
|  E64 Channel 16     |
|  JMP-1              |
|  Mixer 7            |
|  GR50 Channel 1     |
|  ...                |
|  GR50 Channel 5     |
+---------------------+

This is more intuitive since each track typically is associated with a
single channel.


> It will still be very important for an musician to know that devices are
> daisy chained to the same midi buss, as sending eg. program changes might
> otherwise affect other devices than the one the messages were intented for.
> Example: if I send a pgm change to my Bassstation, and my patchbay is not
> setup correctly, I also see my reverb unit reacting to those messages :-(
>
Yes. This is why I wrote controller code for my rather dumb patch bay.
An 
application should say "I want to send a program change to the
Bassstation",
rather than "I want to send a program change down channel 3 of port 2"

This allows intelligent code downstream to actually first send a sysex
to
the patchbay before sending the program change.

> > I have been playing with designs for a universal sysex editor plugin.
> > Perhaps
> > this plugin should be responsible for giving names. I limited
> > implementation
> > might only read this from a file, whereas a full-blown implementation
> > would
> > request this info from the device.
> 
> Looking forward for your implementation / prototype :-)
> 
How adverse is everyone to having this implemented in C++? My original
design revolved around a set of abstract interfaces. The object would
inherit and implement the interfaces that it supported. For example,
a device capable of receiving and responding to program changes
might implement:

class Patchable
{
  int GetPatchCount() = 0;
  int SetCurrentPatch() = 0;
  nit GetCurrentPatch() = 0;
  vector<string> GetPatchNames() = 0;
  int GetPatchName(int patch_number) = 0;
};

Of course, in my design, a mulitimbral device, i.e. a device that can
respond independently on several channels, would have a controlling
object for each channel. Perhaps this isn't the best approach, instead:

class Patchable
{
  int NumberOfChannels() = 0;
  int GetPatchCount() = 0;
  int SetCurrentPatch(int channel) = 0;
  int GetCurrentPatch(int channel) = 0;
  vector<string> GetPatchNames() = 0;
  int GetPatchName(int patch_number) = 0; 
};

My patchbay is sort of a strange creature in that it is both a MIDI
patchbay and an audio patch bay. It has 50 presets for the MIDI
patchbay and 50 for the audio. That's why I had originally split
things up. In hindsight though, this is not the norm. I vast majority
of synths have the same patch names for every channel.

Lately I've been looking at the MIDI Kit that comes with the BeOS. I
wonder if it would be worthwhile to do an implementation on top of
ALSA. BeOS is getting some commitment from the music industry. If
common interfaces existed it might mean more support for Linux.

> >
> > > Problem is that to get full support for a certain device we need something
> > > specific (eg. a daemon program) for this device; there are VERY MANY
> > > devices... So to do this good it would be an absurd amount of work! (Hmmm, I
> > > get the feeling we are reinventing a wheel....)
> > >
> > I've been trying to design my sysex editor plugin so that a programmer
> > could decide to implement only a bare minimum, perhaps just "give patch
> > names" and "set current patch." This way each device handler could be
> > developed incrementally. Also, if you look at the SysEx implementation
> > for a particular company, for example Emu, a single plugin would work
> > for all of their Proteus series, including the Morpheus and quite a few
> > of their samplers.
> 
> Agreed, but still very much work...
> 
Yes. Hopefully if the minimal was easy more and more people would be
inclined
to contribute. I've also considered writing a parser for one of the
commercial
Editor/Librarian device description file formats. 
> >
> > One feature that would nice is the ability of some plugin code to be
> > statically
> > registered with a port. For example, in my setup:
> ...
> In your case I'd recommend to write a (simple) ALSA driver (client) which
> provides 8 input ports, and sends events received from these ports to that
> "mqx-32 port-2" interface. And have this driver insert sysex once you switch
> to another device. This can be done perfectly with the ALSA sequencer in
> it's current state.
> ...

Yes. This is exactly what I want to do. But I want my client to be
invoked
any time an application opens an ALSA port. Is this possible? If a user
starts up a MIDI sequencer, before (or when) it queries for available
ports,
I want my client invoked to it can provide those eight virtual ports to
the application.

Thomas

