Which plugin formats are standard in linux today?
Moderators: MattKingUSA, khz
Which plugin formats are standard in linux today?
Hi,
Does anybody has any experience compiling for linux plugins made with juce.com?
Any IDE recommendations? Which is the most standard plugin format today in Linux and which ones allow midi input and output?
Does anybody has any experience compiling for linux plugins made with juce.com?
Any IDE recommendations? Which is the most standard plugin format today in Linux and which ones allow midi input and output?
Last edited by Username0 on Sat May 09, 2020 5:43 pm, edited 1 time in total.
- sadko4u
- Established Member
- Posts: 987
- Joined: Mon Sep 28, 2015 9:03 pm
- Has thanked: 2 times
- Been thanked: 360 times
Re: Which plugin formats are standard in linux today?
I'm using Eclipse + CDT in development process.
Current primary Linux plugin standards are LV2 and LinuxVST, both allow MIDI processing.
I don't recommend to use JUCE, although it's cross-platform, it doesn't support LV2 yet.
Also it has some bugs that probably won't be solved for a long time: https://forum.juce.com/t/cant-make-frie ... gtk2/18120
Current primary Linux plugin standards are LV2 and LinuxVST, both allow MIDI processing.
I don't recommend to use JUCE, although it's cross-platform, it doesn't support LV2 yet.
Also it has some bugs that probably won't be solved for a long time: https://forum.juce.com/t/cant-make-frie ... gtk2/18120
LSP (Linux Studio Plugins) Developer and Maintainer.
-
- Established Member
- Posts: 681
- Joined: Sat Nov 01, 2014 8:15 pm
- Location: The Internet
- Been thanked: 1 time
Re: Which plugin formats are standard in linux today?
I guess DISTRHO is one of the best frameworks for plugins. It can do JACK, DSSI, LV2 and VST. But it doesn't have the ability to reliably work with raw MIDI data and can't do MIDI output yet.
For coding I prefer CodeLite.
For coding I prefer CodeLite.
Re: Which plugin formats are standard in linux today?
Thank you for your answers.
Is LinuxVST simply VST compiled in Linux? Is this what JUCE produces?
Is it an issue with the JUCE host example program or with the plugin itself when you host it in other linux sequencers?
Is LinuxVST simply VST compiled in Linux? Is this what JUCE produces?
Is it an issue with the JUCE host example program or with the plugin itself when you host it in other linux sequencers?
sadko4u wrote:I'm using Eclipse + CDT in development process.
Current primary Linux plugin standards are LV2 and LinuxVST, both allow MIDI processing.
I don't recommend to use JUCE, although it's cross-platform, it doesn't support LV2 yet.
Also it has some bugs that probably won't be solved for a long time: https://forum.juce.com/t/cant-make-frie ... gtk2/18120
Last edited by Username0 on Sat May 09, 2020 5:46 pm, edited 2 times in total.
- sadko4u
- Established Member
- Posts: 987
- Joined: Mon Sep 28, 2015 9:03 pm
- Has thanked: 2 times
- Been thanked: 360 times
Re: Which plugin formats are standard in linux today?
LinuxVST plugins are just plugins that use Steinberg SDK to compile under Linux.Username0 wrote:Is LinuxVST simply VST compiled in Linux? Is this what JUCE produces?
Yes, it's mostly problem of JUCE hosts.Username0 wrote:I read your post and I'm not sure I understood well. Is it an issue with the JUCE host example program or with the plugin itself when you host it in other linux sequencers? I really don't need the JUCE host, I would only like to be able to compile my plugins for linux without having to completely rewrite them...
LSP (Linux Studio Plugins) Developer and Maintainer.
Re: Which plugin formats are standard in linux today?
I like Geany (lightweight IDE) and Vim too.
If JUCE requires a huge IDE to compile programs, it sounds like an overly demanding framework. I try to keep tools & dependencies to a minimum. Good engineering practice.
CMake is the most useful tool for cross-platform C/C++ development IMHO. But I digress....
If JUCE requires a huge IDE to compile programs, it sounds like an overly demanding framework. I try to keep tools & dependencies to a minimum. Good engineering practice.
CMake is the most useful tool for cross-platform C/C++ development IMHO. But I digress....
- mike@overtonedsp
- Established Member
- Posts: 145
- Joined: Mon Apr 24, 2017 5:26 pm
- Location: Oxford, England
- Been thanked: 55 times
- Contact:
Re: Which plugin formats are standard in linux today?
If JUCE requires a huge IDE to compile programs, it sounds like an overly demanding framework...
You can build JUCE from the command line if you so wish. It doesn't need an IDE, thiink of it as a collection of C++ classes
Agreed. Keeping dependencies to a minimum is just about the only way you will ever create something which is actually deployable on a linux system other than the one you developed it on.I try to keep tools & dependencies to a minimum
@sadko4u: I think your approach is wrong. You are trying to force GTK into the JUCE framework, and, whether you perceive that as a 'bug' in JUCE or not, you are going to have problems further down the line, even if you get over that particular issue. Likely you will end up with a 'VST' which only works in a GTK host application (so that kind of excludes any host except Ardour) and more specifically a GTK 'n' application so that means problems with any GTK host which isn't using the exact version of GTK you are using. (It's now just about enshrined in the GTK spec that incompatibility between versions is a design 'feature' which may not help the situation).Also it has some bugs that probably won't be solved for a long time..
For my own plug-ins I developed my own X11 based graphics 'engine'. At the present time this is what you have to do to integrate with a linuxVST host. Fortunately JUCE provides this too, but, you have to use JUCE's UI framework - that's the point of it. So, fundamentally you will have to rewrite your UIs to either use JUCE, or X11 directly. That probably seems like a lot of work (it turns out writing plug-ins is actually quite difficult, especially for linux), but its still probably less work than you will have to do to make GTK work reliably.
LV2 is not the 'magic bullet'. - I've developed for just about all plug-in formats on all the main OS at one time or another and the only thing that holds true is that no plug-in API is ideal, and likely there will never be one which is. Many developers don't like VST for linux because of the licensing, but there are indications that is changing. I suspect LV2 will always have a problem gaining acceptance outside of Linux. Fundamentally it exists to (try) and solve some very linux specific issues. Outside of that there is no essential reason for it on any other platform. For it (or any other new) format to gain acceptance, you would have to write a 'must have' plug-in, and, then decide to only release it in a format that just about no-one supports. For reference look how long it has taken for Steinberg's own VST3 standard to gain acceptance.
This isn't anti-LV2 or pro VST, its just based on my experience.
Plug-in developer - Applied Computer Music Technologies / OverTone DSP
- sadko4u
- Established Member
- Posts: 987
- Joined: Mon Sep 28, 2015 9:03 pm
- Has thanked: 2 times
- Been thanked: 360 times
Re: Which plugin formats are standard in linux today?
You're right because I've really failed with choosing the tookit for building UIs. I went the way like Calf or Invada or Amsynth did and used GTK2. But the other side of the medal that is relative to compatibility with hosts was bad. First I learnt how to do funny custom controls with GTK2 and now I accept that I could spend just a bit more time for developing my own toolkit under X11. So now I need to spend the same amount of time again while porting all widgets to X11.mike@overtonedsp wrote:@sadko4u: I think your approach is wrong. You are trying to force GTK into the JUCE framework, and, whether you perceive that as a 'bug' in JUCE or not, you are going to have problems further down the line, even if you get over that particular issue.Also it has some bugs that probably won't be solved for a long time..
That's right, too. I'm already working on my own TK.mike@overtonedsp wrote: For my own plug-ins I developed my own X11 based graphics 'engine'. At the present time this is what you have to do to integrate with a linuxVST host. Fortunately JUCE provides this too, but, you have to use JUCE's UI framework - that's the point of it. So, fundamentally you will have to rewrite your UIs to either use JUCE, or X11 directly. That probably seems like a lot of work (it turns out writing plug-ins is actually quite difficult, especially for linux), but its still probably less work than you will have to do to make GTK work reliably.
I also mentioned many problems of LV2 and VST 2.x and 3.x in other topics. The main disadvantage of LV2 is it's complexity. It's hard to code something using 'raw' specs until you get and read some examples. I don't understand the need to write RDF, especially when modern plugin standards allow to implement plugins with changeable number of inputs and outputs.mike@overtonedsp wrote: LV2 is not the 'magic bullet'. - I've developed for just about all plug-in formats on all the main OS at one time or another and the only thing that holds true is that no plug-in API is ideal, and likely there will never be one which is. Many developers don't like VST for linux because of the licensing, but there are indications that is changing. I suspect LV2 will always have a problem gaining acceptance outside of Linux. Fundamentally it exists to (try) and solve some very linux specific issues. Outside of that there is no essential reason for it on any other platform. For it (or any other new) format to gain acceptance, you would have to write a 'must have' plug-in, and, then decide to only release it in a format that just about no-one supports. For reference look how long it has taken for Steinberg's own VST3 standard to gain acceptance.
This isn't anti-LV2 or pro VST, its just based on my experience.
LSP (Linux Studio Plugins) Developer and Maintainer.
-
- Established Member
- Posts: 315
- Joined: Mon Jan 02, 2017 9:46 am
- Has thanked: 1 time
- Been thanked: 5 times
Re: Which plugin formats are standard in linux today?
It's not all doom and gloom though.sadko4u wrote:You're right because I've really failed with choosing the tookit for building UIs. I went the way like Calf or Invada or Amsynth did and used GTK2. But the other side of the medal that is relative to compatibility with hosts was bad. First I learnt how to do funny custom controls with GTK2 and now I accept that I could spend just a bit more time for developing my own toolkit under X11. So now I need to spend the same amount of time again while porting all widgets to X11.mike@overtonedsp wrote:@sadko4u: I think your approach is wrong. You are trying to force GTK into the JUCE framework, and, whether you perceive that as a 'bug' in JUCE or not, you are going to have problems further down the line, even if you get over that particular issue.Also it has some bugs that probably won't be solved for a long time..
That's right, too. I'm already working on my own TK.mike@overtonedsp wrote: For my own plug-ins I developed my own X11 based graphics 'engine'. At the present time this is what you have to do to integrate with a linuxVST host. Fortunately JUCE provides this too, but, you have to use JUCE's UI framework - that's the point of it. So, fundamentally you will have to rewrite your UIs to either use JUCE, or X11 directly. That probably seems like a lot of work (it turns out writing plug-ins is actually quite difficult, especially for linux), but its still probably less work than you will have to do to make GTK work reliably.
I also mentioned many problems of LV2 and VST 2.x and 3.x in other topics. The main disadvantage of LV2 is it's complexity. It's hard to code something using 'raw' specs until you get and read some examples. I don't understand the need to write RDF, especially when modern plugin standards allow to implement plugins with changeable number of inputs and outputs.mike@overtonedsp wrote: LV2 is not the 'magic bullet'. - I've developed for just about all plug-in formats on all the main OS at one time or another and the only thing that holds true is that no plug-in API is ideal, and likely there will never be one which is. Many developers don't like VST for linux because of the licensing, but there are indications that is changing. I suspect LV2 will always have a problem gaining acceptance outside of Linux. Fundamentally it exists to (try) and solve some very linux specific issues. Outside of that there is no essential reason for it on any other platform. For it (or any other new) format to gain acceptance, you would have to write a 'must have' plug-in, and, then decide to only release it in a format that just about no-one supports. For reference look how long it has taken for Steinberg's own VST3 standard to gain acceptance.
This isn't anti-LV2 or pro VST, its just based on my experience.
Your plugin GUI's look pretty good, it's just that the gtk conflicts with some hosts.
Linux Reaper with a GDK3 compiled libswell.so crashes when the lsp vst plugins are used and Linux Reaper with a GDK2 compiled libswell.so acts strangely when the lsp vst plugins are loaded and gtk events don't run normally.
Linux Tracktion freezes the lsp vst controls.
I've been able to get the lsp vst plugins running fine in Linux Reaper and Linux Tracktion by running the lsp vst plugins remotely and that way the toolkit doesn't matter (works for the amsynth vst as well).
There is not much of a speed slowdown (if at all) doing it remotely btw.
https://github.com/osxmidi/LinVst/tree/linux
- sadko4u
- Established Member
- Posts: 987
- Joined: Mon Sep 28, 2015 9:03 pm
- Has thanked: 2 times
- Been thanked: 360 times
Re: Which plugin formats are standard in linux today?
Anyway, it's not good. According to many responses from users related to problems of LSP Plugins UI with JUCE-based hosts, Reaper, Renoise and Bitwig Studio, I think GTK2 is a dead end. I'll concentrate on development of toolkit. I have already some sort of progress:ubuntuuser wrote:It's not all doom and gloom though.
Your plugin GUI's look pretty good, it's just that the gtk conflicts with some hosts.
Linux Reaper with a GDK3 compiled libswell.so crashes when the lsp vst plugins are used and Linux Reaper with a GDK2 compiled libswell.so acts strangely when the lsp vst plugins are loaded and gtk events don't run normally.
Linux Tracktion freezes the lsp vst controls.
I've been able to get the lsp vst plugins running fine in Linux Reaper and Linux Tracktion by running the lsp vst plugins remotely and that way the toolkit doesn't matter (works for the amsynth vst as well).
There is not much of a speed slowdown (if at all) doing it remotely btw.
https://github.com/osxmidi/LinVst/tree/linux
LSP (Linux Studio Plugins) Developer and Maintainer.
-
- Established Member
- Posts: 315
- Joined: Mon Jan 02, 2017 9:46 am
- Has thanked: 1 time
- Been thanked: 5 times
Re: Which plugin formats are standard in linux today?
Your plugins came up at the Reaper forum where someone was trying to use them in Linux Reaper.sadko4u wrote:Anyway, it's not good. According to many responses from users related to problems of LSP Plugins UI with JUCE-based hosts, Reaper, Renoise and Bitwig Studio, I think GTK2 is a dead end. I'll concentrate on development of toolkit. I have already some sort of progress:ubuntuuser wrote:It's not all doom and gloom though.
Your plugin GUI's look pretty good, it's just that the gtk conflicts with some hosts.
Linux Reaper with a GDK3 compiled libswell.so crashes when the lsp vst plugins are used and Linux Reaper with a GDK2 compiled libswell.so acts strangely when the lsp vst plugins are loaded and gtk events don't run normally.
Linux Tracktion freezes the lsp vst controls.
I've been able to get the lsp vst plugins running fine in Linux Reaper and Linux Tracktion by running the lsp vst plugins remotely and that way the toolkit doesn't matter (works for the amsynth vst as well).
There is not much of a speed slowdown (if at all) doing it remotely btw.
https://github.com/osxmidi/LinVst/tree/linux
So I did a quick fix that enables them in Linux Reaper and Linux Bitwig (and it also works in Linux Tracktion with a standalone window) https://github.com/osxmidi/LinVst/tree/linux
Until you can get the plugins ported to X11, at least maybe some users might find my quick fix helpful.
Gtk/Gdk is great for a lot of things but it turns out not so for audio stuff (20/20 hindsight), especially for vst's and the various Linux hosts.
Last edited by ubuntuuser on Sun Jun 04, 2017 8:01 am, edited 7 times in total.
Re: Which plugin formats are standard in linux today?
Cool. I don't know if the controls actually work but it looks fine.sadko4u wrote:Anyway, it's not good. According to many responses from users related to problems of LSP Plugins UI with JUCE-based hosts, Reaper, Renoise and Bitwig Studio, I think GTK2 is a dead end. I'll concentrate on development of toolkit. I have already some sort of progress:
I wonder if OpenGL is a good option for plugin GUIs. SetBFree uses it for 3D but it's fine for basic 2D too. The hard part would be to replicate common GUI elements, and text rendering is surprisingly complicated, but there are some libs for that. Compatibility might be a problem too, though I imagine any system capable of running a DAW would support at least OpenGL 2.1.
- mike@overtonedsp
- Established Member
- Posts: 145
- Joined: Mon Apr 24, 2017 5:26 pm
- Location: Oxford, England
- Been thanked: 55 times
- Contact:
Re: Which plugin formats are standard in linux today?
At present, if you want ot use openGL in a plug-in GUI, that means GLX, which means once you've written an openGL rendering engine, including all the shaders, and programmable pipeline stuff (I've also had to do this for some of my plug-ins, which is not trivial, unless you want to rely on yet another stack of dependencies and potential third-party library conflicts ).I wonder if OpenGL is a good option for plugin GUIs...
You then still have to write the X11 toolkit to provide it with something to render into, and to handle the user IO. Plus you then have the added bonus of unreliable or at least inconsistent linux openGL drivers, on top of X11, (which already has some problems with stability). On the plus side, you get hardware acceleration, which means the empty / black window you will get most of the time will look great in 4K.
(You will also need a collection of graphics cards of different vintages if you want to have a hope of creating shaders that will 1. actually compile at all, and
2. do something useful on anyone elses machine.)
Plug-in developer - Applied Computer Music Technologies / OverTone DSP
Re: Which plugin formats are standard in linux today?
There are some tools that could help with openGL, but none of them have reached a stable relase. 1st is pugl http://drobilla.net/software/pugl which is a minimal opengl and event api. I don't know a ton about openGL so maybe it wouldn't actually change any of the challenges mike pointed out, but it also has a cairo backend. That is what is used in OpenAV plugins and I am slowly moving the infamous plugins to that. It at least abstracts x11 so you can be cross platform and not strictly dependent on old API. I believe DISTRHO also uses pugl but with openGL drawing. So there are quite a few examples you can look at.
There is also a toolkit being developed for openGL called rutabaga. Its still a work in progress, but it has some good capability already and if you are considering rolling your own anyway, give it a look: https://github.com/wrl/rutabaga/ . The dev is quite open to collaboration or adding what you might need. I know it has some styling capability already so maybe it will work.
There is also a toolkit being developed for openGL called rutabaga. Its still a work in progress, but it has some good capability already and if you are considering rolling your own anyway, give it a look: https://github.com/wrl/rutabaga/ . The dev is quite open to collaboration or adding what you might need. I know it has some styling capability already so maybe it will work.
_ssj71
music: https://soundcloud.com/ssj71
My plugins are Infamous! http://ssj71.github.io/infamousPlugins
I just want to get back to making music!
music: https://soundcloud.com/ssj71
My plugins are Infamous! http://ssj71.github.io/infamousPlugins
I just want to get back to making music!
-
- Established Member
- Posts: 165
- Joined: Thu Nov 07, 2013 1:19 pm
- Been thanked: 1 time
Re: Which plugin formats are standard in linux today?
+1 to PUGL. I've used PUGL+nanovg+glLoadGen to handle platform specifics and to make openGL much more approachable in the Zyn-Fusion GUI. PUGL isn't perfect, but it gets you most of the way there in terms of just being able to use a GL context. For the Zyn UI I ended up sticking to OpenGL 2.1 core+frame buffers which is old enough that the vast majority of people are able to use the interface (be prepared to hear about some complaints if you pick a recent GL version).
I think using OpenGL for plugin UIs is a good approach overall, though it does end up being more of a programming challenge than trying to use a more traditional GUI library.
I think using OpenGL for plugin UIs is a good approach overall, though it does end up being more of a programming challenge than trying to use a more traditional GUI library.
ZynAddSubFX maintainer