[LAD] Plugin Toolkits (was ~ Forgive me, toss your Macintosh)

[Harry van Haaren]

On Sun, Dec 10, 2017 at 7:43 PM, Gordonjcp <gordonjcp at gjcp.net> wrote:

<snip> Previous discussion about plugins using GUI library frameworks like
Gtk/QT, which are not designed for plugin usage. As a result, they export
symbols that may collide when loaded in a DAW and plugin, when DAW and
plugin are compiled against different version, ending up in a segfault that
is no single softwares fault, but one of usage of a library for a purpose
it is not appropriate for.

> So what would you write it in instead?

There are a range of toolkits / libraries available especially designed for
plugin usage.
In no particular order, the following come to mind. (Note, as OpenAV I'm
the author of Avtk(a), </disclaimer>)

Toolkits / frameworks:
https://github.com/x42/robtk/  (meters.lv2, scopes.lv2 and other x42
software)
http://distrho.sourceforge.net/   (particularly the "DGL" component IIRC)
https://github.com/mruby-zest  (new Zyn Fusion UI toolkit)
https://github.com/wrl/rutabaga
https://juce.com/
http://openavproductions.com/avtk/ (and its WIP 2.0 version
https://github.com/openAVproductions/openAV-avtka)

<apologies; I expect there to be others toolkits, the above are all I can
think of right now.. >

Many of the above are based on a fantastic abstraction library from the LV2
author, specifically abstracting away platform and implementation details,
without any static data. That means it was designed for a purpose - like
embedding and plugin GUIs: https://github.com/drobilla/pugl


I have previously used Gtk, FLTK/NTK, and other toolkits. None of them are
guaranteed to work correctly in DAW X that links to the same libraries.
They're just not designed for that use case - and that's fine. But we (as
developers) need to be careful to not consume a library in a way not
intended for it to be used..

As such, Avtk is developed on PUGL to ensure there is no static data, and
to fix lots of other potential issues that many toolkits have (forking new
threads, waiting for a response in a thread while displaying a modal
dialog, using static caches for data, etc...) For details on AVTK, there
was a presentation at LAC '15 video, slides + paper available[1].

OpenAV dog-fooded[2] writing the ArtyFX[3] plugins using the AVTK library
for the UIs. Based on the experience, I'm developing AVTKA (Avtk v2) in
plain C, with emphasis on ease of use and simplicity in getting lightweight
plugin interfaces built. This makes it easier to use the toolkit for LV2
plugin UIs, as well as a range of other uses. An example of other uses is
creating "virtual hardware" devices for the Ctlra library, inside existing
audio software without needing to care which UI toolkit: eg: Mixxx + Ctlra
virtual interface, built using PUGL + AVTKA. A demo video of exactly that
from the Sonoj event available here[4].

As you may notice, I'm a little passionate about doing the right
engineering in terms of solving the UI toolkit + plugin problem. As
hardware controllers are getting more fully-featured, they also have
screens available. In order to capitalize on thier potential, we need to
handle this use case too - so we can have user-interfaces on Desktop, DAW,
and Hardware controller that have similar look and feel.

Looking forward to what the next steps are in Linux Audio Community start
doing, with these root problems addressed, and various solutions
available...
Regards -Harry

[1] http://lac.linuxaudio.org/2015/video.php?id=14
[2] https://en.wikipedia.org/wiki/Eating_your_own_dog_food
[3] https://github.com/openAVproductions/openAV-artyfx
[4] https://youtu.be/qHt-AQHcBXg?t=1237

--

http://www.openavproductions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20171210/1a799d5a/attachment.html>