[linux-audio-dev] alsa midi device name extension proposal.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] alsa midi device name extension proposal.
From: Juan Linietsky (coding_AT_reduz.com.ar)
Date: Wed Mar 27 2002 - 07:29:19 EET


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:

djleet_AT_myworkstation:/etc/alsa/definitions$ vi my_trance_machine.def

device {

        name = " r0x0r tranc3m4chine "
        port = "MIDI 0-1"

}

bank {

        name = "rezocool phasers"

        msb = 31
        lsb = 22

        patch_1 = " super acid pad "
        patch_2 = " cool juicy 303 thing "
        patch_2_control_default = 55,20
        patch_3 = " temple of doom "

}

bank {

        name "basses"

        msb = 32
        lsb = 22

        patch_1 = " super six poles filtered FM bass "
        patch 2 = " pick bass "

}

etc.

---

This should basically avoid us users and programmers to do all this work from the sequencer program side.

----FAQ-----

After some discussions on certain points with different people, i'm adding this faq with the hopes that can answer some questions or arguments about this:

Question: What is the scope of this implementation? Answer: this is much simpler than what most think, mainly, retrieving names of patches, banks and controllers from a device. And retrieving only.

Question: dont you think this is too complicated because of the amount of different synths/cards/programs around? Answer: No, since all this is standarized: banks are set using controllers 0/32.

Question: wouldnt this break compatibility in alsa? Answer: technically, it shouldnt since this is purely extensions.

Question: Why do you insist in modifying the api? cant this be done using MIDI SYSEX commands? Answer: This cant and shouldnt be done with sysex for a number of reasons, first because of uglyness (sysex is ugly;) and conflicts with the idea of device sharing, but the real reason is that midi is not a 2-way protocol, thus most devices, specially soundcard drivers for internal synths or sequencer clients only work 1-way and there's not an incoming midi connection from them. And creating one just for the sake of retrieving this information is just horrible. A simple api call should give you the data you want and will work in all cases.

Question: Is this worth it? Is doing this useful? Answer: I think that definitively yes, since this has been one of the biggest problems with midi since we started using it for composing in computers. There is not any way to know the names of a device if it's not compilant with general midi. MIDI will never support this, and the only way to get around this limitation for us is from the OS api itself.

Well, i'd like to hear what you people think.

thanks for reading this!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Mar 27 2002 - 07:15:16 EET