On 27 Mar 2002 14:42:17 -0700 Josh Green <[EMAIL PROTECTED]> 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
