On Sun, 24 Mar 2002 01:35:18 +0100 stef <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel