EQ10Q 2.0 Plugins Released

I would like to share with you that EQ10Q plugin bundle has finally reached a release state. I’ve just released the first stable version of this plugins with the version number 2.0. The main advantage of this release is that the Beta testing procedure is finished. But it also includes the following new features:

  • Mid/Side matrix plugins
  • (CS10QM & CS10QM) Added Feedback compression mode (side-chain signal is picked from output instead of input)
  • Added mid/side modes in EQ10Q stereo versions
  • GUI optimizations
  • Improved FFT drawings
  • Added dry/wet in dynamics plugins (compressor and gate)
  • Added zoom and scroll for the eq plot window

I strongly encourage every Ardour user to visit my website to obtain the last version of the plugin bundle and a full description of its features.

Excellent! Thanks!

Great stuff! Brilliant plugin.

Thanks Sapista.

Amazing suite, keep up the great work!
I am going to install 2.0.

Wow Sapista I just installed your plugins and I have to say this is turning out to be a really nice set of plugins!! I just used it to mix a little and it was a breeze. It does what I expected it to do. The only thing I’d like to see added is an expander option maybe in the gate plugin. Awesome work!

These plugins look great!

Thanks you all for the support to eq10q project.
@dsreyes1014: I’m working on 2.1 version which will include some fixes and new wanted features like expander included inside the gate plugin and sidechain compressor. All of this is implemented on development branch, but I have to performe more testing before realeasing 2.1. However if someone can test it from svn i will be happy to hear his comments about.

sapista: No worries sapista. Just sent a small thank you donation. Keep up the good work.

Hey Sapista, just letting you know the feedback mode on the compressor is incredible. I’ve been using that in place of the TDR Kotelnikov, and it’s very close!
Are there any plans in the future to turn the feedback toggle into a feedback slider/knob? I noticed that if you open the plugin with Ardour’s generic UI it provides not an on/off switch, but a slider.

I tried building these, and got some errors part way though the make.
(lots of successsful “built target” messages, then…)
[ 79%] Built target eqwin
[ 79%] Linking CXX executable …/bin/eq10q_gui_tester
…/bin/libeqwin.a(bandctl.cpp.o): In function BandCtl::BandCtl(int, bool*, char const*, bool)': bandctl.cpp:(.text+0x55d): undefined reference toGdk::Pixbuf::create_from_file(std::string const&)’
bandctl.cpp:(.text+0x657): undefined reference to Gdk::Pixbuf::create_from_file(std::string const&)' bandctl.cpp:(.text+0x751): undefined reference toGdk::Pixbuf::create_from_file(std::string const&)’
bandctl.cpp:(.text+0x84b): undefined reference to Gdk::Pixbuf::create_from_file(std::string const&)' bandctl.cpp:(.text+0x945): undefined reference toGdk::Pixbuf::create_from_file(std::string const&)’
…/bin/libeqwin.a(bandctl.cpp.o):bandctl.cpp:(.text+0xa3f): more undefined references to Gdk::Pixbuf::create_from_file(std::string const&)' follow ../bin/libeqwin.a(bandctl.cpp.o): In functionBandCtl::drawBandButton(BandCtl::Button*, Cairo::RefPtrCairo::Context)’:
bandctl.cpp:(.text+0xc862): undefined reference to Glib::ustring::ustring(std::string&&)' bandctl.cpp:(.text+0xcf61): undefined reference toGlib::ustring::ustring(std::string&&)’
(many more error messages like the above)
This is on AV Linux 2016, 64 bit.

“make install” did install the packages that had been built, but Ardour crashed as soon as one plugin was inserted.
By the way, I couldn’t find an email address to contact you (sapista) on the SF web site.

Some progress… after removing libgtkmm-3.0 so the build had to use v2.4, and doing a system upgrade to current Debian testing (lots of changes), the plugins now build and install, and Ardour (current V4.7) loads them.
But there’s no GUI, only the generic UI.
Does anyone recognise that symptom?

You have a gcc4/gcc5 mixup. Plugins like these which use C++ must be compiled with the same version of gcc as Ardour. We offer gcc5 builds on http://nightly.ardour.org/ and will do so for the next major release. Releases to this point are all built with gcc4; your version of these plugins was built with gcc5.

I discovered that, and rebuilt the plugins with gcc4, but still no luck.
I could get a nightly of Ardour with gcc5, but then wouldn’t all my other plugins that worked before stop working?
…though this might explain why one or two LinuxDSP plugins switched to generic GUI when I installed AVLinux 2016.
I’ll try both with gcc5 versions anyway, and see what happens…

Both Ardour gcc5 version and eq10built with gcc5 still didn’t work for me. But Gmaq pointed out that the ready-built package would also be available from the KXstudio repository, and that has now been upgrade to V2, I’ve installed that and it is now working properly. I may never know why my own build wouldn’t show the native GUI.

Very nice it looks too.

@anahata: this issue only affects plugins that use C++ (and even then, not all of them).

I managed to get this to build from soucecode in my Fedora 23 system. It works great in Ardour 4. Very nice job! However, the GUIs will not open in Mixbus v3.3. Any guesses on why this may be?

@sapista: how deeply is EQ10Q entrenched into gkmm?

Would it be unreasonable to move away from external dependencies that cannot be linked statically? Ideally Plugins are completely self-contained and don’t rely on external ABI compatibility.

Ardour already does to great length (gcc4/gcc5) on Linux only because of about 12 plugins that use external libs which are not ABI compatible. If plugins were self-contained, there’d be no need for that (libstdc++ itself is ABI compatible. Only derived libs like sigc++, gtkmm etc are not). There is also the issue that QT4/5 and gtk2/3 can’t co-exist in the same memory space and that statically linking them is not feasible. and with gtk4 on the verge things will only get worse. Really the sooner plugins move away from /big toolkits/ the better. On all other platform that’s already common practice for Audio Plugins.

Looking at the EQ10Q UI it does not strike me as if anything gtkmm related is really needed. They’re all custom widgets and it uses no “complex” widget such as File-Browser or Treeview (those are holding back Ardour moving away from GTK). It’d be great if you would consider dropping gtkmm in future versions, and as side-effect make the plugin UI portable.

@x42: Well, eq10q’s gui is laid out using gtkmm boxes, all widgets are drawn using cairomm placed in gtk::drawingAreas. Moreover, all signals and slots are implemented using the gtkmm model, so libsigc++ is heavily used. So, I’m afraid that eq10q is deeply entrenched into gtkmm.

In my opinion, developing plugins completely self-contained will be a great think. But to achieve that, some kind specification should be provided by LV2 standard in order to assure the ABI compatibility between plugins and hosts that faithfully implement such spec. Another option is the linux-software classic approach: developers provides code and distributions care about putting all together and make them work. Binaries obtained from ardour.org are clearly against the second model, because all required libraries are provided inside the pack so any plugin that use some lib from the running linux distro with an ABI incompatibility to ardour provided lib will fail.

I’ve been thinking about migrating all the gui code to another graphic toolkit in order to provide a better compatibility with ardour.org binaries. However, it’s difficult to establish the great balance between “binary compatibility” and “great-gui development using powerfull gui tools as gtkmm”. Which toolkit is recommended to develop GUI’s for plugins? GTK, JUCE, directly X…? @Ardour dev’s: Do you think that some king of spec/recommendation should be wirted to plugin dev’s in order to avoid such kind of issues?

At present the only real recommendation we can give is “do not use GTK or Qt”. x42 has a few other ideas in mind, but as far I know none of them are ready to be actual recommendations yet. Another thing that is an important part of the considerations is that many plugin developers want something that will work cross-platform, which rules out using X directly (along with using Cocoa or Windows GDI etc.)

LV2 does not cover plugin GUIs with anything like the detail that would be needed to provide ABI compatibility. And even if it did, that would just ensure that, for example, a Qt4 host could not open a Qt5 plugin GUI, which might be better than a crash, but doesn’t do much to ensure the situation for users.

@paul: Thanks for your answer, but I still have a doubt. If the use of GTK and QT is completely discouraged, then what is recommend for handling mouse events and layout various widgets in the plugin window? And if I choose some lib to handle all of that and works nice with current ardour’s binaries, how we can keep ABI compatibility for future versions?