[LV2] Mapping of OSC to LV2 Atoms

[Hanspeter Portner]

On 23.10.2015 16:59, David Robillard wrote:
> On Tue, 2015-10-20 at 17:40 +0200, Hanspeter Portner wrote:
>> On 17.10.2015 05:42, David Robillard wrote:
>>> On Thu, 2015-10-15 at 17:41 -0600, Spencer Jackson wrote:
>>>> On Thu, Oct 15, 2015 at 5:17 PM, David Robillard <d at drobilla.net> wrote:
> I agree in terms of the transformation, but a native OSC message type
> would still be nice.  My personal ideal is that I can use the stuff
> defined by this extension as my sole OSC implementation, and just deal
> with the network side of things in the host.

I see. I'm taking a different route here, by implementing the
network/serial side of things inside a plugin [0] which can be loaded
into any existing host. That is the main reason I opt for an atomey-only
representation, as hosts with support for atom object/events would need
no/little change to support OSC.

> This ties in with what I have been working on / thinking about lately,
> which is event-based control in general.  We want to support numerous
> protocols (MIDI and OSC in particular), but having plugins implement a
> mish-mash of them would be a complete mess.

I fully agree.

> An abstraction which lets
> plugins only deal with one things (LV2 parameters controlled by atoms),
> yet makes it easy for hosts (or whatever) to control those plugins from
> MIDI and OSC would be nice.

I fully agree.

It makes not much sense to have three subsystems (parameters, MIDI, OSC)
to achieve similar things. Plugins ideally should just use the native
(and most powerful) one (e.g. parameters via atom events).

I mainly think of MIDI and OSC as a means to link a host/synth to
peripherals/control surfaces/sensors/actuators/sequencers/... (the
things that do not talk atoms).

Using OSC to build custom APIs for a synth plugin (à la SuperCollider)
was not my intention at all for the extension. The LV2:patch extension
is much more capable to achieve such kind of things and should thus be
preferred.

> Such a thing could be integrated into lilv,
> but if we want dynamic bindings it all becomes quite a bit more
> complex...

That's kind of what I had in mind with this extension. But instead of
putting such 'bindings' into lilv I'd rather implement them as plugins
themselves (but one thus not exclude the other).

OSC-peripheral
 |
HOST
   |
  OSC-Atom binding plugin
   ||
  Synth plugin A
    |
  Effect plugin B

MIDI-peripheral
 |
HOST
   |
  MIDI-Atom binding plugin
   ||
  Synth plugin A
    |
  Effect plugin B

I have an experimental plugin that acts as an automatic bridge between
OSC<->LV2:patch [1]. Paired with a host which has experimental support
for dynamic parameter discovery [2], I get automagic bidirectional GUI
control [3] for a plain OSC peripheral for free without the LV2 host
knowing any OSC at all (the work is done by the plugin). The host
*needs* to support dynamic parameters (via patch:Patch, patch:Get,
patch:Set) for that to work, though.

Such bindings are definitely doable with the LV2:patch extension.

My take at dynamic/advanced bindings is realtime event scripting, again
implemented as a plugin [4]. That's definitely not everyones piece of
cake, but it's the right tool for the things I'm interested in.

*Disclaimer* I obviously am in favor of a modular approach, which works
well for non-linear hosts à la ingen, maybe not so well for linear
host/DAWs.

> 
> Getting tangential here to some degree, but if we're going to jump on
> the OSC bandwagon, it's worth some thought how LV2 can best deal with
> numerous control protocols without making things any more of a nightmare
> for plugin and host authors than they already are.

Fair enough.

[0]
https://github.com/OpenMusicKontrollers/eteroj.lv2/blob/master/eteroj_io.c
[1]
https://github.com/OpenMusicKontrollers/eteroj.lv2/blob/master/eteroj_query.c
[2] https://github.com/OpenMusicKontrollers/synthpod
[3] https://dl.dropboxusercontent.com/u/46882396/synthpod_eteroj%23query.png
[4] https://github.com/OpenMusicKontrollers/moony.lv2