On Sun, Sep 28, 2008 at 6:18 PM, Chris Williams <[EMAIL PROTECTED]> wrote: > DSSI, IMO, *attempted* to get this right. Implicit in the > DSSI spec is an acknowledgment that a plugin spec can't be > in the business of mandating gui solutions on a platform > with many to choose from, so they tried to find a way > around it using a remote gui which communicates with the > host via OSC. I'm not sure this is entirely correct, > either, but it's at least "more right" than several other > ways of doing it (*cough* LV2), especially the central idea > of trying to abstract the gui away from the architecture.
The DSSI approach has two really big problems: 1. It's hard to share significant amounts of data between GUI and plugin, and to do things like synchronising the state of user presets. It can be done using shared memory negotiated between GUI and plugin via configure calls, for example, and Lars wrote a small library to help with this, but it's always going to be a pain. 2. It's different from any other plugin system, so you can't just write the code once and wrapper it for each of your supported protocols. Take a look at the absolutely gross hack used by dssi-vst, for example, to see how much pain is involved in doing an incomplete and unsatisfactory job of wrapping a GUI written for another system. Chris _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
