Alsa MIDI device description extension proposal.

Alsa MIDI device description extension proposal.

[Juan Linietsky]

I have a proposal in mind, which should make much easier for programs to use the devices in a less-blind way, and standarize patch naming and device descriptions. I think it would be great if authors of existing apps have the chance to modify their programs to take advantage of this, saving us both users and programmers a lot of effort.

I really think this is a very important issue that hasnt been addressed,
And, if no one is interested in workig on this, I'd like to work on this myself, so i'll have the chance to learn.


----Proposal follows----

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 a sound
or bank, we have to yet again recreate the instrument definitions for
our sequencing apps.

To avoid this instrument naming madness, i propose to add an extension
to both the alsa user 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.

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, which alsa-lib will take care of, like for example:

djleet@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, and also ending up with a hundred of incompatible formats.


As I said before, this would be extensions to the current ALSA sequencer
system, so I think nothing should become incompatible with the current
alsa version.


thanks for reading this!

Juan Linietsky

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Alsa MIDI device description extension proposal.

[stef]

Nice idea, this could work for some preset synthesizers.
But it doesn't have to be part of Alsa.

For example i could write a midi driver for my
Waldorf Microwave. It opens all HW midi port(s), sends sysex
to detect/find the synth, loads all patch names from the unit
and creates extra Alsa midi ports for each voice.
If the unit is in multi mode, it will create the ports
'Micowave 1'..'Microwave 4'.

Midi communications to these ports will be routed to the
corresponding hw port and channel except a special
sysex, which allows the sequencer application to
get the patch list and to set a patch.

Of course it would be nice to have a generic synth driver,
which reads patch names from a file as you did describe,
but this should not be part of Alsa.

The only thing we have to standardize is the sysex to
request patch lists and to switch patches.

	-get patch list
	-set patch
	-refresh patch list from synth/file

Stef(an).



Juan Linietsky wrote:
> 
> I have a proposal in mind, which should make much easier for programs to use the devices in a less-blind way, and standarize patch naming and device descriptions. I think it would be great if authors of existing apps have the chance to modify their programs to take advantage of this, saving us both users and programmers a lot of effort.
> 
> I really think this is a very important issue that hasnt been addressed,
> And, if no one is interested in workig on this, I'd like to work on this myself, so i'll have the chance to learn.
> 
> ----Proposal follows----
> 
> 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 a sound
> or bank, we have to yet again recreate the instrument definitions for
> our sequencing apps.
> 
> To avoid this instrument naming madness, i propose to add an extension
> to both the alsa user 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.
> 
> 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, which alsa-lib will take care of, like for example:
> 
> djleet@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, and also ending up with a hundred of incompatible formats.
> 
> As I said before, this would be extensions to the current ALSA sequencer
> system, so I think nothing should become incompatible with the current
> alsa version.
> 
> thanks for reading this!
> 
> Juan Linietsky
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Alsa MIDI device description extension proposal.

[Juan Linietsky]

On Sun, 24 Mar 2002 01:35:18 +0100
stef <stef@hardco.de> wrote:

> Nice idea, this could work for some preset synthesizers.
> But it doesn't have to be part of Alsa.
> 

some preset synthetizers? not really. It would perfectly
work for any soundcard with internal synth (sound blaster awe, sblive, others?), alsa sequencer client programs (iiwusynth, timidity, saturno, others), and any external synth with either presets OR NOT. This is a BIG range of midi ports which could be used.

> For example i could write a midi driver for my
> Waldorf Microwave. It opens all HW midi port(s), sends sysex
> to detect/find the synth, loads all patch names from the unit
> and creates extra Alsa midi ports for each voice.
> If the unit is in multi mode, it will create the ports
> 'Micowave 1'..'Microwave 4'.

Yes, so whats the problem with it? you can still get patch names. Also, you're forgeting that 99.99% of the people wont do the approach you are doing, so it wont be as annoying to write patch definitions.

> 
> Midi communications to these ports will be routed to the
> corresponding hw port and channel except a special
> sysex, which allows the sequencer application to
> get the patch list and to set a patch.

i dont understand this, coud you please explain this better?


> 
> Of course it would be nice to have a generic synth driver,
> which reads patch names from a file as you did describe,
> but this should not be part of Alsa.

This _has_ to be part of alsa. I'm not just talking about a standard way of doing patch definitions, i'm talking about a standard way of polling for patch information. This has to be managed by drivers/modules transparently for the user. Think about someone writing with soundfonts using the sblive, sbawe, iiwusynth or timidity.  There is no patch definition file there, but there is patch names, bank info which the driver DOES KNOW about. But there is no way to retrieve this info from it.
Or think about using saturno, the alsa client dx7 emulator, which works by loading the dx7 sysex patches/banks. it does know about patches an names, but yet again the sequencing app has no way to retrieve this info. Now think this for all kind of drivers/sequecer clients that have this problem, and think how much programmer and user time can be saved if alsa can just have library calls for polling this?
Also I think this shouldnt be done with sysex calls, first because of the extreme annoyance of parsing, and second and mainly, because if the driver is only a bridge between an external device or a sequencer client, it has no right to interfere the communication between both capturing and sending propertary sysex messages that would ALSO slow down and mess the communication.



> 
> The only thing we have to standardize is the sysex to
> request patch lists and to switch patches.
> 
> 	-get patch list
> 	-set patch
> 	-refresh patch list from synth/file
> 
> Stef(an).
> 

Yet again, I think sysex is dumb, because of the above reasons. It's just annoying in any possible way. A library call plus driver support is simpler and cleaner for the developer and the user. Alsa sequencer does rock and it's extremely simple to use, and these are the main advantages. Implementing this functionality as sysex would really be a big annoyance.
And from what i know It's not more work for the library developing, A driver is not supposed to be forced to answer that IO call, if the driver
doesnt support it, will just return an error in the call, and alsa lib will take care of that.


regards.

Juan Linietsky

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Alsa MIDI device description extension proposal.

[Juan Linietsky]

> Yet again, I think sysex is dumb, because of the above reasons. It's just annoying in any possible way. A library call plus driver support is simpler and cleaner for the developer and the user. Alsa sequencer does rock and it's extremely simple to use, and these are the main advantages. Implementing this functionality as sysex would really be a big annoyance.
> And from what i know It's not more work for the library developing, A driver is not supposed to be forced to answer that IO call, if the driver
> doesnt support it, will just return an error in the call, and alsa lib will take care of that.
> 
> 

I think this wasnt clear enough, let me rephrase it better.

Sysex is basically meant for users, so using sysex brings the following problems:
-It's harder from the developer standpoint to do this, specially from their app. It's harder to code, much less abstracted (since he's not supposed to manage sysex code at driver level) Instead of just using a few simple library calls, he has to capture the input sysex calls, and parse it. And, also being myself such a fan of how clean the alsa sequencer api is, this would be torture ;). Also more annoying for driver developers
who instead of just sending the info, they have to encoding as sysex.
-It's useless for the user. This is not some kind of sysex you use to set patches or something like that. It's sysex for retrieving information that "interferes" with the normal way you communicate with the driver, so the user has access to things that there isnt any point in it having access to.

So, thats why I really think the sysex approach is overcomplicated, kills
the clean interface to the alsa sequencer, and since it's only for alsa,
it definitively has no point in being there. A library call is simpler to use, simpler to write, and fits much nicer with the overal sequencer api.

I know that probably many of you think this is not the right approach
just because of the fact that it hasnt been done before in audio APIs.
But this only because of midi limitations that no one attempted this.
It's only starting to be done recently, and one of the better examples
is Steimbergs VST and Sonar's DXi, which both finally allow for this

(Althought I dont like the way those apis work since they force you to run an instance of the program per channel)

All in all, i think this HAS to be a library call, it's not some extra useless thing, and I'm sure that any programmer of sequencer programs 
will like to make use of it, as much as users will like the result.
(And I'm telling you this from my perspective which is both user 
and app programmer)

regards

Juan Linietsky













> regards.
> 
> Juan Linietsky
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Alsa MIDI device description extension proposal.

[Juan Linietsky]

Oh, and you know what, I was so concentrated in my hate for sysex ;) that i just noticed that i forgot to write the most obvious point about why sysex is a no-go.

And this is basically, that what you propose would work like this:

sysex call to poll for bank description -> Midi Out
and later
Midi In <- patch listing

And this has a fatal flaw, which is basically, what i said in my first, mail... Midi is a 1-way protocol. Thus considering this, remember that 
not all deviecs have In/Out , in fact many of them are either midi IN only, and midi OUT only. Think about the sblive/awe synth, alsa sequencer clients, etc, are MIDI OUT ONLY, so it's not possible in any way to retrieve information from them via sysex.

regards

Juan Linietsky




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Alsa MIDI device description extension proposal.

[stef]

Juan Linietsky wrote:
> 
> On Sun, 24 Mar 2002 01:35:18 +0100
> stef <stef@hardco.de> wrote:
> 
> > Nice idea, this could work for some preset synthesizers.
> > But it doesn't have to be part of Alsa.
> 
> some preset synthetizers? not really. It would perfectly
> work for any soundcard with internal synth (sound blaster awe,
> sblive, others?), alsa sequencer client programs (iiwusynth,
> timidity, saturno, others), and any external synth with either
> presets OR NOT. This is a BIG range of midi ports which could be used.

> > For example i could write a midi driver for my
> > Waldorf Microwave. It opens all HW midi port(s), sends sysex
> > to detect/find the synth, loads all patch names from the unit
> > and creates extra Alsa midi ports for each voice.
> > If the unit is in multi mode, it will create the ports
> > 'Micowave 1'..'Microwave 4'.
> 
> Yes, so whats the problem with it? you can still get patch names.
> Also, you're forgeting that 99.99% of the people wont do the approach
> you are doing, so it wont be as annoying to write patch definitions.

No problem with this, except that i don't think it should be
implemented in Alsa.

> > Midi communications to these ports will be routed to the
> > corresponding hw port and channel except a special
> > sysex, which allows the sequencer application to
> > get the patch list and to set a patch.
> 
> i dont understand this, coud you please explain this better?

The driver (not part of Alsa but an application which uses
Alsa) sits in between the hardware midi port and offers
other midi ports to sequencer applications. The sequencer
simply uses the driver's midi port instead of the real
synth/soundcard hardware port.

'Patch list request' and 'set patch' sysex sent from the
sequencer app to the synth gets captured and answered
by the driver.

> > Of course it would be nice to have a generic synth driver,
> > which reads patch names from a file as you did describe,
> > but this should not be part of Alsa.
> 
> This _has_ to be part of alsa. I'm not just talking about a standard
> way of doing patch definitions, i'm talking about a standard way of polling for patch information. This has to be managed by drivers/modules transparently for the user. Think about someone writing with soundfonts using the sblive, sbawe, iiwusynth or timidity.  There is no patch definition file there, but there is patch names, bank info which the driver DOES KNOW about. But there is no way to retrieve this info from it.
> Or think about using saturno, the alsa client dx7 emulator, which works by loading the dx7 sysex patches/banks. it does know about patches an names, but yet again the sequencing app has no way to retrieve this info. Now think this for all kind of drivers/sequecer clients that have this problem, and think how much programmer and user time can be saved if alsa can just have library calls for polling this?
> Also I think this shouldnt be done with sysex calls, first because of the extreme annoyance of parsing, and second and mainly, because if the driver is only a bridge between an external device or a sequencer client, it has no right to interfere the communication between both capturing and sending propertary sysex messages that would ALSO slow down and mess the communication.

- sysex is made for such jobs.
- it's not slow because the sysex never hits a midi cable
- it's totally ok if the driver captures and sends its own sysex,
  because it's SYStem EXclusive for the driver. It even
  is allowed to filter its own sysex from going to the
  real synth, because it can be sure that the synth(s) will
  ignore it.

> And from what i know It's not more work for the library developing,
> A driver is not supposed to be forced to answer that IO call, if
> the driver doesnt support it, will just return an error in the
> call, and alsa lib will take care of that.

Right. If you're using sysex you have to wait for the driver to
respond. Timeout some milliseconds. And you have to deal with
sysex.

No problem for me, but as you sait, i'm one of the 0,001% of
Alsa users which use external synths.

Stef(an).

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Alsa MIDI device description extension proposal.

[stef]

Juan Linietsky wrote:
> 
> Oh, and you know what, I was so concentrated in my hate for
> sysex ;) that i just noticed that i forgot to write the most
> obvious point about why sysex is a no-go.
> 
> And this is basically, that what you propose would work like this:
> 
> sysex call to poll for bank description -> Midi Out
> and later
> Midi In <- patch listing
> 
> And this has a fatal flaw, which is basically, what i said in
> my first, mail... Midi is a 1-way protocol. Thus considering
> this, remember that not all deviecs have In/Out , in fact many
> of them are either midi IN only, and midi OUT only. Think
> about the sblive/awe synth, alsa sequencer clients, etc,
> are MIDI OUT ONLY, so it's not possible in any way to retrieve
> information from them via sysex.

No problem. If the connection to the hardware is IN only,
the driver can retrieve the patch list from a file.

The sysex discussion was about the connection
synth driver <-> sequencer app. So the port the driver
creates (and the seqencer uses) has to be bidirectional.

You don't have to retrieve sysex from the soundcard but from the
driver. There could be a 'generic' driver which answers
sysex requests from the sequencer app based on the contents of
a file, and maybe some synth specific drivers, which use
a bidirectional connection to the synth to retrieve patch lists.

The sequencer app doesn't have to deal with that difference.


Stef(an).

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: Alsa MIDI device description extension proposal.

[Juan Linietsky]

On Sun, 24 Mar 2002 13:22:21 +0100
stef <stef@hardco.de> wrote:

> Juan Linietsky wrote:
> > 
> > Oh, and you know what, I was so concentrated in my hate for
> > sysex ;) that i just noticed that i forgot to write the most
> > obvious point about why sysex is a no-go.
> > 
> > And this is basically, that what you propose would work like this:
> > 
> > sysex call to poll for bank description -> Midi Out
> > and later
> > Midi In <- patch listing
> > 
> > And this has a fatal flaw, which is basically, what i said in
> > my first, mail... Midi is a 1-way protocol. Thus considering
> > this, remember that not all deviecs have In/Out , in fact many
> > of them are either midi IN only, and midi OUT only. Think
> > about the sblive/awe synth, alsa sequencer clients, etc,
> > are MIDI OUT ONLY, so it's not possible in any way to retrieve
> > information from them via sysex.
> 
> No problem. If the connection to the hardware is IN only,
> the driver can retrieve the patch list from a file.
> 
> The sysex discussion was about the connection
> synth driver <-> sequencer app. So the port the driver
> creates (and the seqencer uses) has to be bidirectional.
> 
> You don't have to retrieve sysex from the soundcard but from the
> driver. There could be a 'generic' driver which answers
> sysex requests from the sequencer app based on the contents of
> a file, and maybe some synth specific drivers, which use
> a bidirectional connection to the synth to retrieve patch lists.
> 
> The sequencer app doesn't have to deal with that difference.
> 

Yes, but then again, what i'm saying is that in a lot of cases you dont have that. My main point is that you will have to use a patch definition file ONLY when the driver doesnt support sending you patch names (which happens, as you said, if we're talking about a bridge midi port which connects to external harware). In _other cases_ such as soundcard synths, or software synths running as sequencer client, the driver/app itself is able to give you the patch/bank information directly, so there's no point in reading them from a file. Lets say that you are using a sound blaster live. You go and type:

sfxload mysoundfont.sf2

Which uploads the patches to the soundcard using snd-synth-emu10k1 driver.
the patch names are inside of the .sf2 archive, and are uploaded to the card together with the sampledata. The driver has the patch names and the banks, so, how would you retrieve them? see how nothing except a library call is an option. Sysex will simply not work, because this device is midi out only. A patch definition file would be retarded since not only the driver has all the info, but you can contantly be changing soundfonts every time you're going to compose, so writing a patch defintion file out of a soundfont every time you get one is just very annoying. Not to mention all kind of other sequencer clients. Lets say I'm using rx/saturno (the yamaha dx7 emulator), which connects through sequencer client api. 
It proovides a midi out port for apps, but not midi in. And Lets say I
keep loading hundreds of different d7x patches. Converting them to ALSO patch file definitions is annoynig, and this follows for any existing app and any app to be written. It's just annoying.
So as you see, sequencer client apps proovide a midi out port only. to add support for sysex, both squencer client and squencer app mantainers will be forced to add port reading/writing in the inverse direction only to retrieve patch names, which i think goes beyond the line of annoyance.
And what about those multiplexer boxes that give you 5 midi outs and no midi in? even for external synths.. you wont be able to use the bidi connection to retrieve patch names.

All this could be easily done with just a library call and support for it in the drivers/sequencer client apps. It's much nicer to use for the programmers, much cleaner as implementation, and will allways work whathever the case is. So why not doing a midi library call?
Being that case that we're talking about alsa, i think it's simpler
overall to do it this way, instead of having to resort to sysex, which is a hack to overcome the limitations of a braindead and obsolete protocol such as MIDI is.


      
regards

Juan Linietsky