On Thu, 2012-08-02 at 10:59 +1200, Jeff McClintock wrote: > > I have adapted the GMPI requirements final draft document to a > > comparison with the current state of LV2: http://lv2plug.in/gmpi.html > > For historical interest. I did complete the GMPI prototype. > Now running on Windows (GUI + DSP support) and Mac/Linux (DSP support). We > have over 1000 plugins available on Windows, mostly related to modular > synthesis (because that's my interest). > This year I ported the SDK and several plugins to Mac, and will also be > ensuring they run on Linux (Waves Plugins Ltd have a high-end Linux-powered > mixing desk that runs plugins. It handles mixing and effects for large > consoles and runs at a rock-solid 1 ms latency).
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? :) > .SEM Comparison with GMPI... > > http://www.synthedit.com/software-development-kit/sdk-version-3-documentatio > n/specifications/ > > SEMs main differences with LV2: > * Sample-accurate parameter updates via time-stamped events. > * Provides a performance optimization mechanism for handling silent audio > streams. > * Supports fractional pitch numbers. > * Provides the ability for an instrument to define an arbitrary set of > parameters that applies to each voice > > Comments on LV2..... > > >53 Disagree - Achievable entirely with metadata. > > If a feature is achievable with metadata, then you DID MEET that requirement > (in a cool manner). The spec doesn't say HOW to meet the requirement. > Update your table to say 'Met' on these requirements. 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. > The SEM DSP Plugin API has a total of four functions { open(), setBuffer(), > process(), receiveMessageFromGui() }, the remainder of the spec is covered > by metadata. 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. > >61 ...It is unclear what "patches" means here. > > It means presets. Or more generally save/restore the plugin's state. It > doesn't mean the plugin *cares* about presets (like VST2), presets can be > concept the host entirely takes care of. I see. "With patches" should have been omitted. Thanks. > >73 "GMPI must define a simple in-process custom UI mechanism. " Disagree - > It is unclear what this requirement means. > > It means the SDK should support GUIs, for example VST provides for opening a > OS 'Window', what and how you draw inside that window is not specified. More > importantly the API has a mechanism for tweaking the plugins parameters from > the GUI. The crux is not that the API supports graphics or drawing, but that > it supports communicating with the plugin from an abstact 'control surface' > potentially running in a separate thread or even a separate process space. > i.e in SEM the API supports a 'GUI' class getting/setting any of the > plugin's parameters in a thread-safe manner. 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. > >101 "GMPI should allow for copy-protected plugins" Disagree - LV2 is not > and should not be encumbered with specific "copy protection" mechanisms. > > I would say LV2 MEETS that requirement. This point is simply that you should > not actively *disallow* copy protection, and that you can check for example > that the plugin is GPL *without* instantiating it, (because a host might > want to check the license before unintentionally breaking that license by > linking to the plugin). 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 ;) > All in all very good to see GMPI requirements used as a benchmark. A lot of > smart people put many months into GMPI. I think it was considered 'too > radical' at the time (the utter crap VST2 was considered ideal by many, and > still is). 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. > My suggestion that it didn't need MIDI at all (MIDI being too > limited and crufty) resurfaced in VST3 Note-expression. What we see now > with LV2, SEM and VST3 is a vindication of GMPI actually being ahead of its > time. 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev