@sapista: There is also something not right with the graph, at 44.1 / 48kHz sample rate, again with a peak filter, the graph shows what appears to be a de-cramped filter response, whereas the real response (using an FFT) is not de-cramped at HF, therefore it could be argued that the graph is implying a better quality filter than that which is actually being used to process the audio.
@sapista: If I switch a single band to a peak filter, and, with music (or tone) playing (it’s easier to hear the effect with music) I sweep the filter frequency from one frequency to another using the control point on the graph, it seems as though nothing has happened, however, if I stop moving the control point, the filter can be heard to move very slowly to its new position. It suggests to me that, if you cannot reproduce it, then there is something (or several) things not being properly initialised - in this case to do with your smoothing / parameter interpolation - and on my system it just happens that this causes the smoothing to default to the longest possible time-constant. This is at 44.1 / 48kHz sample rate with a 512 sample buffer setting for JACK (the latency is far too long to be a JACK buffering issue - other plugins, including my graphical (Black EQ) 
are very responsive by comparison)
@linuxdsp:
about the latency problem. I can not reproduce it neither in ardour 2.8.14 neither ardour 3 beta5. Please can you explaint more detailedly this issue? For sure, fix problems like these is very important to me.
@All who have troubles with GUI (the curve graph)
I found a solution to that problem and it will be fixed in the next revision (beta3)
@ sapista:
Just as LeatusPenguin, I also have the same issue with GUI in Mixbus 2.2
Here’s screenshot attached also:
https://docs.google.com/open?id=0B89XHw6WcgFvZW5BblJNNlhncjA
@sapista: Same GUI problem for me too - works in the binary A2.8.14 from ardour.org, but Mixbus-2.2.0 and A3B5 show the same bug that others have reported.
Great news! I like this EQ, thanks!
@linuxdsp: nothing new; it’s the same thing you and I have been discussing for a long time. Email or see me on IRC if you have questions.
That look totally awesome, good you removed the plotmm dependency, it was hard to compile under some distros.
Thanks!
@LeatusPenguin: all library versions for a2, a3, and Mixbus can be found in the tools/build-gtk-stack script.
FYI, we (Harrison) abandoned Gtk as a suitable plugin GUI toolkit as of the 2.2 release. If you use Gtk, you have to build the plugin to use the exact_same gtk ( both compile-time and run-time) that the host is using. Gtk plugins often work on linux, because the distribution maintainers are building the Ardour and plugin source using the same Gtk. But the new Ardour/Mixbus binaries make this trickier. It becomes nearly impossible to distribute a standalone Gtk binary that works on a given system; and the problem is compounded further on windows and osx due to the differing link methods.
We want our plugins to work on all platforms, and “all” LV2 hosts, so we are using Dave Robillard’s pugl opengl toolkit. This presents its own set of challenges, but our resulting plugins have enjoyed extremely wide support except for a few reported linux setups ( opengl and high-performance audio can be a troublesome combination on linux )
I welcome any interested plugin developers to contact me. I can help you with cross-platform development, get your plugin into the Mixbus binary packages, and add it to our store if you’d like.
-Ben
Hello, I am am on Ubuntu 12.10 (stock kernel). I am using gtkmm 2.4 and gcc 4.7.2. The new beta compiled succesfully, though it had about 4 or 5 errors. I will give it a try soon! Looks like a nice improvement.
I welcome any interested plugin developers to contact me..... get your plugin into the Mixbus binary packages, and add it to our store if you'd like.
How does this affect agreements with plugin developers such as myself who already have products in your store and (in my case) - are charged a significant percentage on sales - but whose products are not currently deployed with the Mixbus binaries?
If this represents a move to a “Mixbus App Store” style model (which is how it appears to me), with more widespread developer involvement, surely there needs to be a uniform agreement regarding pricing / distribution / free plugins etc, and, is it unreasonable to have assumed that if such a move was / is planned, that there might have been some prior consultation before an announcement on a public forum?
OK progress… your updated beta2 version compiles for me with gcc-4.6 but there are a lot of compilation warnings. Thanks for your quick response
I tested it with Ardour 2.8.14 and Ardour 3beta5 and it seems all good…
Somewhat strangely the EQ10 does not work with Ardour3-VST built from the same SVN and built against the same Drobilla libs but that could very easily be a fluke of ArdourVST so probably not something you need to be concerned with.
@sapista: Looks very good, however, it has a severe denormal problem - CPU usage is ‘ok’ with audio, but when I stop the audio, CPU usage increases gradually up to about 60 - 70%
It also has very significant latency when moving the controls? - I swept a peak over a 1KHz tone and thought nothing was happening - however, when I centered the peak over the 1KHz tone and waited for a few seconds the level gradually started to rise (the same test with audio confirms that the filter follows the GUI but with a latency of several seconds)
There were also pages of compiler warnings when I built it - some of which look quite nasty - I think it would be wise to fix those before you go any further with it.
The tarball is a new one with a diferent name. Now you should test the tarball named eq10q-2-beta2.tar.gz. Be shure that you use that and please keep me posted.
@LeatusPenguin
For sure I will try to reproduce your issue to track it down. What is your distro? gcc version? gtkmm version? And… I supose that Mixbus is distributed as static compiled packages, so someone know with which version of gtkmm was compiled mixbus?
I get this output when I run make:
[ 40%] Building CXX object gui/widgets/CMakeFiles/eqwin.dir/eqbutton.cpp.o
In file included from /home/cameron/Desktop/eq10q-2-beta1/gui/widgets/eqbutton.cpp:22:0:
/home/cameron/Desktop/eq10q-2-beta1/gui/widgets/eqbutton.h: In constructor ‘EQButton::EQButton(int, bool*)’:
/home/cameron/Desktop/eq10q-2-beta1/gui/widgets/eqbutton.h:62:11: warning: ‘EQButton::m_bStop’ will be initialized after [-Wreorder]
/home/cameron/Desktop/eq10q-2-beta1/gui/widgets/eqbutton.h:60:16: warning: ‘FilterType EQButton::m_FilterType’ [-Wreorder]
/home/cameron/Desktop/eq10q-2-beta1/gui/widgets/eqbutton.cpp:25:1: warning: when initialized here [-Wreorder]
/home/cameron/Desktop/eq10q-2-beta1/gui/widgets/eqbutton.cpp:86:80: error: cannot call constructor ‘Pango::FontDescription::FontDescription’ directly [-fpermissive]
/home/cameron/Desktop/eq10q-2-beta1/gui/widgets/eqbutton.cpp:86:80: error: for a function-style cast, remove the redundant ‘::FontDescription’ [-fpermissive]
make[2]: *** [gui/widgets/CMakeFiles/eqwin.dir/eqbutton.cpp.o] Error 1
make[1]: *** [gui/widgets/CMakeFiles/eqwin.dir/all] Error 2
make: *** [all] Error 2
That is sweet!
Errors like yours are tipically related to compiler and gtkmm version. I have Developef eq10q under Debian Squeeze which uses older versions than other distros. Now I have to improve de code to be able to buil/run fine for other distros.
Please, what distribuion are u using? What gcc and gtkmm versions?
great news, great plugin. thanks.
Hi, great work, looking forward to checking it out.
I am also having similar compilation problems as Cameron but strangely I’m having issues on AV Linux 6.0 (32bit) which is also based on Debian Squeeze so in this case we should have the same version of gtkmm 2.4 however AV Linux uses gcc 4.6 and Squeeze comes with 4.5 by default. I’ll try a compile with gcc 4.5 and report back.
EDIT
No joy with gcc 4.5 and libgtkmm2.4-dev 2.20.3 here either:
[ 40%] Building CXX object gui/widgets/CMakeFiles/eqwin.dir/eqbutton.cpp.o
/home/glen/Packaging/EQ10/eq10q-2-beta1/gui/widgets/eqbutton.h: In constructor ‘EQButton::EQButton(int, bool*)’:
/home/glen/Packaging/EQ10/eq10q-2-beta1/gui/widgets/eqbutton.h:62:11: warning: ‘EQButton::m_bStop’ will be initialized after [-Wreorder]
/home/glen/Packaging/EQ10/eq10q-2-beta1/gui/widgets/eqbutton.h:60:16: warning: ‘FilterType EQButton::m_FilterType’ [-Wreorder]
/home/glen/Packaging/EQ10/eq10q-2-beta1/gui/widgets/eqbutton.cpp:25:1: warning: when initialized here [-Wreorder]
/home/glen/Packaging/EQ10/eq10q-2-beta1/gui/widgets/eqbutton.cpp:86:80: error: cannot call constructor ‘Pango::FontDescription::FontDescription’ directly [-fpermissive]
/home/glen/Packaging/EQ10/eq10q-2-beta1/gui/widgets/eqbutton.cpp:86:80: error: for a function-style cast, remove the redundant ‘::FontDescription’ [-fpermissive]
make[2]: *** [gui/widgets/CMakeFiles/eqwin.dir/eqbutton.cpp.o] Error 1
make[1]: *** [gui/widgets/CMakeFiles/eqwin.dir/all] Error 2
make: *** [all] Error 2
glen@av6devdesk:~/Packaging/EQ10/eq10q-2-beta1/eq10-lv2-2.0b1avlinux6$
Looks like a cool EQ. Maybe I will try and build this and see how it looks on my Mixbus install.