LMMS has been loading windows VSTs for a long time. couldn’t it be possible to borrow some of their code and do this in ardour? it effectively makes the list of plugins you can use shoot way, way up.
I remember using VESTIGE as far back as 2008, with really awesome results.
rusk: that doesn’t scale sensibly. Browser plugins are not executed thousands of times per second in a realtime context, and you don’t have a situation where there might be N different plugins on every track.
And let me clarify the history here. Kjetil Mattheusen was the first person to get Windows VST’s running on Linux. He did so using a server-based approach, where a single server loaded all the plugins and the real “host” called the server to get stuff done. This didn’t scale (for the reasons I’ve outlined above) in cases like Ardour, so I and Torben Hohn reimplemented Kjetil’s idea so that the plugins could run inside the DAW. This approach scales, but turned out to be very very dependent on the precise version of Wine. I subsequently decided that although the code for this within Ardour would be loosely maintained, I would NOT support it.
After we did that, some other people took various approaches that used varying amounts of Kjetil’s approach and ours. This includes what LMMS does and also what dssi-vsthost does.
If you want to load Windows VST plugins into Ardour on Linux, you use a specially built version (which is actually a windows program executed with Wine). We will NOT ever make Ardour use technology that runs Windows VST plugins in another process.
Yes, I know I can do it manually with fst but it’s not useful even using gui like festige. Loading vst plugins in the same manner as lv2 is importaint thing imho.
Why not implement loading vst-s from within DAW in some external process like modern browsers do with flash plugin container? This way plugin crash will not cause DAW crash and ardour itself will not dependent of wine headers.
seems I can’t edit my post.
I mean would it be possible to have this in by default, and on non linux builds as well.
@d3drocks: As a commercial developer of linux plugins, whenever I mention my genuine personal opinion on this, I get accused of everything from having a commercial interest in spreading FUD about using Windows plugins on linux, to just hating WINE for some irrational reason, however, my genuine (irrespective of commercial interests) opinion is this:
(and I’ll repeat it again because its based on personal experience)
it effectively makes the list of plugins you can use shoot way, way up.
It makes the list of plugins you can use dependent on WINE shoot way up - and while I think WINE is an incredible achievement, its still a compatibility layer, which has had to be (reverse) engineered from a closed OS, which means that there are always going to be compatibility issues as the developers cannot know all the (undocumented) issues inherent in the OS (and the plugins), and compatibility issues between them.
What this means at a user level is that you can’t be at all sure that what works today might not fail inexplicably the following day (or after a WINE upgrade) - or due to the phase of the moon, or the prevailing wind direction. And when it does fail, neither you nor the developers (and you can be sure the plugin developers won’t care) will be able to do anything about it.
So, its fine if you want to experiment with windows plugins on linux (but seriously, if you’re going to run windows software, its far better to do that on windows)
However, if you depend upon a project working reliably, and repeatably its probably not so good to use plugins designed for a completely different OS.
As for including it by default there is empirical evidence that the Windows VST compatible builds of ardour (on linux) are (or certainly were) less reliable generally, so I would caution against including something by default which compromises the stability of the application (obviously I’m willing to be corrected if this is not the case, and its something the ardour devs are better able to comment on).
I realize what you are saying here, but i seriously think its an important thing to add. so many people are locked down to windows (I used to make VST plugins for windows with synthmaker) things that having something like this would be really useful. to address your stabability issues, you could always mix down what comes out of the plugins to audio, but I’ve never had serious problems with it in the past.
I would reccomend you give LMMS a try and see how they handle it. I’ve found that broken windows plugins won’t crash projects. it can be done.
people make these arguments against wine all the time, and repeatedly I’ve found them to be not valid. everyone complains about compatibility issues. there are some, yes, but I’ve got major things running in it at the moment, and since the help from codeweavers appeared, things have become pretty good.
I would reccomend you give LMMS a try and see how they handle it.
What I don’t often mention is that for probably about a year before any of my linux plugins were released I devoted a considerable amount of time to understanding most of the issues which at the time were causing problems with Windows VSTs under WINE on linux - with a view to a pro-audio manufacturer using the technology as an option on one of their linux based products. Most of the serious issues were resolvable, and a great deal of progress was made - it was far more reliable than e.g. FST was at the time, but the decision was made in the end not to pursue the project further as the stability could not be guaranteed to an acceptable (albeit very high) level of reliability.
The major issue being that as much as you can fix a lot of the issues around individual plugins as they arise, when a plugin doesn’t work, you may find that the WINE devs can’t resolve it because of the closed nature of the plugin, and the plugin developer will not be prepared to support or investigate the issue because it could just be a problem with WINE. That was the main reason why it wasn’t deemed commercially viable in that instance and I think that illustrates why a note of caution should be added. How much this matters is purely down to your own personal acceptance of the risks.
(obviously there are other products available which do similar things, but there is usually some kind of caveat about compatibility or ‘supported’ plugins)
Another reason, was that for many of the commercial Windows VSTs which most pro users wanted to use, some kind of hardware dongle was required and my understanding is that there was / is virtually zero chance of those copy protection systems ever working under WINE for obvious reasons.
Again, how much that matters depends on what plugins you use.
My view is that all the wine stuff should be kept outside of Ardour. Falktx from KXstudio is writing a wrapper called Carla to handle most of the format plugins, including wine vsts. It’s not ready yet but works pretty cool with a lot of vsts. You have some more work because you need to wire ardour tracks and plugins through jack, but it’s more reliable.
There are enough problems with some LV2 and DSSI crashing Ardour… from my experience, Ardour doesn’t crash if you load only quality plugin, including linuxdsp ones of course.
For some time, Ardour can be built with Windows VST support, but you’ll have to compile it yourself, or use, for example, AVLinux, which provides a pre-compiled version of Ardor with windows VST support enabled. There is always the caveat that Windows VSTs run using wine and therefore may have problems, break with new versions, etc.
Clear. That was just an idea. Not feature request. I’m not familiar with system programming.
Other idea, not feature request, but asking your opinion. Are some sort of supported plugin formats able to run external commands? Let’s imagine a festige like plugin that will be able to run fst externally, automatic connect jack routes and save it’s state within ardour session file like plugin settings. Is that possible?
sure, it could do that.
Bingo! Such plugin is allready under development in kxstudio!