[LV2] lv2:relation

[David Robillard]

On Thu, 2012-03-01 at 12:38 +0100, Stefan Kersten wrote:
> On 2/29/12 12:54 AM, David Robillard wrote:
> >>> "Parameter" =
> >>>   * Identified by URI, has a "value" of any type (one per URI per plugin)
> >>>   * Is a property the plugin "understands"
> >>>   * Likely to be saved in plugin state
> >>>   * Can get/set by sending a message
> >>>   * Can be expressed in a control port
> >>
> >> so this would not necessarily be tied to a port?
> >
> > Right.  Mainly, you could set/get one via messages (via an event port)
> > as well.  Among other things, this means you could create them
> > dynamically.  I like that this is tied in with ports so the abstract
> > concept of a "parameter" is not tied to the logistics of ports or
> > whatever else.
> 
> 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.

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

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

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

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.

That said, I don't think your example is *wrong*, having a simple string
or number ID is just more pleasant.

-dr