"Don't use any toolkit can't be the right answer. To solve this situation, Ardour could be provided as dynamically linked packages for the individual distributions, right? Of course this would be much more work for Paul..."
You're kidding right...?!
Yes Paul should really quit laying around and start doing more... Coding the best DAW on Linux and creating self-contained Distro-agnostic binaries is really just not enough...
There are existing plugin UI methods that work.. some freedom of choice for doing things the "wrong" way has already been given out of courtesy, choosing a toolkit outside of that is just being stubborn for the sake of being stubborn...
If I would be the dev of EQ10Q I would prefer to implement the GUI in a separate process. Implementing IPC-mechanisms for some data model is *much* simpler than programming your own GUI-toolkit.
@dbra: externalUI already provides a way to do that (and some plugins do exactly that). It doesn't provide the IPC mechanism, that would (and, I think should be for the plugin developer to decide how to implement) but it does provide the hooks necessary. I can't be certain, as I don't use a separate process for my plugins, but there may be an issue to watch out for around inheriting the environment from the parent process (ardour) when the UI process is forked.
It might also be possible to convert it to e.g. a VST using JUCE - that way it would be compatible with just about everything
the external UI extension to LV2 makes it impossible for the host to manage automation correctly. this is a major drawback and is a reason why ardour no longer supports it (or will not do so in the future.
@paul: what aspect of automation does it not support? As far as I know I have not found any issue with automation. The (external) UI provides a means to pass parameter changes initiated by the user to the host, which are then stored as automation events by the host (where they originate from is irrelevant, it could be external MIDI controls, the default UI or a plugin provided one - the host only knows the parameter ID and the value). When automation is played back, the control changes are passed to the UI, which displays them. This is exactly as it works on e.g. an Audio Unit plugin (to which LV2 is very similar in design)
There is good reason not to drop externalUI - principally because it is the only LV2 UI solution which works with acceptable reliability (and on other DAWs not using GTK)
Doesn't work on mine. The sound just goes out when it's activated. I'm using the Ardour3.2 package from KXstudio for the plugin.
Your subscriptions & donations are critical help that make it possible for full-time development of Ardour to continue. Your support is critical and much appreciated.
August goal US$4500 (US$54k/yr)
Subscribers 1024 US$1600/month
Support Ardour, get free upgrades: pay $1, $4, $10 or $50/month for a year: