On Thu, 2012-08-02 at 10:59 +1200, Jeff McClintock wrote: Interesting. I didn't think anyone had done any actual work here in ages, if ever. I stand corrected. I don't suppose the code for those modular synthesis plugins is available? :) Well, the requirements I made this comment for say the plugin must provide a method. Taken literally, this is not met, and I do not think it *should* be met, hence I disagree (they clearly derive from mistakes in VST). I guess I can interpret "method" more abstractly and consider them met. Did you consciously decide to use a setBuffer method for some reason? I consider that (connect_port in LADSPA/LV2) a mistake and efficiency problem. Passing an array to process is better. I see. "With patches" should have been omitted. Thanks. Redundant with 71. I'll consider it met, then, thanks. A requirement specifically about a strong and sensible plugin/UI separation would have been a good one. By far the worst thing about porting VSTs with GUIs. A free for all for UIs to screw with DSP code is insane. Fair enough, I guess I will just list this as met. I felt compelled to at least hint that LV2 is not the sort of project that would ever consider including evil software crippling garbage as a requirement ;) Yes, I thought it would be a useful comparison. If there is any more useful information in an easily digestible requirements-based format, let me know. Anything but events with an arbitrary type tag and a POD body of *whatever* is a mistake, period. "Including" MIDI is not a burden, it is a trivial consequence of having a sane event mechanism. You just need a type tag, and fill your payload with some MIDI bytes. Not allowing for MIDI is completely unrealistic, and would mean plugins can't work with by far the most common format of musical control data, and porting existing code to work as a plugin become dramatically more difficult. Clearly a loss. All you get trying to do things that way is endless mailing list fights about whether to mandate MIDI, or OSC, or the new Ultimate Control Structure, or whatever - a waste of everyone's time. I am ranting a bit here about specification philosophy, but: plugins can use whatever events they want. The organic reality of software development is... well, reality, and good. The silly idea that The Holy Specification having written something down means every host magically supports it is not reality, it is a fantasy. ("Profiles" sound to me symptomatic of this same wrong thinking. Fine-grained features that precisely describe specific functionality is the proper way to deal with varying platform and host support, trying to classify the entire world up front is delusional) MIDI sucks. But MIDI is what plugins are using, and MIDI is what hosts are using, MIDI is what tons of existing code uses, MIDI is everywhere. It is not LV2's place, and it is not my place, to make some fascist mandate that you may not use MIDI, which would do nothing but cripple LV2 and reduce support and power. That said, something better is indeed needed, but (Sidenote: Similarly, Jack royally screwed up by mandating MIDI only, despite being presented with a patch by myself to trivially make the event system generic, and that is why you can't sequence precise per-note pitch bends and parameters in Ardour and control a Jack Synth via OSC or whatever else today, a common source complaint on IRC these days. That is what you get when you don't let developers freely develop) That said, sure, MIDI sucks. Something better is needed, but certainly not some One Ultimate Control Structure to the exclusion of everything else. Extensibility is the way. Anyway, the actual details are the same. With LV2 I have been thinking a lot about this, but there are 3 main options for controllers: 1) Use atom "objects". These are essentially POD dictionaries, and thus extensible. By far the most flexible, automatically serialisable, but with a bit of conceptual and syntactic overhead to actually using them 2) Use OSC. Frankly atoms are better, but OSC is 'standard'. 3) Use a special struct. This is the knee-jerk C programmer thing to do, and simple and fast, but it worries me because if something is omitted from that struct - oops, now everyone has to switch to an entirely new one. I guess an extensible struct with a size field would be a good compromise, we should have made *all* the structs like that anyway. I have been generally going by the philosophy that custom structs are bad, since there is an existing serialisation mechanism in place that works with standard atom types that is used e.g. for cross-process communication between UI and plugin as well as state saving and so on. It saves to/from the same format as LV2 data files, meaning describing things there for whatever reason is also natural. This might be an exception for performance reasons, however. It might be best for me to just forcefully drag people into using atoms for everything, though, since that is also what you need to use to get higher level control like "load this sample", and it means progress is not held up by explicit host support for every little thing... perhaps I need to spend some more effort making working with dictionaries really clear and obvious, it is the best solution on paper, it's just confusing to people who don't get the big picture. I very much like the idea of completely open ended communication between plugins and UI, as well as between plugins (and/or plugins and hosts), where everything is fast, numeric, and POD, yet serialisable to the standard LV2 data syntax. It seems worth it. Liberating, but you have to 'get it' first. Anyway, I've gone on a digression. Thanks for the input, document updated as suggested. -dr