[LAD] "enhanced event port" LV2 extension proposal

[Krzysztof Foltman]

Dave Robillard wrote:

> IP doesn't dictate packet contents whatsoever.  It does what it needs to
> do quite well, I don't think it's crufy at all.  It would be crufty if
> it tried to define, say HTTP error codes...

That's right. Lars addressed that criticism pretty well, I think. The
"evolved" proposal is both keeping headers and data in the same place
and keeping event semantics on separate layer from event transport.

> Please look at the definition of the LV2_MIDI struct in lv2-midiport.h.
> Note the char* parameter, and read it's comment.  The buffer is flat,
> there is no cache thrashing or any such issues here whatsoever.

Here it comes:

	char*      buf;      ///< raw event  data

Maybe you meant to write this?

        char       buf[];   ///< raw event data directly follow here

Because char* usually means, you know, a pointer, not a variable length
array :)

Take this, and solve alignment and URI numbering issues, and both
proposals (LarsL&KF and yours) are actually the same one. Which is a
good thing.

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

Lars solved that one pretty well.

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

Unless the handing out is done on the fly, based on URIs. Like, say,
file descriptors :) We still have "central authority", but this time
it's the host loading the plugins, not a person. Should give a much
better roundtrip and less authority abuse ;)

Krzysztof