[LAD] "enhanced event port" LV2 extension proposal

[Dave Robillard]

On Wed, 2007-11-28 at 23:39 +0100, David Olofson wrote:
> On Wednesday 28 November 2007, Dave Robillard wrote:
> [...]
> > The only problem that needs to be handled is how to get the type in
> > there.  I would like to find a good solution to this problem that's
> > as extensible as URIs but doesn't actually stick a URI in the event
> > struct (there are a few other future extensions that have the same
> > problem. strcmp of URIs in the audio thread is, as you say,
> > completely out of the question, but so is handing out a flat numeric
> > space.  This is /the/ problem that needs solving here, and I'm
> > desperately trying to guide the conversation in a direction that
> > will get it solved nicely ;)
> 
> I don't know if this is applicable here, but for Audiality 2 I'm 
> dealing with this on the connection level. Each control is a port 
> like any other, meaning it has a name, a protocol URI and a few other 
> parameters that the host needs to know what can and cannot be 
> connected. If two ports have the same URI, they can be connected, and 
> that's it, basically. Event semantics ("structured 
> stream", "commands" etc) and data fields are left to the plugins that 
> implement the ports, so the host doesn't even need to know what the 
> plugins are talking about. (This is a "direct connection" model; data 
> is not normally piped through the host.)

Same with LV2 ports; works perfectly for port types.  Problem is,
sticking a URI in each /event/ is far too bloated/slow.

-DR-