[LAD] [Jack-Devel] JACK & MIDI

[Dave Robillard]

On Fri, 2008-01-18 at 12:58 -0500, Paul Davis wrote:
> On Fri, 2008-01-18 at 09:37 -0800, Fernando Lopez-Lezcano wrote:
> 
> > 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)
> 
> OSC is not a bus-oriented protocol, its 100% point-to-point. That is,
> you do not put messages on a bus and all listeners pick it up. You have
> to explicitly dispatch each OSC message to each target. this makes it
> fundamentally different from MIDI, which, independent of the actual
> physical transport layer, is bus oriented.

This is simply not true (I know who convinced you of this, because he
tried to convince me too, but I actually read the spec ;) )

There's no reason not to truck around OSC messages just like MIDI
messages, semantics are a separate issue (that is a "problem" with OSC
no matter how you transport it).  That is, the problem you are
describing is just as present with OSC via UDP as via Jack.

Standard for messages (ie /note_on) are the solution to this, and are
also transport agnostic.

If you read the OSC specification, it very precisely defines exactly
what a message is as a sequence of bytes (ditto bundles).  It also says
absolutely nothing about /requiring/ messages be sent around in packet
based addressed protocols like UDP (namely because this is silly, and
would violate the hell out of the network layer model).

The messages themselves are quite good as a generic message system.
Simple, flexible, has several types you can use as arguments (including
several floating point formats), and you can even easily extend it with
new types (which the main spec document does itself, only 4 are truly
"standard" OSC types).
 
When anyone talks about OSC in Jack, what they really mean is
transporting "OSC Messages" in Jack, and there's no problem with that.

-DR-

P.S. OSC messages are an awful lot like D-Bus messages, if anyone cares.
(/paths/like/this "with" 1.0 "whatever" 5 "arguments") is a natural
message format, if we reinvented it (just because a particular developer
likes TCP/IP too much) we'd be reinventing the exact same thing except
by a different name, completely unknown, and slightly incompatible.  I
hope it's obvious that this is.... less than wise