[LAD] "enhanced event port" LV2 extension proposal

[Dave Robillard]

On Sun, 2007-12-02 at 18:35 +0000, Krzysztof Foltman wrote:
> Dave Robillard wrote:
> > More or less agreed.  The size thing isn't really an issue in practise,
> > just reaching for equivalence with OSC/Jack for equivalence's sake.
> >
> > Dealing with a 24 bit number is pretty weird though.  Worth it?
> >   
> I prefer 16+16 to 24+8. I can see more uses for 16-bit types than for 
> 24-bit sizes (basically, defining a new URI for every parameter exposed 
> by a plugin, you'll find people insane enough to try that). Perhaps you 
> can probably see the applications where 24+8 is more desirable. Decide 
> for yourself.

Well, we don't need that much space for type, and more for size would be
nice.  The only practical limitation for size is probably something like
UDP packet size though, which fits within uint16_t easily.

We are definitely going to need some kind of shared data structure
extension, so really massive message are probably stupid.  16/16 works
and is un-weird.

> > The 'free' payload is tempting since the majority of events (at least
> > for now) are going to be 4 bytes of MIDI.  OTOH, we probably want the
> > data itself aligned (consider e.g. ramp events)
> >
> > We have 32-bit alignment for the data.  Is 64-bit alignment worth
> > shooting for?
> >   
> Yes, I think so. 64-bit platforms are getting more and more popular.

Well, giving size and type 32 bits would give the data 64-bit alignment,
but that's a 16 byte event header...

64 bit will become the norm, sure, but does 64-bit alignment matter here
anyway?  (I have no idea).  We're probably not going to be firing around
arrays of floats to do vectorizable things with here

> BTW, does reading a double from address misaligned by a dword involve 
> performance penalty? If not, we can say that we use alignment of 
> sizeof(void *) on a particular platform. Should be enough.

Life is easier and less problematic if we just pick absolute sizes and
stick with them (so the buffer has a precisely defined format anywhere).
I doubt this is a compelling enough reason to do otherwise.

> > These structs don't actually 'exist', for the nth time ;)  so the
> > compiler doesn't take care of any padding/alignment etc.  We're defining
> >   
> Well, at some point we're going to end up with some structs anyway :)

Not really, just casting a char* pointer to a struct to make life easy.

> In other words, we can define the buffer content in two ways:
> 
> 1. By specifying offsets of particular fields (including payload fields 
> for every event type) as numbers.
[snip]

> 2. By defining it as C structures, and calculating offsets based on
[snip]

We are very precisely defining the layout of a byte array, period.  Yes,
we are discussing it in terms of structs for obvious reasons.  The
constant resurfacing of this idea that they are different is getting
old... this is exactly the same as the current MIDI stuff but we're
adding a few things.

What we have right now is this:

/* 0       4       8       12      16
 * |               |               |
 * |       |       |       |       |
 * | | | | | | | | | | | | | | | | |
 * |FRAMES |SUBFRMS|TYP|LEN|DATA..
 */

On the plus side, 4 byte MIDI messages fit nicely in that 16 byte box,
entire message is 2 64-bit words, 64-bit aligned, no wasted space.
Extremely powerful timestamp, 65535 message types in one system at a
time, maximum message size 64K.  Not too shabby... (though you can see
why I'm tempted to take a byte from type and give it to size).

The data itself isn't 64-bit aligned, but I'd have to see some real
reasons to care.

Whether the alignment of messages themselves in the buffer (via the
padding applied to data) is machine specific is a question (though not a
particularly significant one, IMO), but the layout of the message header
shouldn't be.

-DR-