On Wed, May 12, 2010 at 11:54 AM, Pedro Lopez-Cabanillas
<pedro.lopez.cabanillas@gmail.com> wrote:
The ALSA sequencer API may be implemented in user space, offering a way to
existing applications to be used with the new sequencer in a transparent way.
That would be nice and consistent with our (Linux audio users) priced freedom
of choice. I know that it is not the easy path, but would be consistent with
the efforts of the ALSA people providing an OSSv3 compatibility API.
which probably fucked up linux audio more than anything else for the last 10 years.
Not only that, but Jack MIDI forces to the MIDI applications to always be used
subordinated to an audio stream. Even when you don't want to use digital
audio at all, because your MIDI sources and receivers are all external
musical instruments.
that's an artifact. for now, just run jackd -d dummy and fire up a2jmidid -e. no audio is flowing anywhere at all.
Another drawback is that if you want to succeed replacing an existing API, you
need to provide at least every functionality provided by the old one, and do
it in a nice way that can be adopted easily by the developers. I understand
that the ALSA sequencer API is huge and cumbersome, but the minimalist
approach of Jack MIDI may be just another mistake in the opposite direction.
if you can expand on what that direction might be, it could be useful.
there are issues that i have with the JACK MIDI concept, but they are clear and simple (and the diametric opposite of those with ALSA sequencer). specifically:
* ALSA sequencer is bad for synthesis because data arrives in the wrong thread at the wrong time; its good for MIDI control because the data does not arrive
in the RT process() thread
* JACK MIDI is good for synthesis because data arrives in the right thread at the right time; its bad for MIDI control because the data arrives in the
RT process() thread