On Mon, 2012-03-05 at 09:40 +0900, michael noble wrote: [...] > I'm chiming in late here, but it is a topic I've thought about a > little having experimented in the domain. Given the open-endedness of > OSC, I've always thought it makes more sense to implement some kind of > plugin based translators, as it were, something like the ladosc ladspa > plugins but with more flexibility and eliminating the need for both a > sender and receiver plugin. > > For instance, if one were to implement an LV2 OSC instrument, you > automatically get multi-host compatibility without having to expect > the host dev's to agree on a standard as such. The plugin would simply > need some kind of sensible interface to define namespaces for the > translated midi events that the host would be sending to the plugin > via the standard sequencer interface. This way, discrete and > continuous events could be mapped to OSC output within the UI of the > plugin. I hope I'm making sense.
I don't really grasp what you're getting at here, or what MIDI has to do with it, etc. However, using plugins to process/filter/whatever OSC messages is natural (same thing for Jack apps). You can use any event types in LV2. What you'd need to work with OSC in plugins is a simple implementation capable of reading and writing OSC messages in realtime. Liblo is too heavy for that. Reading is probably easy. Writing is a bit trickier, I struggled with inventing a decent API for a similar thing (LV2 atoms, not OSC, but same idea), but eventually arrived at an "append-based" API which works pretty well. I call this the "forge" API for atoms. A similar scheme could work for OSC, e.g hard real-time code to write the message "/foo/bar if 1 3.0" could look something like: OSC_Forge forge; osc_forge_set_output(output_butter, n_bytes); OSC_Msg msg; osc_forge_msg_start(&msg, "/foo/bar"); osc_forge_int(1); osc_forge_float(3.0); osc_forge_msg_finish(msg) One unfortunate thing with OSC is the size of the type string must be known in advance[1], so you might have to pass that to osc_forge_msg. Nesting (bundles) can be handled automagically, the forge maintains a stack (without allocating, of course). Such a thing can be implemented in a single smallish header. I think a very simple stand-alone API to deal with OSC message would go a long way towards making OSC more feasible for plugins or Jack apps. -dr [1] I consider this a mistake in OSC. The type tag should precede each argument so messages can be built sequentially by simply appending successive arguments. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
