On Saturday 07 January 2012, Dan Muresan wrote:
> The decision about using one MIDI API or another,
one GUI framework or
> another, one programming language or another, in my case depends only on
> I find the best suitable tools for a task. I
can't care less about the
the most popular thing, because in that case I would not be
If you're writing for yourself only, no one can argue with that; but I
was talking about public-facing apps, in which case standardizing on a
single MIDI protocol helps users (and the ecosystem in general).
Well, I publish some of my programs with free software licenses, so they may
be used by anyone interested. But yes, I write for myself in the first place.
At least I don't work for you.
You are wrong about another thing: the MIDI protocol is the standard to
follow, as it is defined by www.midi.org
. ALSA implemented this standard long
time ago, like other frameworks did before. Linux already had MIDI APIs
following the standard long before Jack MIDI arrived bringing more
fragmentation to the (already weak) Linux ecosystem.
I've always thought that Jack MIDI is easier to
program and provides
better jitter guarantees, but you may see things differently.
It is designed to subordinate MIDI messages to digital audio in real time. For
these use cases it may fit well. Pretending that it fulfills the needs of any
other use case where MIDI may be involved is only hype and propaganda.
> writing Linux applications. You know: Linux usage
is absolutely marginal,
> among musicians and audio professionals. I find
Jack MIDI unsuitable for
use cases, so
I usually don't use it.
It would be interesting to know which use cases you are encountering?
Except one program (VMPK) that uses RtMIDI so it supports Jack MIDI, all my
other programs use ALSA sequencer for features that Jack MIDI don't provide
any facility. Of course, I may implement anything needed from scratch, but I
refuse to do so. I prefer to invest my time in other more productive tasks.