btw, this is why steinberg created the “VSTGUI” library all those years ago …
Hi,
I was investigating the crash related with the gtkmm versions difference between ardour self/distribution build and ardour from ardour.org binaries. I have found a solution and this will be implemented in a next beta release, cooming in a few days.
But if you can not wait, you can test it in the last svn snapshot. If you decide get it from SVN, uninstall EQ10Q manually before installing the version from svn because the version on svn installs eq10q in userhome/.lv2 instead of /usr/local/lib/lv2. To uninstall it, run sudo rm -rf /usr/local/lib/lv2/sapistaEQv2.lv2 in a terminal.
Just if you are curious, the problem was related with the two fader widgets used to control the in/out gain. These faders are drawed using a png image and this image is loaded using the function Cairo::ImageSurface::create_from_png() which is only avalaible if Cairo have PNG support enabled using the CAIRO_HAS_PNG_FUNCTIONS macro.
For some reason, ardour from ardour.org doesn’t like using such function from Cairo and crashes when trying to execute it with an unhandled exception.
Now, the PNG image is drawed using Gdk::Pixbuf and coping it to a Cairo surface. This works fine for mine, tested with both variants of ardour (binary from ardour.org and ArchLinux package).
Paul@ It’s possible that the binary of Ardour3 from the website does not includes the PNG support in Cairo?
Nice! I’m looking forward to it… 
@sapista: it seems unlikely but you’ve given a very detailed account of the issue and i will check. We certainly include PNG support in the package overall, since all the icons in ardour (or almost all) are loaded in that format.
Hi,
I’m not a plugin developer but a couple of months ago I spent a lot of time chasing down a similar issue with the Calf Plugins with the Ardour binaries. I know that what finally got it working was Paul’s decision to add ‘gdk-pixbuf’ (oversimplified explanation: the ability to draw pixmaps or image files within apps in GTK) to the GTK libs in the Ardour bundles. I think it’s very important to note that Paul shouldn’t have needed to do this at all but he did it out of the awareness and consideration that the Calf plugins are widely used and popular with Linux users.
As has been stated here before it is a bad idea to use UI toolkits to create plugin GUI’s because in the end it very often causes someone else down the line extra time and effort to use such applications. But perhaps maybe there should be some kind of informal agreed upon ‘standard’ for people who insist on using pixmaps (and png images etc.) to create their UI’s that at least conform to features already available in Ardour.
I know this is Linux and everyone is so ‘free’ to do whatever thay want, (including free to create extra work for somebody else) but maybe it wouldn’t hurt to be ‘free’ to consider what method works most synergistically with existing applications…
If a plugin depends to such (any) degree on the capabilities of specific libraries / function / method implementations, which are not directly related to the a plugin API but which essentially (might) reside inside the host application / bundle, and require quite specific changes to the host to make them work, then surely its not a ‘plugin’ its just an extra (optional) bit of (very) application specific code? It doesn’t seem like the right approach to me… (you wouldn’t get away with it on other operating systems)
Don’t use any toolkit can’t be the right answer. To solve this situation, Ardour could be provided as dynamically linked packages for the individual distributions, right? Of course this would be much more work for Paul…
@dbra: distributions do that. I do not, and will not. But even that doesn’t actually help unless you get every single plugin from the distro as well.
Hmmm, or maybe spawning a separate process just for the plugin-UI would help? Don’t know if this is actually possible, I’m just brainstorming…
Ardour could be provided as dynamically linked packages for the individual distributions, right?As Paul says, the distributions do this (and I would add, badly in my experience). For a developer to maintain builds for (all) the distributions would be impossible - again, in my experience, just managing packaging for distributions, given the number of incompatible package formats, and, that some versions of package managers are incompatible with supposedly the same format on a given distribution (I still have not resolved why a .deb I package for Ubuntu, will not always work reliably on e.g. Kubuntu or why gdebi will work where the software center fails, or why lintian reports plainly ridiculous warnings about a package's dependencies on itself... a process made all the more unfathomable by the fact that the official Ubuntu example documentation is also incorrect when referenced against its own pedantic white-space requirements in the package files. But I digress.. externalUI was intended to spawn another process for the UI, this does mean the plugin requires some IPC method - and this needs some care... or we end up with something like dssi - my plugins use X11, and externalUI as a 'GUI agnostic' method of simply telling the plugin when to launch its editor, and provide a means of passing parameter changes back from the GUI to the host. I run the UI in the same process as the host because it avoids the IPC issues. (but my graphics 'engine' is tens of thousands of lines of code, because it uses X11. Possibly (and I say possibly) a way to manage the UI would be e.g. if the host (or plugin) provided a reference e.g. to some generic 'RGBA' surface on which the plugin would draw its GUI, leaving the host to manage the interface between the surface buffer and whatever UI internals it uses. But this is probably not the place for what could become a complex discussion (or argument maybe... :) )
I should also add, that I think that looking at the problem of pugin UIs with regard specifically to using toolkits is the wrong way to think about the issue. When you write a plugin on any other operating system, you use the base operating system GUI API (or, toolkit if it is sufficiently ‘evolved’ to provide those niceties). For example:
If I write a VST (or an AU) for the Mac, I use cocoa, (or carbon) or at a lower level CoreGraphics. I don’t care that ardour uses GTK and therefore that I could use GTK, or that Reaper uses its own library or whatever. GTK, is just another component of ardour (in this case) which sits on top of the OS.
Similarly if I write a VST for Windows, I use GDI (or GDI+) I don’t care that Ardour or Mixbus uses GTK on top of that, or if any other host uses its own ‘toolkit’. Once again its just another (application) component which sits on top of the base Graphics system.
On linux, that base system is (for the moment) X11. With X11 you don’t get all the nice menus and dialogue boxes, and buttons ‘ready made’ - but to me that’s just ‘what you get’ with linux, and part of the (plugin) developer’s task is to make that work - if possible - (and nowhere is it written that that will be easy… )
“Don’t use any toolkit can’t be the right answer. To solve this situation, Ardour could be provided as dynamically linked packages for the individual distributions, right? Of course this would be much more work for Paul…”
You’re kidding right…?!
Yes Paul should really quit laying around and start doing more… Coding the best DAW on Linux and creating self-contained Distro-agnostic binaries is really just not enough…
There are existing plugin UI methods that work… some freedom of choice for doing things the “wrong” way has already been given out of courtesy, choosing a toolkit outside of that is just being stubborn for the sake of being stubborn…
If I would be the dev of EQ10Q I would prefer to implement the GUI in a separate process. Implementing IPC-mechanisms for some data model is much simpler than programming your own GUI-toolkit.
@dbra: externalUI already provides a way to do that (and some plugins do exactly that). It doesn’t provide the IPC mechanism, that would (and, I think should be for the plugin developer to decide how to implement) but it does provide the hooks necessary. I can’t be certain, as I don’t use a separate process for my plugins, but there may be an issue to watch out for around inheriting the environment from the parent process (ardour) when the UI process is forked.
It might also be possible to convert it to e.g. a VST using JUCE - that way it would be compatible with just about everything
the external UI extension to LV2 makes it impossible for the host to manage automation correctly. this is a major drawback and is a reason why ardour no longer supports it (or will not do so in the future.
@paul: what aspect of automation does it not support? As far as I know I have not found any issue with automation. The (external) UI provides a means to pass parameter changes initiated by the user to the host, which are then stored as automation events by the host (where they originate from is irrelevant, it could be external MIDI controls, the default UI or a plugin provided one - the host only knows the parameter ID and the value). When automation is played back, the control changes are passed to the UI, which displays them. This is exactly as it works on e.g. an Audio Unit plugin (to which LV2 is very similar in design)
There is good reason not to drop externalUI - principally because it is the only LV2 UI solution which works with acceptable reliability (and on other DAWs not using GTK)
Doesn’t work on mine. The sound just goes out when it’s activated. I’m using the Ardour3.2 package from KXstudio for the plugin.