> > For historical interest. I did complete the GMPI prototype. > I don't suppose the code for those modular synthesis plugins is > available? :)
I release as many as possible open source. Unfortunately before I used plugins I coded everything as part of my application, so a most of the good filters, Oscillators etc are not available as plugins, when I have time I'll do more. The stuff I have released is included with the SDK... http://www.synthedit.com/software-development-kit/ It's pretty specific to SynthEdit and the SEM SDK though so might not be much help to anyone. > > 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. [Plugin]--buffer-->[plugin] I use the same buffers over and over, so I inform the plugin once of the buffer addresses, then I need not do so again. Not passing an array to process() is less overhead on the function call... But I think any efficiency gain would be minimal either way, passing an array to process is probably just as good. > 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. Absolutely. The GMPI model is complete separation of GUI/DSP. The GUI has no direct access to the DSP. When the GUI tweaks a parameter it does so only via the Host. The GUI can run on you iPad, the DSP on you Linux box. No special plugin code for that scenario, it's transparent. Very clean. > > 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 ;) Understood. GMPI was for both commercial and free software. > "Including" MIDI is not a burden, it is a trivial consequence of having > a sane event mechanism....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. Yeah, I do support MIDI via 'events', MIDI was trivial....but..... My concept with GMPI (not everyone agreed) was that MIDI was not required *in* the plugin. For example take your MIDI keyboard's "Modulation Wheel". Imagine the function that parses the MIDI bytes, decides what type of MIDI message it is and typically converts that 7-bit controller to a nice 'float' scaled between -1.0 -> +1.0. Typically every single VST synth plugin has that code. The inefficiency is that 1000 Plugin developers had to create and debug equivalent code. I decided the *host* should provide that routine. Written once, available to every plugin developer. The plugin simply exposes a port, and the metadata says "map this port to MIDI modulation-wheel". The advantage is - very rich MIDI support is available to ALL plugins. Not just the standard 7-bit controllers, I support CC, RPN, NRPN, SYSEX, Notes, Aftertouch, Tempo, almost everything. The MIDI parsing code exists only in one place so it's robust, and it saves plugin developers a lot of wasted time duplicating existing code. Plugins are small and lightweight, but MORE functional than the average VST plugin. With VST it's a mess. Developers MIDI support is highly variable, almost none support SYSEX for example. Half of them can't handle NRPN properly if at all. The other advantage is that with MIDI abstracted and presented as normalized 'float' values, the host can substitute OSC or HD-MIDI control without changing the API. Your existing plugins become 'hi-definition' and 'OSC capable' without any effort. You don't have to argue "MIDI vs OSC" because both are possible. Back then I said 'no MIDI in GMPI' - it was interpreted as highly radical and everyone hated the idea. I should have said 'MIDI parsing provided as a service to the plugin'. You have to write the MIDI parsing anyhow, why not make it available for everyone? > That said, sure, MIDI sucks. Something better is needed, but certainly > not some One Ultimate Control Structure to the exclusion of everything > else. All I've done with GMPI is recognise that MIDI controllers can be 'normalised' and presented to the plugin as nice hi-definition floats using the event system (atoms?). The plugin 'has no MIDI', no crufty 7-bit crap, yet is fully compatible with MIDI. That's my rant over ;) Best Regards, Jeff _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
