12 May
2010
12 May
'10
5:59 p.m.
On Wed, May 12, 2010 at 11:54 AM, Pedro Lopez-Cabanillas <
pedro.lopez.cabanillas(a)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