On Mon, Feb 22, 2010 at 6:11 PM, <[email protected]> wrote: > On Mon, Feb 22, 2010 at 06:06:55PM -0500, Paul Davis wrote: > >> >> But why is your app giving midi-ports both for jack and >> >> alsa at the same time? >> > >> > Why not? I think that doing this actually serves users >> > better, especially since JACK MIDI adoption is still on the >> > up-swing. >> >> 1) it makes the app quite a bit more complex >> 2) it introduces yet another name mapping scheme from ALSA<->JACK >> 3) its a job best left for specialized clients like a2jmidid >> 4) it makes it harder to write an app that can be used with or without JACK > > Aeolus also provides both when used in Jack mode. > As regards (1), it's mainly the Jack interface that > complicates things as many of the MIDI messages can't > be handled in the process callback.
my experience with ardour3 tells me this: JACK MIDI and ALSA MIDI are opposites in this respect: * ALSA MIDI is fundamentally poor for realtime MIDI driven synthesis and parameter control BUT very convenient for system control * JACK MIDI is very inconvenient for system control but fundamentally good for realtime MIDI driven synthesis and parameter control we've adopted some relatively simple designs in a3 that make JACK MIDI ports *not* being used for RT synthesis etc look (API-wise) pretty much like an ALSA MIDI port (by interposing a FIFO between the process callback and everything else) i don't really see too many ways out of this dilemma. injecting information into a JACK client (or any piece of software really) that is intended for use in an RT-constrained piece of code is really so different than injecting it for non-RT purposes that i don't think there is a way to just get the best of both worlds with no effort. --p _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
