2 Dec
2007
2 Dec
'07
12:59 p.m.
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-