Subject: Re: [linux-audio-dev] alsa midi device name extension proposal.
From: Josh Green (jgreen_AT_users.sourceforge.net)
Date: Wed Mar 27 2002 - 23:42:17 EET
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:
>
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.
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.
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.
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
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.
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. 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.
Sorry about any ignorance of current projects, etc. I've been out of the
loop for a while. Cheers!
Josh Green
This archive was generated by hypermail 2b28 : Wed Mar 27 2002 - 23:41:40 EET