[LV2] [RTID] proposal for a 'real time ID' extension

[David Robillard]

On Sat, 2016-08-06 at 15:07 +0200, Hanspeter Portner wrote:
> Hi list
> 
> I hereby propose a tiny LV2 extension under working title RTID mainly useful for
> event messaging. RTID = Real Time ID.
> 
> *Issue*
> 
> 1. patch:sequenceNumber
> When creating/routing patch messages, they can be annotated with a
> patch:sequenceNumber to assist in matching of patch queries and their replies.
> patch:sequenceNumber should thus be collision-free. If the host is the only
> agent issuing patch queries, this poses no problems.
> 
> However, in modular hosts, patch queries may be issued by plugins, too. Those
> plugins need a way of generating a patch:sequenceNumber that does not collide
> with the ones from the host and/or other plugins. Plugins thus need a way to get
> such an unambiguous number from the host, e.g. via a feature.
> 
> 2. Custom modular event systems
> LV2 atoms are so versatile that they are predestined to build custom alternative
> event systems on top. Let's look at sonification of multi-touch/motion/gesture
> event data:
> 
> The predominant techique is to annotate new touch/motion/gesture events with
> unique integer IDs so they can easily be tracked across space and time [0].
> Touch events have a single 'on' event and dozens to thousands of 'update' events
> that refresh some or all of the event's dimensions/properties (e.g. like MIDI
> aftertouch on steroids).
> 
> Let's further imagine pure LV2 event filters that analyse this data to derive
> new events (e.g. based on velocity/acceleration or gesture recognition). In
> order to discriminate derived events from original ones (they may well be mixed
> together downstream in a modular host), they need to be able to request a new
> unique ID somehow. Ideally from a central authority, e.g. the host via a feature.
> 
> *Cure*
> 
> The host provides a feature for plugins (and itself) to request a unique,
> collision-free integer ID to annotate arbitrary event messages where needed.

Sounds reasonable to me.

> As non-colliding integer IDs are not only useful for patch:sequenceNumber, but
> also for custom event systems, it makes sense to not simply add this to the
> patch extension, but create a separate one.

I disagree with this part, though, if simply because we already have
way, way too many extensions (and bundled and namespace prefixes and...)
and it's a mess.  I don't want to add yet another extension for one
little feature.

Which it goes in I'm not terribly concerned about, but patch seems the
most reasonable since I imagine the specification for how these
sequencer numbers need to work will inherently need to be associated
with message semantics.

> *Spec*
> 
> The extension is as simple as it can get: A single function which requests the
> next integer ID from the host whereby the function MUST be RT-safe,
> non-blocking, lock-free and wait-free. New RTIDs may be requested in any of the
> many LV2 thread groups.

I doubt the latter requirement is possible to achieve for anything but a
trivial atomic integer increment.  Is that good enough for fancy use
cases with many plugins operating in parallel on distinct event streams?

>   typedef void* LV2_RTID_Get_Handle;
> 
>   typedef int64_t LV2_RTID;
> 
>   typedef struct _LV2_RTID_Get {
>     LV2_RTID_Get_Handle handle;
>     LV2_RTID (*next)(LV2_RTID_Get_Handle handle);
>   } LV2_RTID_Get;

Seems fine.  Maybe we should stick a flags parameter in next() Just In
Case(TM) ?

> Have a look at the patch [1] and the prerendered documentation [2][3] of the
> current proposal.
> 
> *Implementation*
> 
> This extension can easily be implemented in any host with as little as 1-2
> dozens lines of code. The spec itself contains one in C11 with atomics [3].
> 
> I have this up and running under another namespace
> (http://open-music-kontrollers.ch/lv2/xpress#voiceMap) since months in my humble
> experimental host [4] and accompanying plugin bundles [5][6]. It runs smoothly
> and has not posed any issues so far.

Great, thanks.  I do love proposals in mergeable branch of lv2 form :)

-- 
dr