[LAD] "enhanced event port" LV2 extension proposal

[Dave Robillard]

On Sat, 2007-12-01 at 22:19 +0100, David Olofson wrote:
> On Saturday 01 December 2007, Dave Robillard wrote:
> [...non audio time timestamps...]
> > 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.)

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.

> > 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?

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-