1 Dec
2007
1 Dec
'07
5:29 p.m.
On Sat, 2007-12-01 at 22:19 +0100, David Olofson wrote:
Yep. Something ala:
struct LV2Event {
uint32_t frames;
uint32_t subframes;
foo_t type;
uint32_t size;
// data follows here
};
Best choice for order and foo_t for alignment? Making it smaller than
32 makes size's (and data) alignment suck, but 2^32 types of events at
one time is pretty nuts.
Cheers,
-DR-
On Saturday 01 December 2007, Dave Robillard wrote:
[...non audio time timestamps...]
Understandable. I'm thinking the events themselves can be the same
(they're so open-ended, why not..) but the transport mechanism would
just be different. Some kind of one-event-at-a-time thing instead of a
big flat buffer.
There's also the sharing of transport layer and 'crossing' contexts,
yes. The way I see it in both cases the generic event is just a time
stamp, size, and some data, so might as well make this one good enough.
Precise timing resolution never hurt anyone anyway.
All I ask for is a few measley bits :) That I
can point to widely
accepted standards (one of which is very, very close in domain to
this event stuff) that use timestamps of this sort is telling..
Sure, I have no problem with that. I just don't want to make sure
we're not confusing this with types of event communication that just
doesn't fit in the model of this particular event system. I mean,
it's kind of pointless to pollute *this* event system with features
that you need a completely separate LV2 extension to actually
use. :-) (Well, unless that other LV2 extension can use this one as a
transport layer in some sensible way, maybe.) Anyway, making
the frames part 16 bits screws up parity with Jack
MIDI. We already have a uint32_t frame timestamp. We want
fractional, so stick a fractional part in there, voila. The host
just sets the fractional part to 0 from Jack, things can use the
fractional bit (or not) as they please.
Simple.
Yes, that makes sense to me. It seems like the general case (even when
making use of sub-sample timing) favors separate integer and
fractional parts, and then, why not just use an int for each?