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

On Sun, Dec 10, 2017 at 7:43 PM, Gordonjcp &lt;gordonjcp(a)gjcp.net&gt; 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. 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(a)lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev