[LAD] "enhanced event port" LV2 extension proposal

[Dave Robillard]

On Sun, 2007-12-02 at 12:58 +0000, Krzysztof Foltman wrote:
> I think the version you (probably) proposed is:
> 
> struct LV2_EVENT_HDR
> {
>   uint32_t frame, subframe;
>   unsigned int size:24;
>   unsigned int type:8;
>   // put data here, but header size+data size must be a multiple of 8
> };
> 
> plus 8-byte alignment requirement (ie. header size+payload size must be 
> an integer multiple of 8), is going to work.

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?

> Either that, or 16 bits for both size and type. Or 16 bits for size and 
> 8 bits for type, and the remaining byte may be used for char field in 
> payload (5 byte payload "for free"). All three are more or less equally 
> good/bad.

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?
 
> MIDI would look like this: 12 bytes header, (up to) 3 bytes content, 1 
> byte padding - which is fine.
> 
> Same for pointer-only data on 32-bit architecture, for 64-bit, there 
> would be a padding of 4 bytes followed by 8-byte pointer. Not very 
> elegant, but perfectly acceptable. Plus, the compiler takes care of 
> generating padding.

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
the internal layout of a byte array here, not an actual C struct.
Alignment stuff is simple enough anyway, maybe with a macro or two.

-DR-