linuxaudio.org

On Mon, 2012-03-05 at 09:40 +0900, michael noble wrote:

[...]

quoted text
> 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

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev