10 Dec
2017
10 Dec
'17
10:14 p.m.
On 12/10/2017 09:37 PM, Paul Davis wrote:
On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber <
markus.seeber(a)spectralbird.de> wrote:
Hm, I did not think about that hard enough, honestly. Then again this makes
me want to explore the idea of a plugin GUIs separately from the DAW process.
This is not a new idea, but has it already been implemented and explored in detail,
apart from the obvious translation of MIDI/OSC from/to track automation?
You can still statically link for example with
FLTK
You still need to ensure that the host can integrate with FLTK (or any
other toolkit's) event loop. Without some explicit awareness, events etc.
will never be delivered to the non-host toolkit.
and derivatives or roll your
own. On Windows I think Steinberg even provides a GUI toolkit for VST
plugins if
Not in any effective form. Their old version (more than a decade old) was
based on *Motif* for X Window. There's a newer attempt at this, but it no
notable benefits unless you wrote the host using the same thing, which is
essentially impossible because of it's limited scope.
I remember correctly? Or go plain ImGui or plain
OpenGL or whatever suits?
Maybe robin can give better recommendations since he seems to have done
some work
on lv2 GUIs. (maybe see https://github.com/x42/robtk )
robtk is probably one of the most obvious answers, but even robin can
identify some drawbacks.
the thing is that on other platforms, there's a single event loop that all
possible toolkits connect to. on Linux (X Window (and probably Wayland
too)), this isn't true. Qt has done work to use the same glib-based event
loop as GTK but this isn't a general solution. On Windows or MacOS, it
makes no difference what toolkit the host and plugin use, because
everything is inevitably going to get routed through the same event loop
(and redraw cycle). On Linux this is not true, and it's the root of most of
these issues with plugins.