Paul Davis wrote:
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.
Well, actually OSC uses a server/client model (at least the OSC apps I
know do). In any case, OSC clients just connect to servers, and that
server might well be Jack. OSC servers like SC3 would have to adapted,
though, that's true.
But first and foremost, OSC is just a way to cram data with attached
type information into a buffer, so, as Dave already pointed out, you can
just ignore the transport layer and provide your own API instead. Audio
applications also need to be Jack'ified to work with Jack after all...
What jack could maybe do, in addition to provide a transport mechanism
for both OSC and MIDI, is to allow connections between MIDI and OSC and
do the translation on the fly (using some set of MIDI-over-OSC
messages). That would be cool. Jack'ified apps could then just happily
use OSC as their control protocol and never worry about MIDI any more. I
don't know whether it's practical to add that functionality to Jack;
otherwise there could be a Jack client doing that kind of thing.
Also, implementing something like OSC in Jack would vastly expand its
scope. Want to process sensor data from your Gizmo ABC(TM) measuring
equipment or your brandnew "I Robot" Mark II vacuum cleaner? Sure, why
not, just write a Jack client which reads the data and translates it to
OSC, now you can pipe it into any Jack application, maybe via another
Jack client which does the necessary controller mapping. This might
sound like a pipedream now, but with cpu speeds always on the rise and
manycores in every PC soon the processing power will be there.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW:
http://www.musikinformatik.uni-mainz.de/ag