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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 29 12:15:09 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 29 2007 - 12:15:10 EET