In last few days/weeks I was gaining more and more interest in learning how to programm LV2 plugins. I come from a web development background, so I have programming experience. I’m just starting to transfer that over to C/C++ and Turtle.
As I realized, in Ardour 8.X the Calf Plugins where no longer available, due to GTK2 deprecation. So I researched a little on programming LV2 plugins and found the YT channel of this guy https://www.youtube.com/watch?v=Mp58M9ZGeSs and in this video he speaks about why neither GTK2 nor GTK3 are valid options for the UI … nor is Qt, because of the problem with static and dynamic linking.
Basically every UI framework has potential linking problems with one software or another. Whether it’d be Ardour, Audacity or some other LV2 host.
The guy in the video is promoting his own framework BWidgets but since I’m fairly new to C/C++ UI programming I can not really estimate how cross-host and future proof that solution is, as opposed to the other ones like GTK, Qt.
Is there a framework that is a reliable, cross-host and rather future proof base to build LV2 userinterfaces?
Since I’m just starting out with LV2 programming, I don’t have anything big planned so far, I just wanna make sure to start in the right place
You hit the big million-dollar question of FLOSS plugin development.
A while ago I started some notes with a survey of existing widgets toolkits, which would be suitable for audio plugins in general and for using with the DISTRHO Plugin Framework in particular.
I just added a section to these notes listing the desirable traits such a toolkit should have and which would be nice to have. I do not make any claims of completeness for either this bullet-point list or the list of libraries.
In a nutshell, AFAIK, there is no library, that ticks all the boxes.
Well “best” depends on how you define “good” for the issue at hand.
and not just that. Those desktop toolkits offer nothing relevant for audio plugin UIs. No knobs, no VU meters, no waveform display etc…
Nor do general purpose widgets support touch start/stop events, or external updates when the host automates parameters that are not currently being touched.
If you look at plugins in general, none of them use any desktop toolkits on any platform. Even Apples own AUs don’t use common Cocoa buttons (usual exceptions apply).
Not just F/LOSS. Pretty much every proprietary plugin company faces the same issue and most either just roll their own framework or use JUCE.
–
tl;dr: If you want a kitchen sink framework, and not just a simple basic event system for your own widgets, then I suppose either DPF or JUCE is the way to go.
Thanks guys. I’ve been looking into JUCE and DPF the last days.
First of all that looks really nice and like the somewhat future proof solutions I was looking for, only that I now have troubles finding out which one to focus on.
JUCE seems like it’s a little too feature rich and overboard, quite a big package to pick up. But at the same time I can find a lot more learning material for JUCE than for DPF.
However, I still think I will try DPF first and see how far I can get with that. There is this presentation from FalkTX, demoing the process of plugin creation with DPF , that looks very interesting and at least to a noob like me, it looks like a little shallower learning curve.
