EQ10Q v2 Beta3 is Released

EQ10Q V2 (Beta3) is there!
A new beta for EQ10Q LV2 plugin is released today.

This beta solves the display problem when opening the plugin for second time on Ardour3. And other bug fixes and DSP optimitzations.

Take a look at eq10q.sourceforge.net for more information and downlad links.

Hey, cool! I’ll try it tomorrow. Thanks a lot!

Like the Beta 2, it crashes when I try to open EQ10Q’s GUI… I’m on Fedora 17-64 with the latest binary package of Ardour (3.1.10) from this site.

It compiles without any warnings or errors. Here is the output of cmake:

– The C compiler identification is GNU 4.7.2
– The CXX compiler identification is GNU 4.7.2
– Check for working C compiler: /usr/bin/gcc
– Check for working C compiler: /usr/bin/gcc – works
– Detecting C compiler ABI info
– Detecting C compiler ABI info - done
– Check for working CXX compiler: /usr/bin/c++
– Check for working CXX compiler: /usr/bin/c++ – works
– Detecting CXX compiler ABI info
– Detecting CXX compiler ABI info - done
– Found PkgConfig: /usr/bin/pkg-config (found version “0.25”)
– checking for module ‘gtkmm-2.4’
– found gtkmm-2.4, version 2.24.2
– Configuring done
– Generating done
– Build files have been written to: /home/carsten/src/eq10q-2-beta3

Any hints on that?

What output is there in a terminal window if you start ardour in there?
Maybe there’s an error message on starting ardour, or when you try to open the gui of eq10q

I’m getting a crash with it in A3 too. Terminal output is:

terminate called after throwing an instance of ‘std::bad_alloc’
what(): std::bad_alloc

This happens when opening the GUI.

It will load and open in A2, however, I’ve noticed that while the single band version seems to work, the others get progressively more unreliable, the EQ10 loads, but just produces a loud pop, followed by silence (no audio will pass through at all).

There is also some strange issue with the parameter interpolation, with the single band its …ok, but adding more bands makes it much more ‘steppy’ such that by 10Bands, it jumps with severe latency relative to the UI (not a smooth sweep, which I would expect, irrespective of the number of bands).

I feel I should also mention that it isn’t “WYSIWYG” - the graph is, in simple terms, what the filter response would look like if it were an analogue filter. The problem is that it’s not. It’s a digital filter and therefore the actual frequency response is at times quite different from that shown on the graph. Specifically at lower (44100 and 48K) sample rates, band-pass with a high center frequency, it appears de-cramped on the GUI, but this is not representative of the actual frequency response.

This has the potential to be a great plugin, but I think it needs a bit more testing (I guess it is just a beta after all)

I got this output on the console on opening the GUI:

(ardour-3.0:9633): glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: std::bad_alloc

^ It’s from the EQ10Q-stereo-plug-in. I haven’t tested the others…

dbra@ I think that the crash your are describing is related with some kind of binary incompatibility between Ardour3 and EQ10Q. I can reproduce the same issue compiling the plugin with gcc 4.8 (latest version on Arch Linux) and using Ardour from ardour.org which is compiled with 4.4. But using the ardour 3.1 from Arch repositories which is compiled with gcc 4.8 all works fine.

I have to dig a bit on it to get a solution, but if someone knows a good way of handle this issues, any sugestion is welcome.

Cool. Thanks!

I compiled it using gcc 4.4.3 (on Ubuntu 10.04 LTS) and as you will have seen I got the same crash. I suspect the issue is not caused by using a specific / wrong version of gcc, but more that there is a deeper problem (and the particular compilation / build environment simply changes the way (or if) the problem manifests)

linuxdsp and dbra, please can you post which versions of gcc and libgtkmm are you using? Ardour3 from ardour.org?
Any info about your enviorment can help me with that problem

I already supplied that infos in the first posting.

I compiled it using gcc 4.4.3 (on Ubuntu 10.04 LTS)...
-- checking for module 'gtkmm-2.4' -- found gtkmm-2.4, version 2.20.3

A3 pre-built binary from ardour.org and / or A3.0.1 from ardour.org

A2 from ardour.org, the plugin works (e.g. it doesn’t crash, other problems are apparent though)

I wonder if there could be some issue due to a mismatch between e.g. the local gtkmm (against which the plugin has been built) and the gtkmm which the ardour bundle is using? I suggest not using gtkmm for your UI.

i strongly suggest not using any conventional Linux toolkit for your GUI, actually. problem is, that doesn’t leave a lot of nice choices - basically raw X Window or GL.

@Paul: completely agree - this is why I use X11 UIs (it also means the same graphics ‘engine’ can be used in linuxVSTs too as these expect an X11UI as part of the plugin <-> host API). I would not recommend GL unless there is some absolutely essential feature which can only be achieved by using it. In my experience GL has some uniquely ‘interesting’ issues, especially in a windowed environment, and, particularly on linux, appears to suffer from incompatibility issues across various implementations and different (and also open vs closed) graphics drivers.

I compiled beta 3 today. It’s working like it should. Gui doesn’t crash and Eq is working.

I compiled ardour from git (built from revision 3.0-122-g3b20beb)
libgtkmm 2.24.2
Compiled with gcc 4.7

I compiled beta 3 today. It's working like it should. Gui doesn't crash and Eq is working.

I compiled ardour from git (built from revision 3.0-122-g3b20beb)
libgtkmm 2.24.2

Most likely because you compiled both host and plugin against the same libgtkmm. However, I suspect that if the gtkmm which ships as a necessary part of the pre-compiled A3 is different to that which the plugin is built against, then there would be problems. It would be better (and possible) to design the plugin such that this issue did not arise.

@sapista: From Paul’s comments and your description of the problem it seems as though you may have found the particular function call that is mismatched between your distro’s libraries and the ardour bundle, and worked around it by using a different call which just so happens to work in that particular combination. That’s not to say it won’t also work for other users, but if that is the case then I can’t help feeling it could blow up again some time later.

@Paul: The VSTGUI approach is useful, but I don’t think many plugins now use it, because of various limitations - this is always a drawback of a host / SDK provided library. (however, as I’m sure you can appreciate, on just about any other operating system, you can depend on a common ‘toolkit’ being part of the OS so compatibility issues such as these do not normally cause problems. This is something that the diversity of linux makes uniquely far more difficult than it should ever need to be)

@sapista: i have confirmed that the 32 and 64 bit packages of Ardour from ardour.org come with libcairo that is built against libpng and contains the functions cairo_image_surface_create_from_png(). I have also confirmed that the libcairomm that is included also contains the Cairo:: (C++) wrapper equivalents for these functions.