5 Mar
2012
5 Mar
'12
2:17 a.m.
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.