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

On Thu, 2007-11-29 at 19:43 +0000, Krzysztof Foltman wrote:
> Lars Luthman wrote:
> > It's up to the host I suppose. If you pass the maximum capacity you get
> > maximum flexibility, but also risk that a greedy plugin fills your
> > entire buffer with 12412 MIDI CC's per audio frame. But at some point I
> > guess you just have to assume that plugin writers aren't going to be
> > maliciously stupid. =)
> >
> Judging from my Buzz experience, I *have* to assume that plugin writers
> aren't going to know what they're doing - like a certain plugin
> developer who couldn't get the basic pitch-to-Hz formula right for
> several years, and many others (myself included).
>
> But, unfortunately, there's little one can do to remedy that. You could
> draft the specs in such a way that nobody with IQ under 170 could write
> plugins (DirectShow, I'm looking at you ;) ), but then you'd end up with
> no plugins.
> > According to the core spec, hosts are only required to pass the features
> > to a plugin that the plugin lists as required in its RDF data.
> Unless certain features will need passing "personalized" pointers to
> plugins (separate host's objects per plugin).
>
> And by the way - seems that the char array/union part creates more
> controversies than necessary. So we may get back to Dave's idea of
> payload being a zero-length array (no minimum length), and to 8 bytes of
> alignment instead of 16. If LV2_EVENT_HEADER is defined this way:
>
> struct LV2_EVENT_HEADER
> {
> uint32_t timestamp; // still wondering if fractional addresses should
> be a part of generic even transport spec, by the way
> uint16_t event_type;
> uint16_t size; // of payload, with space occupied rounded up to nearest 8
> };

++

FWIW OSC (and by extension, my LV2 OSC stuff) does this too, except
with 4 bytes instead of 8.

> Then we may define (as another extension, perhaps) a MIDI event like this:
>
> struct LV2_MIDI_EVENT
> {
> LV2_EVENT_HEADER hdr; // or use as a base class in C++
> uint8_t command, arg1, arg2, subchannel;
> uint8_t padding[4];
> };

I /really/ don't like screwing around with MIDI. Just make the events
pure, raw MIDI. Jack MIDI events are 'just n bytes of MIDI', Alsa has
functions to get at 'just n bytes of MIDI', and... well, it's just MIDI.

Everyone knows MIDI, it's probably the most ubiquitous audio standard in
existence. Keeping our hands out of it means trivial interoperability
with everything: past, present, and future. We should just leave it
be.

It's working this way in Jack right now, it's working this way in LV2
right now. If it ain't broke....

-DR-

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