Which plugin formats are standard in linux today?

Programming applications for making music on Linux.

Moderators: MattKingUSA, khz

Username0
Established Member
Posts: 5
Joined: Sun Apr 09, 2017 9:29 pm
Contact:

Which plugin formats are standard in linux today?

Post by Username0 »

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?
Last edited by Username0 on Sat May 09, 2020 5:43 pm, edited 1 time in total.
User avatar
sadko4u
Established Member
Posts: 986
Joined: Mon Sep 28, 2015 9:03 pm
Has thanked: 2 times
Been thanked: 359 times

Re: Which plugin formats are standard in linux today?

Post by sadko4u »

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
LSP (Linux Studio Plugins) Developer and Maintainer.
Lyberta
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?

Post by Lyberta »

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.
Username0
Established Member
Posts: 5
Joined: Sun Apr 09, 2017 9:29 pm
Contact:

Re: Which plugin formats are standard in linux today?

Post by Username0 »

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?
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.
User avatar
sadko4u
Established Member
Posts: 986
Joined: Mon Sep 28, 2015 9:03 pm
Has thanked: 2 times
Been thanked: 359 times

Re: Which plugin formats are standard in linux today?

Post by sadko4u »

Username0 wrote:Is LinuxVST simply VST compiled in Linux? Is this what JUCE produces?
LinuxVST plugins are just plugins that use Steinberg SDK to compile under Linux.
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...
Yes, it's mostly problem of JUCE hosts.
LSP (Linux Studio Plugins) Developer and Maintainer.
tnovelli
Established Member
Posts: 277
Joined: Wed Apr 20, 2011 4:52 pm

Re: Which plugin formats are standard in linux today?

Post by tnovelli »

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....
User avatar
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?

Post by mike@overtonedsp »

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
I try to keep tools & dependencies to a minimum
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.
Also it has some bugs that probably won't be solved for a long time..
@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).
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.
User avatar
sadko4u
Established Member
Posts: 986
Joined: Mon Sep 28, 2015 9:03 pm
Has thanked: 2 times
Been thanked: 359 times

Re: Which plugin formats are standard in linux today?

Post by sadko4u »

mike@overtonedsp wrote:
Also it has some bugs that probably won't be solved for a long time..
@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.
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: 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.
That's right, too. I'm already working on my own TK.
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.
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.
LSP (Linux Studio Plugins) Developer and Maintainer.
ubuntuuser
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?

Post by ubuntuuser »

sadko4u wrote:
mike@overtonedsp wrote:
Also it has some bugs that probably won't be solved for a long time..
@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.
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: 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.
That's right, too. I'm already working on my own TK.
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.
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.
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


Image
User avatar
sadko4u
Established Member
Posts: 986
Joined: Mon Sep 28, 2015 9:03 pm
Has thanked: 2 times
Been thanked: 359 times

Re: Which plugin formats are standard in linux today?

Post by sadko4u »

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


Image
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:

Image
LSP (Linux Studio Plugins) Developer and Maintainer.
ubuntuuser
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?

Post by ubuntuuser »

sadko4u wrote:
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


Image
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:

Image
Your plugins came up at the Reaper forum where someone was trying to use them in Linux Reaper.

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.
tnovelli
Established Member
Posts: 277
Joined: Wed Apr 20, 2011 4:52 pm

Re: Which plugin formats are standard in linux today?

Post by tnovelli »

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:
Cool. I don't know if the controls actually work but it looks fine. :D

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.
User avatar
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?

Post by mike@overtonedsp »

I wonder if OpenGL is a good option for plugin GUIs...
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 ).
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.)
ssj71
Established Member
Posts: 1294
Joined: Tue Sep 25, 2012 6:36 pm
Has thanked: 1 time

Re: Which plugin formats are standard in linux today?

Post by ssj71 »

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.
_ssj71

music: https://soundcloud.com/ssj71
My plugins are Infamous! http://ssj71.github.io/infamousPlugins
I just want to get back to making music!
fundamental
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?

Post by fundamental »

+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.
ZynAddSubFX maintainer
Post Reply