[LV2] Mapping of OSC to LV2 Atoms

[Hanspeter Portner]

On 22.06.2015 19:53, Spencer Jackson wrote:
> I  think it would be best to match the osc method of having no data
> (and no atoms) for the T F I N types. It is not a lot of overhead to
> have a couple extra atom headers but why add it when the original
> spec doesn't have it?  Any existing code made to handle OSC messages
> would need extra modification to handle this difference.

On 22.06.2015 21:07, Albert Graef wrote:
> I don't have much to add to what Spencer already said, but FWIW here 
> are my 2 cents. I agree with Spencer that the TFNI types should be 
> atom-less. All the information is already in the type string, it's
> up to the plugin to process it in any way it sees fit.

Yes, it makes sense to not have any atoms for TFNI, this would be
redundant data.

On 22.06.2015 19:53, Spencer Jackson wrote:
> Just FYI In my OSC2MIDI utility we just ignore that first bit of a m 
> type. Not sure if thats really the best but it was surely the
> simplest.

On 22.06.2015 21:07, Albert Graef wrote:
> Concerning the OSC-encoded MIDI messages, I guess that in order to 
> avoid information loss they might be encoded as a tuple containing an
> LV2_Atom_Int and an LV2_Atom_Chunk. Seems overkill to me, though, so
> I'm also leaning towards just ignoring the port byte, who uses it
> anyway? FLW ;-)

OK, the 4-byte OSC MIDI paramenter would be mapped to a valid 3-byte
MIDI__MidiEvent, ignoring the first byte. When mapping back from
3-byte MIDI__MidiEvent to 4-byte OSC MIDI parameter, we just prepend
a zero byte (0x00).

On 22.06.2015 19:53, Spencer Jackson wrote:
> I've been thinking about it. I'd like to use OSC for microtonal
> control of synths. I'm curious if you have a plan for Chimera's note
> event message structure. I didn't notice any mention on your site.

The Chimaera's preferred output is raw motion data via TUIO 2.0 [1]
which should dynamically be mapped to some other OSC, MIDI, LV2 control
ports, LV2 patch:Message's, etc. (It can also directly output to
SuperCollider Server [2] and is one of the few things that can send
MIDI via OSC ;-)

> I read your postfix documentation. That is good, but it would be nice
> to come up with a default that could at hopefully be semi-standard
> for some interoperability between products.

OSC and interoperability, they don't mix well, yes...

A custom MIDI controller setup may be a direct one:

  MIDI controller <-> MIDI synth

With OSC, you either need a reconfigurable controller or a
mediator so that controller and synth will understand each other.

OSC controller (e.g TUIO) <-> mediator <-> OSC synth (e.g.
SuperCollider, Zyn, Carla, Ardour, ...) or MIDI synth

The OSC prefix output engine [3] turns the Chimaera into such a
reconfigurable controller and can get rid of the mediator.
This kind of works, but you're limited in the complexity of
messages you can create and it comes at a cost as you need to run
a virtual machine to create dynamic OSC messages, which is e.g.
suboptimal on a microcontroller.

I prefer the solution with a mediator. The mediator may be a
standalone app (e.g. your OSC2MIDI) or a LV2 plugin. That's what
I'm interested in right know actually and thus looking for a
sensible mapping of OSC<->Atom: LV2 plugins that can translate
between OSC, MIDI and Atom (e.g. patch:Message) events.

On 22.06.2015 21:07, Albert Graef wrote:
> Do you have any thoughts yet how this extension might be implemented
> in existing DAWs?

No, no thoughts about DAWs at all as I'm into live play and modulars...

> Specifically, I'm thinking about how the DAW should route OSC
> messages from the outside world to a plugin. To not overwhelm plugins
> with a flurry of messages they don't understand, there should 
> probably be a way of advertising the paths (or prefixes of paths) a 
> plugin wants to receive in the plugin manifest?

Mhm, that's all things I've not thought about at all as I can route the
signal where I need it in a modular... I don't know, really.

On 22.06.2015 22:08, Robin Gareus wrote:
> only a simple remark:
> 
>> even more exotic types 'c'    char          LV2_Atom_Int 'S'
>> char []       LV2_Atom_String 'm'    uint8_t [4]   LV2_Atom_Chunk
>> (type=MIDI__MidiEvent)
> 
> is Chunk correct here?

That's a typo, this should be a LV2_Atom of type MIDI__MidiEvent, yes.

> I'd expect a LV2_Atom_Event with type MIDI__MidiEvent (inside an
> Atom Sequence) in the plugin.

Not sure whether I understand your issue here...
If there is a 'm'idi parameter inside OSC, you'd rather like to
extract it automatically?

OSC: /hello ,m 00902a7f

like:

{
  LV2_Atom_Frame_Time
  LV2_Atom(type=MIDI__MidiEvent, body=902a7f)
}

instead of:

{
  LV2_Atom_Frame_time
  LV2_Atom_Object(otype=OSC__Message)
  {
    LV2_Atom_Property(key=OSC__messagePath,
      value=LV2_Atom_String(body='/hello')
    LV2_Atom_Prperty(key=OSC__messageFormat,
      value=LV2_Atom_STring(body='m'))
    LV2_Atom_Property(key=OSC__messageArguments,
      body=LV2_Atom_Tuple
    {
      LV2_Atom(type=MIDI__MidiEvent, body=902a7f)
    })
  }
}

This kind of breaks the prerequisite of being able to reconstruct
the original OSC out of a potential Atom representation...

What about mixed arguments?

OSC: /hello ,misf 00902a7f 2015 world 0.1

If you extract the 'm'idi from the argument list, what would you
do with the original one?

I'd rather do that with a simple OSC->MIDI LV2 filter which extracts
all 'm'idi arguments from an OSC message and discards the rest.

[1] http://www.tuio.org/?tuio20
[2] http://doc.sccode.org/Reference/Server-Command-Reference.html
[3] http://open-music-kontrollers.ch/chimaera/usage/#custom