[LAD] [ANN] Qtractor 0.5.4 - Echo Victor shouts out!

[David Robillard]

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.