On Tue, 15 Jun 2010 13:03:51 +0400, Louigi Verona wrote:
On Tue, Jun 15, 2010 at 12:16 PM, Luis Garrido wrote:
So
I've written a GUI, and I've gotten a better understanding
of how the Qt framework works. It seems to me that all that
would be necessary is for the host to pass a pointer to a QWidget,
which the plugin adds itself to, and the rest can behave exactly
like the ui:GtkUI. If I'm not mistaken, all that would be necessary
it to write a new rdf file.
That's the easy part. Now all that is necessary is that _host
developers_ include support for a ui:QtUI extension. That will be
especially difficult is the host is a Gtk app. Welcome to the plugin
UI holy wars. :-)
Also your plugin outputs MIDI, I don't know how many hosts include
support for that, but I'd reckon not a lot.
At this moment of Linux Audio Plugin History I'd recommend you to
convert your plugin into a standalone application. Then you can add
whatever GUI you want and don't have to worry about connectivity
issues and host compatibility, since all will be handled by
jack/jack-midi/alsa-seq. Add lash or jack-session support and we are
good to go.
Should work fine with Qtractor at least )))
nope.
qtractor does the lv2 external-ui extension only. this is the only lv2 ui
extension that is framework/toolkit agnostic.
it is my stance that all lv2 plugin authors should make their plugins
independent of the host implementation gui toolkit. the lv2 external-ui
extension delivers this independence. you can either do in-process or
out-of-process (like dssi), and most importantly you can do it on whatever
toolkit you believe sucks less.
nb. lv2ui:gtk plugins will only show on gtk hosts. lv2ui:qt plugins will
only show on qt hosts, if there will ever be one that supports it
specifically. qtractor won't be one of them, sorry.
fwiw, use the lv2 external-ui extension.
stay away from all gtk (qt) lock-in (lock-out) epidemics ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org