[LV2] messages and URIs (was: lv2:relation)

[Stefan Kersten]

On 3/1/12 8:21 PM, David Robillard wrote:
> On Thu, 2012-03-01 at 12:38 +0100, Stefan Kersten wrote:
[...]
>> i have a related problem (i'm not very fluid yet with RDF): for control
>> of my audio engine i am thinking about moving from OSC to something more
>> structured and flexible such as LV2 atoms and messages.
>
> Me too.  OSC hasn't really cut it.  I think I might drop all the
> protocols from Ingen and just implement LV2 atom control, then implement
> separate bridges for various protocols.  That way, everybody gets the
> benefit.  I am not sure if a 100% mapping to/from OSC is possible,
> though pipes/ringbuffers/http/truly-awful-midi-sysex/etc will work.

i think it would be good to have an architecture independent binary wire 
specification for LV2 atoms in order to be able to compare 
expressiveness and performance to OSC. currently it's difficult to 
represent nested structures in OSC, which might improve with the next 
protocol major version (see [1]). if it's important to retain fast 
integer-based dispatch for LV2 atoms across machines, it would be 
necessary to implement a protocol for global URID mapping (see also 
[2]), complicating things a little ...

>> let's say my engine maintains a tree of nodes where the leaf nodes
>> correspond to instances of LV2 plugins. nodes are created and
>> manipulated by a client via asynchronous messages and identified via
>> unique integer ids.
>>
>> now if i want to set the value of a control port, i could use a message
>> like this:
>>
>>       [
>>           a msg:Set ;
>>           msg:subject [ a myEngine:NodeId ; myEngine:id 12345 ] ;
>>           msg:body [
>>               uri:parameter 3.14 ;
>>           ] ;
>>       ]
>>
>> in other words, the information of where to send the message (the plugin
>> instance with the corresponding node id) should be contained in the
>> message itself. is this a viable use of msg:subject? i don't really want
>> to make the node ids proper URIs. or would it be better to put the
>> message in some higher level container that contains the information
>> about where the message should go?
>
> (Aside: I am glad to see someone else looking in to this stuff.  You
> have the right idea.  I find the ability to think/talk about low level
> messages in Turtle like this very helpful... and I'm just finishing up
> the round-trip serialisation implementation now)

this is a very nice tool to have!

> I intended msg:subject to be a URI or blank ID, never really considered
> a complex subject like this but I suppose there's no reason to disallow
> it.
>
> However, an ID like that will be a bit annoying to work with.  It's much
> nicer to have a single primitive that can function as an ID.  I would
> suggest one of two options:
>
>   * Have the numeric ID precisely define any node, without a need for a
> type (myEngine:NodeID).

this could be possible, but there are different namespaces, see below.

>   * Construct a path/URI for each node.  Ingen does this,
> so /root/subpatch/oscillator is one path.
>
> The latter is more human friendly, the former is faster.  If you do the
> former with URIs and map them to integers you can get both.
 >
> I am not saying "you must use URIs", but don't just cast the idea aside
> as web junk either.  urn:myengine:12345 is a URI, for example.  Perhaps
> we should have a recommended scheme for process-local uses like this...
> this would be nice if we could use relative URIs ("12345" is a valid
> relative URI), but unfortunately our URI mapping facilities can't.

the problem is that nodes can be created and freed at a high rate. once 
a node id is destroyed its URI should also be removed from the mapping 
table in order to avoid those dead URIs piling up in memory.

which datatype would i use if i didn't want to use a mapped URID but a 
URI string? there is a string type but apparently no URI type.

> Why do you need the myEngine:NodeId?  What other namespaces do you have
> for numeric IDs?  Another option could be to reserve the last few
> characters for a type so you can still distinguish type with a single
> numeric ID.

there are at currently four id namespaces, for nodes, control and audio 
buses and buffers.

i could use different base URIs, e.g.

urn:myengine/node#12345
urn:myengine/audioBus#12345
urn:myengine/controlBus#12345
urn:myengine/buffer#12345

but this seems wasteful in terms of bandwidth and memory allocator 
pressure (mainly for nodes, the other resources are generally more 
persistent). i think the most efficient option would be to encode the 
type in the id, but it seems like a hack ... now that i think of it, the 
type doesn't really need to be transported; if every resource knows how 
to handle a message, i just need one big map of URI/URID to resource.

another option i thought about would be using UUIDs for resources; then 
a resource id would be unique (within certain confidence bounds) among 
several clients and could be generated locally without a central 
registry. would it be possible for the atom extension to support a 128 
bit UUID type?

<sk>

[1] http://lists.create.ucsb.edu/pipermail/osc_dev/2011-November/001964.html
[2] http://smcnetwork.org/system/files/smc2011_submission_173.pdf