Hey guys, I wanted to start this thread so you all could link your favorite linux VSTs. I don’t have any that I know of… maybe I can go back and check some of the many VSTs I own and see if there’s some Linux download options?
I’m curious to just see what works… because most of my VSTs have like 50 knobs or 100 functions… how does that get allocated in the SSP? Or, does it just simply pick presets? How do we choose what we modulate in the presets?
So many questions. wish I had more time to figure it out
The primary goal of the VST support has been to provide a way for people who want to make their own modules. As far as loading existing VST plugins:
I do think there are some linux ARM VST plugins already out there, ready to go, but the user interface dimensions might not fit the SSP’s 1600x480 screen resolution, unless the interfaces are dynamically resizable. For example user interfaces which are made up of fixed-resolution bitmap elements (like knobs) might not be dynamically resizable, which means you would not see the full user interface on the SSP’s screen.
There are probably hundreds of (open source) VST projects, which can be compiled for linux and ARM. I haven’t had a chance to look at any of them. It has been a very intense week getting all this done and pushed out. More info and how-to’s will become available as we go forward.
@bert yeah so that was very very unclear in the recent update. While it’s cool that it’s capable… it’s also not functional for us. I realize it’s a step by step process. because guys like me, can’t just compile something. We don’t know what that means. I’m going to be waiting for you or someone else to compile. While I’m happy it’s an option, I still can’t really use it
I disagree, it was written in bold in the update that you cannot just run any mac or windows VST on the SSP and that the plugins have to be compiled for linux and ARM. Running binaries compiled for intel on ARM is theoretically possible but just way to slow IMHO for anything audio DSP.
I have no idea how many linux VST plugins are available, compiled for ARM. Like I said, we had a really intense week and we have had no time at all to look into this. I’m sure there will be more and more since ARM CPUs are becoming more and more present even in normal laptops and computers. I know that U-he is one of the companies who has released Linux VST plugins, so it’s only natural that they also start supporting ARM in the future. iPhones, iPads and virtually every smartphone uses an ARM CPU, so it’s not like there are no projects or code bases out there that can with a small effort run on the SSP.
We went through the effort to provide an open source quad VCA module which compiles out of the box for linux / ARM, so I’m sure this will be helpful for anyone who want to build a module for the SSP. And that was the goal: to provide an SDK for anyone to create modules for the SSP (as announced originally in the kickstarter).
The Quad VCA VST plugin was provided along with the update and works out of the box. You can use it, we even provided an example preset for it.
@bert that’s all fine and good, and I certainly hope someone out there has such a vst ready to go. Can you do some searching online and provide some links for us? I did a search last night and found Linux vsts - they didn’t work. I am guessing because they need to be for ARM as well, which they were not.
So it’s Linux AND ARM required… Then it should plug and play? It would be incredibly useful if ANYONE @everyone had any links to such vsts?
This is really amazing potentially… but it sounds like it’s going to take work from the vst developers.
Absolutely, but please understand that this was always the case from the very beginning, and has been one of the driving reasons I’ve been so enthusiastic about this module.
The DSP portion of VST is good to go, BUT, the front ends need to be reworked. VSTs in general expose their details to a DAW, where as here the VST is able to do as it pleases, and has the control states of the SSP exposed to it.
In this way entire other firmwares could be made and run in the VST module. Of course the intention here is to quickly allow developers with existing VSTs a path to quickly recompile them and add them into the eurorack arena.
From the normal user, this is a super huge thing, and a positive, but it will require some more patience to truly bear some fruit.
I’m working on a plug-in now for example, and would like to help port a lot of the existing open source VSTs over, time permitting. This is what I’ve been waiting for.
VSTs that have been compiled for the ARM linux platform are great, but chances are theri controls and GUI have not been made for the SSP.
These things will need to be taken into account, before the firmware will be able to recognize them.
Just imagine an engine. A nice big beefy one. Well that engine could make any car go right? However you just can’t pick up the engine and plop it in another car. You need to hook it up to the transmition, attach it to engine mounts, etc. This is the porting process. The same engine will run on the SSP, but the interface has to be reworked.
@2disbetter yeah it’s awesome, there’ no doubt that it’s a long-run thing. I am hoping you, or some other people can start porting vsts over. Until then I’ll put this update out of my mind, because there’s nothing I can do about it.
I really like that the quadvca is the first vst!
I’m not complaining, btw… I’m trying to understand what’s going on. I totally misread the update thinking we could just throw linux vsts into the module and it would magically work… but that clearly is not how it works at all. it needs to be linux/arm, which really doesn’t exist so far as I can tell. So that is fine! It’s all good… it’s something people like yourself need to help us all benefit from
It works fine as is but the way we implemented the VST hosting is such that the developer of the VST can take full control of the entire screen and all the buttons and encoders (except the 4 menu buttons).
The way this works is by implementing the 22 parameters (nr 0-21) that represent the 4 encoder values, 4 encoder buttons, 8 softkeys, 4 cursor keys and 2 shift keys. This has to be done on the side of the VST plugin by the VST developer.
Normally with VST plugins in a DAW you’d get an additional GUI through which you control the VST’s parameters (apart from the VST GUI itself). For example in ableton live the parameters are exposed outside the VST plugin. However that is ableton live, and the SSP is not a DAW. We want the SSP to be as quick, smooth and easy to use, so that is why we decided to avoid putting in an extra layer of control/mapping, and let the VST developer control the entire experience once the VST plugin has been loaded.This means the VST developer can completely customize the UI (since it is fullscreen) but can also customize encoder step size and acceleration since he or she gets the raw data from our software.
Imagine we did put in that extra layer of control or mapping. You would then have to go into the VST module and manually configure what inputs go to which VST parameters for modulation, and the VST parameters would be spread across a lot of pages (some VST plugins have 100s of parameters). That would not be a great experience IMHO and it would require you to do one additional step of mapping nobody wants.
Of course the consequence of this is that off the shelf VST plugins might not work without some minor tweaking. But that is unavoidable.
Most VST plugins have fixed size user interfaces. For example they hardcoded the UI to be 640x480. Obviously we now have moved on, this is 2018 and not 1998, so user interfaces can now use vector graphics and be dynamically resizable. If everyone in VST land made their user interfaces scalable on the fly then all of this wouldn’t be an issue
so off the shelf plug and play won’t work
forget the paid for plugin developers, because they aren’t going to spend time doing anything for such a small audience (in my jaded opinion)
look to the free vst community to spend the time re-tooling their vsts to work with the ssp…
but in all likelyhood, it’s going to be bert and 2dis for a long time until @bert or @celine can convince a developer to join up
well, do you want an extra mapping layer inside the vst module to map inputs to vst parameters, or not? if yes, then you will have to map stuff and off the shelf linux / ARM vsts might work (pending the user interface resolution/size they use). If not, the VST developer has to do a small effort to connect the SSP’s encoders/buttons to his or her plugin parameters.