[LV2] Mapping of OSC to LV2 Atoms
d at drobilla.net
Fri Oct 23 07:59:15 PDT 2015
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:
> >>> How do you propose "/foo tf" be represented as an atom?
> >> As Proposed by Hanspeter:
> >>> LV2_Atom_Object (object.otype=LV2_OSC__Message)
> >>> key=LV2_OSC__messagePath (value.type=LV2_Atom_String)
> >>> key=LV2_OSC__messageFormat (value.type=LV2_Atom_String)
> >>> key=LV2_OSC__messageArguments (value.type=LV2_Atom_Tuple)
> >> LV2_OSC__messagePath = "/foo"
> >> LV2_OSC__messageFormat = "tf"
> >> LV2_OSC__messageArguments would either be an empty tuple or omitted I
> >> suppose.
> >> The idea is more to encapsulate the OSC message rather than just represent
> >> that same data as atoms. If I understand correctly, that is.
> > Might as well just literally use OSC if code making any sense of it
> > would need to be OSC-specific anyway.
> > But this is so close, yet so far. Almost a sensible stand-alone tuple
> > of the message arguments, but not quite because some are omitted because
> > OSC is weird, and you get a (almost completely redundant) format string
> > instead. That seems silly to me.
> > Personally, I think there's two good approaches here:
> > 1) Go all out: full conversion to tidy atoms that have no OSC cruft
> > whatsoever.
> > 2) Don't go at all: just use actual OSC bundles and messages.
> > Anything in the middle seems weird.
> Raw OSC would have the advantage of being more compact memory-wise, but
> would require byte-swapping. I would not want to bet whether one is more
> 'efficient' than the other.
I'd probably define osc:OSCMessage or whatever to be "OSC, except in
native host byte order" (perhaps a type for both if we actually need
that). Clearly plugins converting to network byte order and back for
output (when that output is likely to be connected directly to another
plugin that's just going to flip it back again) is nuts.
> I agree with the 'all or nothing' and am in favor of 1: let us use atoms.
> The initially proposed LV2_OSC__messageFormat property thus is not
> needed any longer.
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.
Though... part of me wants to *not* introduce a native OSC message type,
since this encourages plugins to use OSC for their interfaces and not
LV2's native format (atoms) which we have all this infrastructure for.
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. 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. Such a thing could be integrated into lilv,
but if we want dynamic bindings it all becomes quite a bit more
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.
More information about the Devel