<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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 ....<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 10, 2017 at 4:01 PM, Harry van Haaren <span dir="ltr"><<a href="mailto:harryhaaren@gmail.com" target="_blank">harryhaaren@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Sun, Dec 10, 2017 at 7:43 PM, Gordonjcp <<a href="mailto:gordonjcp@gjcp.net" target="_blank">gordonjcp@gjcp.net</a>> wrote:<br><br><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.<br><br>> So what would you write it in instead?<br><br>There are a range of toolkits / libraries available especially designed for plugin usage.<br>In no particular order, the following come to mind. (Note, as OpenAV I'm the author of Avtk(a), </disclaimer>)<br><br>Toolkits / frameworks:<br><a href="https://github.com/x42/robtk/" target="_blank">https://github.com/x42/robtk/</a> (meters.lv2, scopes.lv2 and other x42 software)<br><a href="http://distrho.sourceforge.net/" target="_blank">http://distrho.sourceforge.<wbr>net/</a> (particularly the "DGL" component IIRC)<br><a href="https://github.com/mruby-zest" target="_blank">https://github.com/mruby-zest</a> (new Zyn Fusion UI toolkit)<br><a href="https://github.com/wrl/rutabaga" target="_blank">https://github.com/wrl/<wbr>rutabaga</a><br><a href="https://juce.com/" target="_blank">https://juce.com/</a><br><a href="http://openavproductions.com/avtk/" target="_blank">http://openavproductions.com/<wbr>avtk/</a> (and its WIP 2.0 version <a href="https://github.com/openAVproductions/openAV-avtka" target="_blank">https://github.com/<wbr>openAVproductions/openAV-avtka</a><wbr>)<br><br><apologies; I expect there to be others toolkits, the above are all I can think of right now.. ><br><br>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: <a href="https://github.com/drobilla/pugl" target="_blank">https://github.com/drobilla/<wbr>pugl</a><br><br><br>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..<br><br>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].<br><br>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].<br><br>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.<br><br>Looking forward to what the next steps are in Linux Audio Community start doing, with these root problems addressed, and various solutions available...<br>Regards -Harry<br><br>[1] <a href="http://lac.linuxaudio.org/2015/video.php?id=14" target="_blank">http://lac.linuxaudio.org/<wbr>2015/video.php?id=14</a><br>[2] <a href="https://en.wikipedia.org/wiki/Eating_your_own_dog_food" target="_blank">https://en.wikipedia.org/wiki/<wbr>Eating_your_own_dog_food</a><br>[3] <a href="https://github.com/openAVproductions/openAV-artyfx" target="_blank">https://github.com/<wbr>openAVproductions/openAV-<wbr>artyfx</a><br>[4] <a href="https://youtu.be/qHt-AQHcBXg?t=1237" target="_blank">https://youtu.be/qHt-AQHcBXg?<wbr>t=1237</a><br><br>--<br><br><a href="http://www.openavproductions.com" target="_blank">http://www.openavproductions.<wbr>com</a></div>
<br>______________________________<wbr>_________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.<wbr>linuxaudio.org</a><br>
<a href="https://lists.linuxaudio.org/listinfo/linux-audio-dev" rel="noreferrer" target="_blank">https://lists.linuxaudio.org/<wbr>listinfo/linux-audio-dev</a><br>
<br></blockquote></div><br></div>