[LV2] Mapping of OSC to LV2 Atoms

[Hanspeter Portner]

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 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.