A DSSI plugin UI is a separate standalone program, that communicates with the host (not directly with the plugin) via Open Sound Control messages. (Thus ducking out of the GUI toolkit compatibility question altogether, ensuring that the plugin is always correctly automatable by the host, and in principle permitting plugins to be controlled by other OSC clients as well.)
Sounds complicated enough, splitting the plugin up into separate "plugin dll" and "gui executable" parts, which both have to know plugin internals; and communicating to the host using OSC, over UDP (!) as required by DSSI. (I know it sounds cool that you might be able to have your DSSI plugin running in Renoise on one machine, and control it from a GUI running on another machine. But show me just one person who is actually doing this. Or at least, name one use case for this. And no, "sounds cool" is not a use case. Besides, if you really want to do this, use ssh -X.)
But it gets funnier:
The mechanism by which a host locates and starts the UI for a plugin is host-dependent, and this section is only a recommendation.
Next follows a "recommendation" how the GUI executable corresponding to the plugin might possibly be found (or possibly not). I. e. there is no defined way to even locate, and start the UI.
Oh, and have you checked out the licence:
Note that liblo is distributed under a different licence from DSSI and so might not be a legal option for certain DSSI implementations.
I won't go into the stupidity of using a network protocol to communicate data between a UI and a real-time audio app which is supposed to have ultra-low latency, it's just too idiotic. Not mentioning the bloat and dependencies it adds.
Now the parameter passing from host to GUI and back is done by parsing strings (like the "base path"), which is, of course, the safest, easiest and most efficient possible method to pass some information which you actually don't need (hint: just pass the parameters to the process/function/whatever-place it belongs, using a numeric ID for each parameter; no need for a "base path"). Some of these parameters are:
<base path>/midi
Send an arbitrary MIDI event to the plugin. Takes a four-byte MIDI string. This is expected to be used for note data generated from a test panel on the UI, for example. It should not be used for program or controller changes, sysex data, etc. A host should feel free to drop any values it doesn't wish to pass on. No guarantees are provided about timing accuracy, etc, of the MIDI communication. (optional method)
"Optional method". Right. Expect lots of confused users clicking on a keyboard control in the UI and not hearing any output, because it's "optional".
# <base path>/show
Show the UI, if it's a graphical interface in a window or some other type that it makes sense to show or hide. If the UI is already visible, bring it to the front if possible. No arguments. (optional method for UIs in general, but it would be bad form to implement a graphical UI without it)
Which reminds me about the usability problems with separate GUI apps. Think about fullscreen mode: Click anywhere on the Renoise window; Plugin GUI window will be hidden. Bring Plugin GUI window to the foreground with some key combination; it will be visible, but only until you use Renoise again. Next, click the "Show Editor" button and wonder why the editor is not shown (it will be HIDDEN by clicking the button, because it was actually visible, just obscured by the fullscreen Renoise window). Also, window managers will show their taskbars et cetera when a non-fullscreen window is shown, overlapping the Renoise window. In any case, you can't use both Renoise and the Plugin GUI at the same time. This will completely disrupt the workflow - just like with current Standalone Synth apps - unless maybe if the plugin gui code uses some clever X11 magic to exclude the gui window from taskbars and also make it topmost, which MIGHT work on SOME window managers - and then you'd have a topmost window which isn't hidden when you switch away from Renoise, which is, probably, also annoying. (The way Renoise currently handles native VST editor windows, presumably using some kind of reparenting, won't work with separate GUI apps because neither Renoise nor the GUI app know about each others' window IDs.)
Etc, etc, etc. All this sounds to me like, "Hey, let's make a plugin API for Linux. But let's make it as complicated, bloated, hard to use for developers and users alike, and inefficient as possible. Also, let's introduce lots of nodes where stuff can easily break. After all, we're dealing with Linux users here. These people LOVE fixing broken stuff."
I'd love to have a decent plugin API for Linux, but I think DSSI is not it.
Hopefully LV2 is more sane. I haven't looked into it yet...
[ view entry ] ( 3203 views ) | [ 0 trackbacks ]
This totally b0rked antialiasing filter... Sounds kinda cool. :-)
broken-antialiasing-filter.ogg
[ view entry ] ( 3006 views ) | [ 0 trackbacks ]
Version 0.3 has a Virtual Keyboard component (most useful in the standalone version) and some other GUI niceties. It's built with latest Juce tip.
Download: Linux binaries (32-bit)
Source: SVN
See README for build instructions.
[ view entry ] ( 3258 views ) | [ 0 trackbacks ]
While Juced (the fork) has some features the original Juce lacks, Juced could be merged a little more frequently for my taste, and it's not always 100% internally consistent (incompatibilities with UI code generated by The Jucer). Also, the main feature I liked about Juced - JACK support - was recently integrated into Juce, so there's little reason left for me to use Juced. I'm switching back Wolpertinger to build with the original Juce for now.
[ view entry ] ( 2555 views ) | [ 0 trackbacks ]
Wolpertinger will now properly build again with Juced SVN.
Build process works something like this:
1. Get Juced
svn checkout http://juced.googlecode.com/svn/trunk/ juced -r163
2. Build Juced
(cd juced/tools/linux; ./manage make lib)
3. Get VST SDK 2.4
... point browser to Steinberg's developer site... Setup "3rd party developer account"... Provide Email address for SPAM... Sign in blood the provided License Agreement... Sell soul to Satan... Finally, unzip the SDK to subdirectory vstsdk2.4...
4. Get Wolpertinger
svn checkout svn://svn.tuxfamily.org/svnroot/tumbetoene/wolpertinger/trunk wolpertinger
5. Build Wolpertinger
(cd wolpertinger; make; make config=release)
Done! You will find the normal binaries in build/Release and debug binaries in build/Debug.
Once you did the setup you can just run
cd wolpertinger; svn update; make; make config=release
to make the latest Wolpertinger.
Note that point 3 (the PITA point) is the reason we need a set of free-as-in-speech VST-compatible plugin headers - a Vestige for Plugins (VFP). If you want to help constructing one, contact me.
[ view entry ] ( 2378 views ) | [ 0 trackbacks ]