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: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW: http://www.musikinformatik.uni-mainz.de/ag _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
