Subject: Re: [linux-audio-dev] alsa midi device name extension proposal.
From: Juan Linietsky (coding_AT_reduz.com.ar)
Date: Mon Apr 01 2002 - 07:21:24 EEST
On 27 Mar 2002 14:42:17 -0700
Josh Green <jgreen_AT_users.sourceforge.net> wrote:
> On Tue, 2002-03-26 at 22:29, Juan Linietsky wrote:
> > Hello! i came up with this proposal for expanding the alsa midi api to
> > support retrieving info regarding to patches/banks/controllers, It's been going around some devel/user lists and some people, and i'm trying to gather as much info and feedback as i can make this proposal more solid and consistent.
> >
> > The following is the proposal----
> >
> > Basically, the idea is this, since midi is by default a 1-way protocol, there's no standard way to retrieve info from a device, this means that if we do have a midi port, we have no standard way to know which banks does it have or the names of the patches. The only work around to this, in midi sequencing programs is to create propertary (to the program itself) files describing the patch layout. This is very annoying when we, for example, use some external synth and we have to create all the sample definitions for a program, or when we use a soundfont and we have to manually create the definitions to each instrument, when it comes in the soundfont itself!
> > Or if we use some random sofstynth and we get to create some neat sound
> > or bank, we have to yet again recreate the instrument definitions.
> >
> > To avoid this instrument naming madness, i propose to add an extension
> > to both the alsalib sequencer interface, driver interface, and sequencer client inerface which could work this way:
> >
> > from the program side:
> >
> > -ability to poll the midi port for amount of banks and their parameters (or default bank if no banks).
> > -ability to poll for patch names in a bank
> > -ability to poll the midi port for rynth channels/patches (default is channel 10, i know, but some synths use channel 16 or more than one rynth channel), or to poll if a certain patch number is a rythm patch (some synths use a certain patch number for the drums)
> > -ability to poll for changes in the devices (or a callback manybe?) so they can be retrieved and updated
> > -ability to poll DEFAULT VALUES of patches (such as controller values, poly/mono, portamento, sustain, expression, volume etc) which the patch
> > sets to when selected. This is extremely useful in external synth modules/keyboards.
> > -ability to poll for controller names (most devices use some custom controlers for different things)
> >
> > from driver/synth client side:
> >
> > -if the driver supports it (such as, for exampe, a sblive or sbawe, opl3 (sbi loading), or alike, or a sequencer client which can hold the patch names itself, such as timidity, saturno, iiwusynth, smurf, etc then the driver itself will take care of answering the client request.
> > -if the driver doesnt support this, (for example, an external midi uart)
> > then it should be possible to create a STANDARD instrument definition file for this device, like for example:
> >
>
Hey josh! it's been a while!
> I'm also very interested in this topic. I've been developing a library
> called libsoundfont for some time to deal with loading, saving and
> manipulation of sound fonts. The idea being that it could be used for
> programs to share a common API in dealing with instrument patches. It
> isn't really there yet and I could use some help. Part of the project
> will be to add a protocol for manipulating a sound font between clients.
> This includes querying information about it.
This is cool, althought i think the instrument/patch retrieving should be done via the alsa sequencer api, so it remains compatible with everything else. Still, i think a libsoundfont would also be great to add native support of soundfont loading in alsa (instead of using sfxload which needs OSS compatibility and is bound to OSS limitations).
> Of course a simpler protocol could be used that would just allow
> querying preset names and current control values of a MIDI channel. This
> might fit more in line with what you are talking about. I would still
> like to see something like this brought about as it would help with
> communication between Swami (was Smurf) and MIDI sequencers.
>
Yes that would be great. Actually, if you have some time (and I dont have much either) we could work on these aditions to the alsa api.
> So I guess the real question is as to whether it should be something
> added to ALSA or another library (like libsoundfont). It would seem like
> it might make the most sense to be an ALSA standard.
Yes, I think it has to be an ALSA standard, basically, because of the importance of it, and because ALSA _is_ lacking this, having to resort to sfxload.
> To keep it as simple and generic as possible (summarizing some of what
> you said):
>
> 1. Querying of instruments (name, bank and preset #)
> - iteration functions
> - find by bank:preset or name
I think the api calls should be basically:
-Query a bank list from a device
-Query a patch list from a bank
> 2. Querying of controls (names, value types, valid value ranges)
> - iteration functions
> - A control ID or other unique identifier for direct manipulation
> - Not just for MIDI custom controllers but any generic control
> using an already defined data type.
>
I think it should definitively default to
-querying a controller name list from a device
-query default controllers from a patch
At least for now, in a future, when the above is working, it could be expanded to work with other kind of setups...
> It seems like a lot of what is missing (I'm sure this topic has been
> beaten to death in regards to LADSPA, sorry if I'm repeating what has
> already been discussed, etc) is of a generic control interface. I still
> think a good generic control setting/querying interface is needed.
Me too, but i wish we could just think about this after dealing with the sample naming issues, which is already a standard.
> Has
> someone come up with something like this yet (Paul? Weren't you working
> on a project in conjunction with LADSPA to handle control stuff?) I'm
> talking about a dynamic data type system similar to GTK (or GObject)
> that allows for giving control values a specific data type (float,
> integer, string, array of another type, etc) and its valid ranges (0.0 -
> 1024.0, 1-5, 20 characters, etc). Perhaps a version number could be kept
> and revised for what data types are defined. Or maybe a way to query if
> a particular data type is supported. This would allow for a somewhat
> expandable control data type system.
This sucks because of the existence of QT and GTK ;) As much as i'd rather to use GTK, which is also way more popular than QT, the poor KDE users wont like using some alien-looking widgetset!
regards
Juan Linietsky
This archive was generated by hypermail 2b28 : Mon Apr 01 2002 - 07:07:26 EEST