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

Paul Davis paul at linuxaudiosystems.com
Sun Dec 10 22:11:02 UTC 2017


I think it's also worth mentioning that although MacOS and Windows
generally have an easier time with this stuff, they too sometimes can
suffer from plugin/host toolkit/runtime wierdness.

There's a case under discussion right now on the coreaudio mailing list
involving a very smart, very long-time developer of a synth development
toolkit who added some code to automatically build GUIs on MacOS. Since
Cocoa uses Objective C, and since Objective C has a single per-process flat
namespace, if you loaded two modules that contain symbols with the same
names in each, there's no way to predict which ones will actually be
invoked. This is causing some trouble getting his runtime-constructed GUIs
to work because (probably) one plugin built with his engine can share
symbol names with another plugin built with his engine.

It's very likely there is a reasonable solution, but still ... the flat
namespace combined with "dynamically load arbitrary code from arbitrary 3rd
parties" is not exactly an obviously winning combination ....

On Sun, Dec 10, 2017 at 4:01 PM, Harry van Haaren <harryhaaren at gmail.com>
wrote:

> 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
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20171210/1b2b7005/attachment.html>


More information about the Linux-audio-dev mailing list