22 Feb
2010
22 Feb
'10
8:50 p.m.
On Mon, Feb 22, 2010 at 6:11 PM, <fons(a)kokkinizita.net> wrote:
On Mon, Feb 22, 2010 at 06:06:55PM -0500, Paul Davis
wrote:
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
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.