Any recent DAW comparisons?

[Jack Winter]

I know the makefiles are obvious for what they do...
question is, which one should we use? which one is better, more stable, what are the trade-offs...?

I actually just went through the readme quickly, and got even more confused...
I don't understand all that WINEPREFIX stuff..
In Carla I made it so it automatically detects the prefix the plugin is located and sets up the variables for the new process so the plugins always work correctly. In case of not being able to find a valid prefix (ie, plugin is on a random non-wine folder) it falls back to a user defined value.

LinVst also detects what prefix it's installed in.

I do the following.

I have 2 dirs: ~/.wvst-prefix and ~/.wvst. In .wvst-prefix I have a general wineprefix called default for plugins that don't need anything special at all. So I might run WINEPREFIX=~/.wvst-prefix/default wine installer.exe and inside of the prefix I install the plugin into lets say c_drive/VSTPlugins. Then in ~.wvst I create a symlink to ~/.wvst-prefix/default/c_drive/VSTPlugins called default. I have more of the same like fabfilter, ikmultimedia, komplete, etc.

I've never tried the included utilities for copying linvst.so since i wrote a script a long time ago for doing this.
It just changes pwd to ~/.wvst/default and copies linvst for each .dll that it finds there, and walks through all of the prefixes doing the same.

I decided to do that to separate plugin bundles from each other, and also to be able to handle any eventual dll overrides needed. Makes for peace of mind, and if I break a prefix I don't mess all of them up.

A few more tips. Everytime you update wine it will scan and update the registry of the prefix which takes a long time and often means that the loading of plugins time out and fail to load, so after I've updated wine I run a script that does wineboot -u on each prefix. Like that they have already been updated when I start my DAW.

The next tip is to run wineserver -p on each prefix to preload the server before starting the DAW and wineserver -k after exiting. Which speeds up loading quite a lot. So something like:

Code: Select all

#/bin/bash
export WINEDEBUG=-all

WINEPREFIX=~/.vstprefixes/fabfilter wineserver -p
WINEPREFIX=~/.vstprefixes/ik-multimedia wineserver -p
.
.
/home/jack/reaper-linux/reaper5
WINEPREFIX=~/.vstprefixes/fabfilter wineserver -k
WINEPREFIX=~/.vstprefixes/ik-multimedia wineserver -k
.
.

And personally I use Makefile-embed as I like my windows embedded, your milage might vary.

Also I noticed that the git repo now looks a lot better with commits with just a few changes and not like it was before. Very nice, maybe I'll look at the code again when I get the chance, as I still have a few ideas for improvements.

[Jack Winter]

That's very nice, thanks for the tips.

The issue is though, regular users will not do this.
It's great that you know the way around the system to do this, yes, but this is precisely the thing we were discussing before.
Users want a simpler solution that does not involve copying and manually managing files. (not to mention building from source)

I have some good plans for carla regarding this, but it will take some time until it's done.

Well building a distro package some packager has to do, no? Like with all software you have to make decisions how to configure (or waf, etc). In this case as it's small there is no autohell, just a couple of different make files. You could also just use one, and pass some defines to it...

Looks like Archlinux has a buildscript on the aur (https://aur.archlinux.org/cgit/aur.git/ ... D?h=linvst) getting an archive from github, so the author even builds a binary..

Regarding how to use it, with flexibility comes complexity, but have you had a look at the source? The README says the following: "linvstconvert (GUI or CLI) and linvstconverttree can automatically batch name convert linvst.so to mutiple windows vst dll names that are located in a folder/directory (the linvstconvert CLI version needs to be run from within the dll's folder/directory). linvstconverttree can automatically name convert folders and sub folders (directories and sub directories) of vst dll plugins." I've never personally tried them as I already had a solution in place.

And regarding how to use it, no need to make it as flexible as I did I suppose the easiest is probably for a user to use the default ~/.wine wineprefix. Install wine, run "wine Setup-plugin.exe", and then create a symlink somewhere, maybe "ln -s ~/.wine/drive_c/Program\ Files/Steinberg/VSTPlugins ~/.vst/wine", and then go to town.

Possibly it needs a better documentation, but you know how that is.. I'm sure if you tried it, you'd figure it out in no time!

Edit: But yes, it would be nice if you didn't have to make build choices, and could control whether it embeds the plugin in the hosts window or not, etc, at runtime through an environment variable. Still I guess you'd still have to consider 32 vs 64 bit host and plugin. It can't all be decided at runtime...

[milkii]

thanks greatly to all for the contributions and comments to/on the comparison matrix.

@falkTX; good point. i'm gonna keep the Windows VST row for now though and update it to reflect the method of bridging, just in case the comparison ends up helping, though i was thinking i'd get to a point where i'd be removing such software because of the lack of expression.

which leads to software inclusion parameters - what is a DAW? a DAW traditionally has sequencing, but indeed, Carla has basic MIDI sequencing plugins included, and the map is not the territory etc.

i'll add Giada to the list as it does audio and MIDI, though it's MIDI mapping style is very limited if you want to do a lot.

also, FLOSS? i was fudging it by including T6, and someone added Reason, so I'll go with adding commercial software, with an empty column spacer, for a fuller comparison.

[ubuntuuser]

I release binaries and they are for 64bit/32bit vsts.

The binaries contain 3 versions, an embedded window version and 2 different standalone window versions.

The standalone window version has an always on top window (which someone requested) but maybe some don't like a window like that and so there is another option where the window behaves as usual.

I'm thinking about dropping the normal window standalone version, so that would make just an embedded and standalone version.

The 64/32 makefiles need multilib so that 32 bit vst's work but not everyone wants that so I keep the 64 bit makefiles hanging around as an option (I suppose I could put 64 on the end of their names to be more obvious).

That's about it and I'm using the

Makefile-embed6432-drag

Makefile-noembed-6432-ontop

Makefile-noembed-6432

makefiles

noembed means no embedding window and therfore it's a standalone window (I could rename the noembed part of the name to standalone but I thought it as pretty obvious that noembed means no embedding).

The reason for Makefile-embed6432-drag and Makefile-embed6432 is because the drag and drop embedded feature was a bit experimental so I kept the embedded no drag and drop makefiles hanging around as an option but I'll probably make embedded drag and drop the default and so those 2 makefiles can be replaced by just one (Makefile-embed6432-drag).

Also in the binary are linvstconvert and linvstconvertree which are like batch files or scripts for the linvst renaming (folders of windows vst's can be automatically name converted to .so files very quickly without manually renaming linvst.so).
linvstconverttree does sub folders as well (which someone requested).

A Distro package would probably follow my binary release.

[Jack Winter]

I do realize that this is a work in progress, so maybe this is a stupid idea and the target is a single binary, but any chance the various embed/standalone/dnd options could be built into the same binary and selected by an environment variable?

[sysrqer]

also, FLOSS? i was fudging it by including T6, and someone added Reason, so I'll go with adding commercial software, with an empty column spacer, for a fuller comparison.

Renoise, not reason. You should definitely include non free software, not everyone cares and some are very much against it.

[nils]

That comparison matrix is great.
I only wish it wasn't on some google spreadsheet, destined to be lost in time or on the whim of google.

Is it possible to make that on the linux audio wiki? Is the loss in convenience too heavy?

[ubuntuuser]

I do realize that this is a work in progress, so maybe this is a stupid idea and the target is a single binary, but any chance the various embed/standalone/dnd options could be built into the same binary and selected by an environment variable?

Maybe.

For all of LinVst's existence, the standalone window has been ahead of the embedded version in terms of what it could do and it's just been a case of getting the embedded version to do what the standalone version could do and there were things complicating that like Wines XEMBED which really needs some sort of makeover.

If everything was compatible then just an embedded version would be it, but some hosts seem to do odd things and XEMBED is not working, so I'm keeping the standalone window as an option for now.

I don't know all of the details but XEMBED appears to be sitting between the hosts embedded window and wine and it can then communicate directly with wine's internal functions which is what is needed.

Without XEMBED the hosts embedded window is sitting outside of wines's internal functions and the wine window appears as just a basic window that exists at 0,0 coordinates and so it's hard to get the low level control happening without a lot of workarounds.

So, XEMBED is what's needed but the only problem is that it doesn't work properly and corrupted displays and instability can happen.

Now I've got the embedded version to do what the standalone version can do by using some tricks of the trade and not using XEMBED but I still want the standalone version as an option.

I havn't really got the time to rewrite XEMBED as one wine-dev (very kindly) said I should do.

[Linuxmusician01]

thanks greatly to all for the contributions and comments to/on the comparison matrix.

@falkTX; good point. i'm gonna keep the Windows VST row for now though and update it to reflect the method of bridging, just in case the comparison ends up helping, though i was thinking i'd get to a point where i'd be removing such software because of the lack of expression.

You might also want to make clear if it's 32 bit or 64 bit windows vst's that are supported.

I'm still confused: Windows itself doesn't support the 32 bit ones anymore if I'm not mistaken (it is supported via some trick ore something). Dunno 'bout LMMS and Qtractor: I think it's only 32 bit out of the box and 64/32 bit if one uses Carla. Can LMMS be used w/ Carla? This mess it not the fault of anybody (not even Windows/Microsoft or Steinberg) but it is one of my greatest personal frustrations. Like I said: I've a bunch of beloved VST''s. Most of the time I noodle w/ hardware synths. Don't even use a PC anymore to record it (I use a hardware audio recorder). But sometimes I need a DAW. To use a synth of which I do not have the hardware version. Lets be honest: there are no Moog, Korg or Roland Linux VST or LV2 plugins and there never will be. And every time I've forgotten how it works w/ 32 bit, DSSI, DSSI-VST plugin, 64 bit, how to use Carla w/ my DAW, etc., etc. Don't get me wrong: I know you developers are working very, very hard to make all this possible for me. I appreciate that A LOT! You are saints in my opinion to do this for free for me. I don't deserve that, ha ha.

I just wish it could all be more clear.

[chaocrator]

I'm still confused: Windows itself doesn't support the 32 bit ones anymore

32-bit VSTs are handled (or not) by a DAW, not OS.
for example, Cubase completely dropped 32-bit VSTs support since version 9.

[tavasti]

Looks like my search for DAW is reaching to stage I have found tools which are ok enough for me. This far I haven't found single software for all needs, but softwares which together work enough ok for me.

- Electronic productions are done with LMMS in desktop / laptop, or with Caustic on phone (finalized on linux desktop). Same applys for backgrounds for guitar music. Both can export all tracks independently, so I can finalize mix outside of them.
- All real instruments are recorded with Mixbus. On some occasions I may do some simple midi-stuff there also. And if midi is recorded from keyboard or guitar synth, then it is handled in Mixbus
- All stuff is mixed together in Mixbus. I really love that mixer layout.

So my research is at least suspended for now, and focusing more getting music released. http://cargocollective.com/tavasti/Selecting-Linux-DAW