Re: [LAD] [Jack-Devel] JACK & MIDI

On Fri, 2008-01-18 at 14:38 +0100, Pieter Palmers wrote:
> Fons Adriaensen wrote:
> > On Thu, Jan 17, 2008 at 11:13:10PM +0100, Julien Claassen wrote:
> >
> >> Why can't those people who discussed it here (Dave R., Fons and probably
> >> more - simply sit down and try to take as much as possible from the API - as
> >> it is - and try to work this new concept around it.
> >
> > Well, the two you mention have a long history of not having radically
> > different views... :-)
> >
> >
> > Seriously, there are three things that I profoundly dislike in MIDI.
> >
> > 1. The limited precision of almost all values, 7 bits or 14 with a
> > kludge (but even this kludge is not available in any standard
> > way for e.g. individual note frequencies).
> >
> > 2. Note events are identified by their frequency.
> >
> > 3. The only thing that can actually refer back to a note on event
> > is it's corresponding 'note off' message. It's not possible to
> > send a controller value that refers to a previous note-on event.
> >
> >
> > The worst result of all this, and what really drives me nuts is that
> > the same limits get built-in, carved in stone, into each and every
> > piece of sequencing software. They all perpetuate what is in fact
> > a form of cultural poverty "there's not quarter tones in pop music,
> > so they don't exist" while technically there is no more reason to
> > do so.
> >
> > Midi-over-jack has missed the chance to fix 1) which would have
> > been relatively easy. And even 2) and 3) are not so difficult to
> > get rid of.
>
> If someone comes up with a decent 'event protocol' I'm volunteer to
> implement it in jack, alongside the current jack-midi API (as an
> experimental feature). From an implementations perspective it's a
> no-brainer.
>
> But can someone please tell me what to implement. And not in a vague
> way. IMHO that's the real issue, and the 3 points you now mention are
> only the first steps along that path. Please don't stop there. Take the
> time to write a funded proposal that can be discussed, and then implemented.

I know this has been hashed to death but I agree with Fons and his
"cultural poverty" remark. How true. We got lucky with Jack, most
probably we are not going to get lucky a second time but we could
try :-)

Is there anything inherently wrong with OSC as a _transport_ protocol?
Anything that makes it unsuitable for that purpose within the framework
of jack? (I know there have been threads about this before)

If not, implementing it within jack would be a good first step. It would
then be easy (just kidding[1]) for all of us to agree on some added
semantics that would emulate the functionality of midi on top of it (ie:
a set of predetermined messages with known semantics). No need to even
reinvent the wheel, start of with SKINI for example[2] :-)

-- Fernando

[1] after all, lv2 was a piece of cake to get out the door!

[2] http://ccrma.stanford.edu/software/stk/skini.html

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Jan 19 04:15:02 2008