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

On Tue, 2007-11-27 at 10:46 +0000, Krzysztof Foltman wrote: "extensible" like SYSEX. It isn't 1980 anymore... 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). 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. 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 :)