Re: [LAD] "enhanced event port" LV2 extension proposal

On Tue, 2007-11-27 at 10:46 +0000, Krzysztof Foltman wrote:
> Dave Robillard wrote:
>
> > Why not make it satisfy most everyone by being extensible?
>
> It *is* extensible. Note that commands 0x00-0x6F and 0x73-0x7F are
> unused, so further extensions are free to define them (perhaps we need a
> scheme for binding extension URIs to command numbers, to make it more
> LV2-ey). And 0x72 command can be used for pretty much any data larger
> than 8+2 octets.

"extensible" like SYSEX. It isn't 1980 anymore...

> I think it's not just "not a bad one". The other possibility (multiple
> event ports) is less efficient, and speed is crucial here. It's also
> more complex, looking from plugin author's perspective. So I had little
> choice.

Your extension is too complex, this is primarily why I don't like it.
Why are there two uint8_t's in the header that are probably completely
useless for essentially everything but MIDI? It's crufty.

A stamped chunk of "some sort of event" is simple to understand,
guaranteed 100% extensible and generic without any weird sysexey
1980'sness, and is very, very similar to how LV2 ports themselves work
(and therefore obvious and easy to understand for anyone who knows LV2).

> Notice that I just took the approach of optimizing for most common case
> (MIDI events), and tried to maximize functionality while keeping block
> size small and constant (to avoid pointer arithmetic that was
> complicating Lars' proposal a bit).
>
> > Trying to pre-define things from the top down like this is un-lv2-ey).
>
> Well, sometimes you need to find the right tradeoff between being
> efficient (memory- and speed-wise) and generic. I think I've found an
> acceptable tradeoff (definitely favouring speed, but not losing
> generality and not very memory-hungry).

Your efficiency claims make no sense, frankly. Put everything in a flat
buffer and voila, it's exactly how MIDI events work right now. Your
proposal has no inherent performance advantage over a more obvious and
cleaner one.

> However, I had to make some assumptions about how it will be used
> (mostly implemented by inexperienced people, mostly used for MIDI and
> float parameters, seldom used for advanced stuff). Oh well, I'm
> repeating myself here :)

Exactly. You are making assumptions about what people want to put in
there. This is a Bad Thing(TM). If it can be avoided, it should be
(and it can definitely be avoided).

I have said this a lot, and I will continue saying it more until the end
of time because it's important: the fact that ports can
contain /anything/ is the fundamental core idea behind LV2, and it's a
good one. A good generic event extension must do this as well.

Event transport and event contents are orthogonal problems and they
should be solved separately, otherwise they won't be solved well because
too much is on the table to be figured out at one time (how far would
the Internet have come if every high level protocol was defined in the
IP specification?)

Your optimisation comments (the bulk of your email) are based on a
misunderstanding. I don't mean the data pointer to point somewhere else
in memory, it's a flat buffer (ie almost identical to how MIDI works
right now). For large data, that flat buffer can contain a pointer or
whatever (again, see LV2 port extensions that can e.g. contain structs
with whatever you feel like cramming in there).

In short: if generic events is the goal, then lets make the events
generic!

I'm adamant about this for pragmatic reasons: There are some more
difficult problems here if we really want to crank up the performance of
this, especially random event access and constant time buffer traversal
which needs an lookup table to be around somewhere. I want to make the
event contents part of this discussion go away so we can focus on the
real problem at hand and ignore the (completely orthogonal) details of
event types. The transport part alone is a problem that needs
solving /first/.

Don't get me wrong, I think it's great someone is tackling this one, and
would implement it in a heartbeat, but it needs to be done more in the
spirit of LV2. "Note that commands 0x00-0x6F and 0x73-0x7F are unused"
is more the spirit of MIDI circa 30 years ago. It might be kinda sorta
"extensible" for some limited definition of extensible, but we can do
better.. having to appeal to some (nonexistant) central authority for
doling out a numeric range for features is completely out of the
question (we learned that one with LADSPA IDs).

Cheers,

-DR-

P.S. I tried to see this (generic events) happen with Jack MIDI too but
it was shot down for silly "reasons". Real extensibility means we're
free to hack without having to convince a bunch of sticks in the mud on
mailing lists that we're right (or tell them anything at all for that
matter), which IMO has held back LAD progress in several areas for
years. I absolutely guarantee that people will do new and interesting
things with events if we /completely/ eliminate the diplomatic overhead
of making new event types (I definitely will, and know at least 3 people
who almost certainly will to). Preserve extensibility in LV2 wherever
possible, it's a Good Thing :)

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Nov 28 04:15:03 2007