Linux Audio Editing Is Better With Ardour 3.0

[RealNC]

And that of course means it doesn't exist? Wow.

Why would that mean that it doesn't exist? I don't get what you're trying to say. My point was that it's not going to be used by most people, that's all.

There are open formats. Just like there is AATranslator for converting project data between DAWs.

It's extremely limited at what it can do. To me, it's totally useless, as everything I do is 90% MIDI. But I guess it's better than nothing.

I do like Ardour a lot. I didn't mean to criticize it as being a bad DAW. What I'm saying is that without thorough Windows VST support, it's not going to be used much.

[prokoudine]

Why would that mean that it doesn't exist? I don't get what you're trying to say.

Welcome to the brilliant world of English modal verbs, where "cannot" means "unable to". Here is what you stated, literally:

"I didn't know that it can't run Windows VSTs"

It can run those. You just choose not to use it. That's a whole different situation.

What I'm saying is that without thorough Windows VST support, it's not going to be used much.

That's not Ardour's problem. If you spend some time looking at bug reports in WINE's bug tracker, you'll see that there's a bunch of VST-related reports from the previous decade that haven't been even opened.

In my personal experience, Windows VSTs run well with some sorry exceptions. For instance, the only few plug-ins I couldn't run were the ones shipped with my Focusrite interface. At the same time, Roland's VSTi that was also part of the bundle Just Worked (tm). So really, it's matter of building a library of tools that have proved to work. Much like on Windows.

[RealNC]

That's not Ardour's problem.

I know. It's mine. And I'm saying that Ardour is not suitable for solving it.

If you spend some time looking at bug reports in WINE's bug tracker, you'll see that there's a bunch of VST-related reports from the previous decade that haven't been even opened.

At least one of them is mine. No one seems to be even remotely interested even in crasher bugs (the VST just crashes WINE on startup.) One would think that at least crashers would be given actual attention.

[ninez]

Which VST support? There's Linux VST support that was added by a developer from linuxDSP who is a good friend of Paul. It's very stable and reliable. And then there's Windows VST support via WINE that's never going to be stable and hence isn't available by default. Make your choice.

Not to mention that if you want Windows VST support in Ardour, the build must be 32-bit. Which kind of sucks when you are running a 64bit OS. i've only toyed around with ardour-VST, but i find it easier to just run Windows VSTs outside of / into Ardour-3.0. It's a little extra setup, but not much. (midi-out from ardour channel -> VSTi + VSTi audio into ardour channel). ~ this also gives the benefit where if a VST did crash, this has zero effect on Ardour. but generally, i won't use any buggy VSTs.

As far as stability of (windows) VSTs, as long as wine can run them - they generally tend to be pretty stable, with a couple of caveats; 1. not all VSTs are created equal, thus some are buggy 2. not all VSTs run well in wine 3. upstream wine isn't well-suited for proaudio for various reasons.... for the best stability / performance vanilla/upstream wine really isn't all that suitable, you need to be using various other patchsets with it and/or wine-l-pa. ~ generally, the VSTi's that i tend to use are as good (if not WAY better) than any 'native' VSTs available for linux. and by better, i mean in terms of stability, features, sound engine, flexibility, reliability.

I do like Ardour a lot. I didn't mean to criticize it as being a bad DAW. What I'm saying is that without thorough Windows VST support, it's not going to be used much.

You do realize that you can just run windows VSTs outside of Ardour-3.0, right? (but still use Ardour to control / process audio).

One of Jack's biggest features is interoperability between applications. I use N.I kontakt 5 for most of my drum sounds (loading my battery 3 kits, mostly) and map my (multi-)channels from kontakt into Ardour. it works great. Likewise, when i feel like recording some 'keys', i just load up XYZ VSTi, setup my channel in Ardour ~ and record...In my case, i am using FSThost to wrap .dll/vst into a standalone app. FSThost supports jack_session, so it's not like you can't save your sessions/routing/settings for recall (for a project) later. (likewise, i am sure Non-session-manager could work well for this too).

but i can also appreciate why people use Reaper - since it is an easier setup / just one app. I have Reaper to, but mostly just use it for testing purposes with wine-l-pa.

cheerz

[ninez]

At least one of them is mine. No one seems to be even remotely interested even in crasher bugs (the VST just crashes WINE on startup.) One would think that at least crashers would be given actual attention.

give examples? (specific VSTs).

The problem with _some_ vsts isthat they implement things which Wine does not, which tend to be the one's that don't work at all. imho, it is better to focus on the one's that 'almost work', maybe just have a few rough edges that can be fixed. So i am not surprised that one's that just crash wine badly don't get looked at... although, i must say ~ i have never found one that crashes wine ~ although i have obviously seen many that crash/don't run... although, these days more and more seem to run well.

sometimes, software in Wine will crash just because you haven't installed XYZ dll or have an 'override' that you shouldn't (or vice versa) too.

[RealNC]

give examples? (specific VSTs).

http://bugs.winehq.org/show_bug.cgi?id=29628

The problem with _some_ vsts isthat they implement things which Wine does not, which tend to be the one's that don't work at all. imho, it is better to focus on the one's that 'almost work', maybe just have a few rough edges that can be fixed. So i am not surprised that one's that just crash wine badly don't get looked at... although, i must say ~ i have never found one that crashes wine ~ although i have obviously seen many that crash/don't run... although, these days more and more seem to run well.

sometimes, software in Wine will crash just because you haven't installed XYZ dll or have an 'override' that you shouldn't (or vice versa) too.

Hopefully, one day, all major VSTs will provide Linux versions. Until then, running them in Linux is such a major PITA that most people just don't bother. It took me days to set up Reaper under Linux in a manner that works, JACK+Wineasio being incredibly complicated to get working (and Wineasio not working at all now since I was forced to upgrade glibc, so back to Windows 7 now), and Wine making your hair fall out with nothing running in it out-of-the-box. It would be quite a bit easier if Wine would provide ASIO support on its own though.

Windows and OS X will reign supreme for a while yet.

[ninez]

http://bugs.winehq.org/show_bug.cgi?id=29628

that app does not crash wine ~ but yeah, that is an example of a VST that does not work. (not with WineASIO/SAVIhost, not FSTHost).

Hopefully, one day, all major VSTs will provide Linux versions. Until then, running them in Linux is such a major PITA that most people just don't bother. It took me days to set up Reaper under Linux in a manner that works, JACK+Wineasio being incredibly complicated to get working (and Wineasio not working at all now since I was forced to upgrade glibc, so back to Windows 7 now), and Wine making your hair fall out with nothing running in it out-of-the-box. It would be quite a bit easier if Wine would provide ASIO support on its own though.

I think you are exaggerating on setting up reaper. It took me all of about 10-15 minutes to setup reaper, having never used it before. All that it required was using the wine-rt patch (well, variables provided by wine-rt on startup), plus a little tinkering in the settings dialog.

Regarding WineASIO / jack complexity (?). In my experience, wineASIO support is not hard to setup. the only annoyance is having to get asio.h, which is required to compile. After that, it is simply a matter of compiling wineASIO and registering the driver in wine. - applications that support ASIO (with a few exceptions) will work just fine, without any additional effort. If a glibc update broke wineASIO ~ then why didn't you just recompile it to fix the issue?

Also, don't expect official support for ASIO in Wine anytime soon, or ever ~ ASIO is not apart of windows and is proprietary, made by a 3rd party, wine-devs wouldn't add it to wine for that reason, alone.

As far as wine goes. You should have been using wine-l-pa over upstream wine ~ since it supports MANY more VSTs than upstream wine, has critical bug-fixes for native instruments plugins, patchwork that fixes a lot of the problems associated with the 'wineserver bottleneck' and other performance issues, plus other goodies.

now as far as OOTB support in Wine. If you are not relying on wineASIO (which i don't. i typically use FSTHost since wineASIO only gives you alsa-midi.). then really, you should just need to run winetricks and install; vbXrun (install all of them), vcrun2xxx (install all of them, or all that you can), mfcXX (both), richedXX and msxml3/4 ... Aside from that, it is always good to install 'all fonts' in wine.

FSThost: http://sourceforge.net/projects/fsthost/

the very latest git/svn supports wine-l-pa and has a slew of improvements not officially released yet. there is also a gtk_toolbar branch ~ which i have helped work on / i figured out the gtk.socket alignment issues, helped test the resize/WM code issues/fixes and worked on some of the icons + other bits with the developer. FSThost doesn't require the VST SDK headers or anything like that. It supports jack-midi, jack_session, has a a lot of other useful features, etc...

I agree that things won't be ideal until the bigger VST vendors support linux directly, but who knows when that'll happen. imho FSThost + wine-l-pa is probably your best bet for solid windows VST support / performance - but obviously, that is incompatible with using Reaper. ~ that being said; wine-l-pa does fix some performance issues with Reaper.

wine-l-pa: http://sourceforge.net/projects/l-proaudio/
wine-l-pa in AUR: https://aur.archlinux.org/packages/wine-l-pa/

(i only use Archlinux, so don't directly support any other distribution).

[RealNC]

You do realize that just using Windows is much easier that even reading that wall of technical text you wrote, right? wine-pa? Never heard of it. Arch Linux only? I don't use that. And I'm not gonna abandon my favorite Linux distro.

In fact, you just proved my point: it's insanely complicated to set up. I'll even have to boot a custom kernel? That's just like rebooting into Windows, if I'm gonna reboot anyway. I'm happy for you that you're able to do that in 15 minutes. For me, it takes much longer, and three weeks later something breaks. This cannot possibly be regarded as an alternative to just use it in Windows.

[ninez]

You do realize that just using Windows is much easier that even reading that wall of technical text you wrote, right? wine-pa? Never heard of it. Arch Linux only? I don't use that. And I'm not gonna abandon my favorite Linux distro.

I didn't say using windows wasn't easier, did i? Wine-l-pa is a fork (more like patchset for wine) that makes wine more usable for proaudio / linux-rt. Part of the patchset comes from Code Weavers / Muse Research (ie: the version of wine used in the Muse Receptor). As for it being Archlinux only - it's not... I just don't package it for XYZ distro because i don't use those distros ~ so i was not saying you should switch distros, I'm just pointing out that i (as the person who maintains wine-l-pa) do not package it for any other distro. ~ which considering that this is a project i work on in my spare time, probably shouldn't be an expectation, anyway

In fact, you just proved my point: it's insanely complicated to set up. I'll even have to boot a custom kernel? That's just like rebooting into Windows, if I'm gonna reboot anyway. I'm happy for you that you're able to do that in 15 minutes. For me, it takes much longer, and three weeks later something breaks. This cannot possibly be regarded as an alternative to just use it in Windows.

No, custom-kernel is optional - but has some benefits, such as fixing EXT4 latency issues, optional compiler optimizations, etc ... + for best performance @ lowest latency an RT-kernel is best anyway. As far as complexity, when packaged, installing wine-l-pa should be nothing more than installing any other app. same goes for FSThost. (in Archlinux' case 'yaourt -S wine-l-pa fsthost' + running winetricks once.... that's NOT complicated).

but obviously, if you can't adjust an apps settings to work properly in under three weeks (more like an hour tops!), then obviously, you should be using Windows ~ so i agree.

In my case, it's not an alternative to using windows ~ i use my VSTs in dedicated H/W + am not a windows user at all. but i totally understand where you are coming from.

[porkbutt]

It has been over a year since development work for 3.0 version started.

No, it was originally expected to be released around 2009 after already being years into development. Ardour 3 was the Duke Nukem Forever of audio software.

btw if this release opens the way to a native reaper release for linux then ardour will fulfill its duty.

No, Reaper on Linux will be a fail. They've realized that WINE sucks, so they're hoping some generous developer will come fix their "native" Linux port, which in fact just wraps Windows system calls as Linux system calls. They don't even care enough to do the works themselves, I guarantee you that it will never amount to anything.

who cares about paul's monthly income from ardour being hardly enough to keep him developing and mindless zealots that follow him (while the development is soo slow?) development of ardour is slow because paul davis has set up a system that every donation or subscription is paid directly to him and not distributed among developers fairly. as a result no clever developer helps him finish the job only mindless zealots do

x1000. What other project brings in so much money in donations, while the lead developer publicly cries about how it's not enough and how development may not be able to continue. Did he ever stop to think that Ardour isn't worth paying for? Harrison Consoles "borrows" Ardour's source code and adds their DSP to make Harrison Mixbus for Window,s Linux and Mac, and they only sell it for $45 because if they priced it any higher, nobody would buy it. I think Harrison's DSP accounts for about $44 of the total value there, take that out and you're left with a basic recording software that fails badly once you start to do more than recording.

It will never be suitable for more than recording, the front page or Ardour.org says it all:

Being the best tool to record talented performers on actual instruments has always been a top priority for Ardour. Rather than being focused on electronic and pop music idioms, Ardour steps out of the way to encourage the creative process to remain where it always has been: a musician playing a carefully designed and well built instrument.

So there you have it, only Led Zeppelin tribute bands and snooty Beethoven wannabes and other outdated traditional genres are real musicians according to Ardour.