I just wanted to let people know, that the linuxDSP graph-eq is now available as both a mono and stereo LV2 plugin, along with a few minor bug fixes (notably an initialisation problem with the graph Q settings which somehow crept through testing…) this is a free upgrade if you already have the original version. I regret that it has become necessary to charge for the plugins, but unfortunately the site simply cannot afford to exist any other way. The reality is that I’m sure most people expect to get paid for the work they do, and so do I, but I hope it still represents very good value - and the JACK client plugins are still free. As usual, the site is here:
hi linuxdsp, great stuff! I bought the activation key and all is fine.
I just noticed though that when you drag one of the candy looking ball to the graph limit, you lose the mouse focus/grab so you cannot drag it back inside unless you click again on the candy thing. Otherwise, great stuff, smooth, no zip affect, and CPU footprint is reasonable. Just need an FFT display now, or is it too much to ask 
ah yeah, one thing: when a freq. band is set up to “flat”, dragging the ball has no effect. But could you actually extrapolate how a flat variation within the freq. band would modify the overall curve ?
@djam: Thanks, glad its working well for you, all the plugins continue to evolve, so I will be looking at some of the things you have mentioned, (and the plan is for future upgrades to be available at no extra cost). Regarding the FFT display, I’ve been looking at ways to do that within the limitations of the LV2 format but for various reasons this appears not as straight forward as it might first seem to be. In a native linux VST format plugin for example, this would be no problem at all so I may experiment with that first and then see if there is a way to get it into the current LV2 format or perhaps there is a need for an extension to the LV2 format that can provide the required functionality.
w.r.t LV2, time will tell. In any case, thanks for the plugins
@linuxdsp: i’m pretty sure the fft display works within the LV2 framework - if i remember correctly, the problem was to get data from the plugin to its GUI. I still have some lines of code that sort of solved that problem, but i didn’t look at it for a year and i’m not a real programmer in the first place 
If you are interested in the code, write an email to robert-schwede@gmx.elephant.de (omit the animal)
@robsch: That is exactly the problem. There are various reasons that complicate the process of transfering either the raw data or the FFT bins to the GUI for display, and to be fair, these are not necessarily all to do with LV2 as such, but in some ways represent the deeper aspects of the linux / Xwindows architecture that complicate the issue of providing a plugin GUI that will display correctly independent of the host UI toolkit (e.g. GTK or Qt) (which is where most of the UI development effort has been concentrated in my plugins since I believe it is essential that the UI displays equally well in a GTK host such as ardour or a Qt host such as Qtractor - or any other UI library the host might use for that matter e.g. SDL, XLib, etc etc).
@linuxdsp: maybe i’m not up to date, but i believe that you need to choose a toolkit (GTK that was in my case) to make a (individual) LV2 plugin gui?
However, this seems to be a problem about how to display the data, not how to get it. With http://lv2plug.in/ns/ext/data-access/ it should be possible from the plugin GUI to obtain something like a pointer to the FFT bins that have been calculated by the plugin.
I’m surely missing something here, but probably #lad is a better place to discuss this.
Thanks, I’ll have a look at the data-access extension, that maybe useful - the problem I have isn’t how to display the data, its how to transfer it from the DSP code to the GUI code using the existing LV2 port scheme, so that extension might provide a way (assuming all host applications support it… otherwise there are a whole lot more compatability problems where one host works and another doesn’t etc and I already spend a disproportionate amount of my time trying to avoid those sorts of problems…)
Regarding toolkits, you can ‘choose’ a toolkit, but if you do then the plugin GUI will only normally display in a host that uses that toolkit also (unless you use the external_UI extension which allows the GUI to launch in a separate process). My method for providing the GUI means that it does not need to launch the UI in a separate process, and therefore avoids the need to arrange IPC between the DSP code and the GUI, but it also allows the GUI to function irrespective of the toolkit the host application uses.
are you saying that you are using something like xlib ? wouldn’t it be “hardcore” GUI programming ? (just asking, I never used X libs directly).
For the LV2 GUIs I’m using a toolkit that I created which uses XLib directly, and yes you could say it’s a bit ‘hardcore’ and I know there are some people who class using XLib as lunatic behaviour But it does have some benefits, the main one being that the GUIs are now ‘host toolkit agnostic’ and also given the relatively small subset of features that I need for the plugin GUIs it also reduces a lot of the dependencies that can quickly grow from using something like GTK or Qt (though the JACK plugins do use GTK - but mainly for historical reasons - since they are standalone and therefore don’t run into the same issues with host toolkit compatibility). It also means that I can create linux VST plugins without too much difficulty - since they have to be created using an XLib based GUI (I could use something like JUCE, but there are a lot of things in that I don’t need, and I wanted to avoid having my plugins looking like yet more generic JUCE style plugins).
@linuxdsp: torben hohn has been doing some work on fixing this issue. the basics of hosting a Qt plugin in a GTK host are already done. We’ve been debating with dave robillard the best way to make this kind of functionality available for hosts (and plugins, should that be necessary).
Hello to all,
This my first post here
@Paul: It’s good to hear that there is work going on regarding the LV2 GUI issues.
When can we expect to hear something about the outcome of your discussions?
@linuxdsp: I’m new to GUI programming. I always thought that every Toolkit for X11
is using Xlib, isn’t it?
What are basic differences then between JUCE and GTK regarding the underlying Xlib usage?
Why must a VST-plugin use Xlib? Because as far as I know the first port of Steinbergs VSTGUI
to Unix (I think it was actually Irix) was done with Motif.
Or the other way round: Can a VST-plugin for Linux or even a LV2 plugin for Ardour be written
with Motif?
I’m currently looking for the best fitting GUI toolkit for LV2 plugins, however, I think, Xlib
would definitely be a job for a full time plugin programmer
Michael
@sigma6: Just to clarify, you’re right, just about every toolkit uses XLib eventually (although it doesn’t have to since XLib is just a convenient library of functions to handle the X protocol to talk to the X-server, so if you were particularly masochistic you could write a complete re-implementation of XLib and I think that is essentially what XCB is all about although I believe most distros can use an XLib - XCB wrapper to maintain compatiblity with XLib based toolkits and applications… But I digress)
So what you have is something like GTK which provides higher level functions for dealing with the normal screen-furniture, windows and widgets and that communicates with the X Server using Xlib. I’ve chosen to write my own toolkit which uses XLib functions directly.
You’re correct that the original steinberg VST GUI for linux used motif, and this is a similar concept to using other toolkits, since motif is basically another abstraction of the XLib functionality into a higher level library, but typically in a linux VST the GUI editor gets passed a host XWindow ID and an XLib Display* with which to create its GUI, and for that and various other more complex reasons it seemed easier to me to just build a GUI toolkit that I could use which talked to XLib at this level rather than trying to force some of the lower level functionality I needed into a GTK or Qt based implementation.
Basically I use XLib because its the lowest common denominator, so you can just about guarantee it will be there - for the time being at least - regardless of the host implementation. I’m also trying to keep dependencies to a minimum, even though sometimes that seems like re-inventing the wheel, its a balance between that and creating things that depend on too many - sometimes large - external dependency ‘trees’. Especially when the subset of functions that are needed is sometimes only a small fraction of the library(s).