Yeah, on Github there was an update in 2016, so that's more recent.
But I can't even get it complied, since it's using some libs that Manjaro doesn't feature (anymore?). That's so sad, this project really looked promissing.

It looks like this guy did some really great work. Would be a shame to see it just die. Right now, it's not possible to load my windows template in Linux without shared memory in WINE. Every instance of a Kontakt plugin takes 200mb of memory in WINE. If you have 1000 tracks of Kontakt, that's 200GB of memory without ANY samples being loaded. And any duplicate samples are loaded into RAM separately as well.

The thing is, these improvements in Wine can be done. Just like the muse research guys got iLok working as well as several other tweaks. But it seems like there is just not enough people interested to make the WINE developers pay attention (apparently Muse Research offered their tweaks for inclusion in WINE but nothing happened).

It's a bit of a catch-22. Because having these improvements in WINE would bring over more windows users to Linux, which would in turn help spur development. In a perfect world, if Justin had the time to look at this and an integrated Windows VST bridge, I think a lot more users would jump ship. Unfortunately things like Kontakt are irreplaceable because the sample libraries can't run in anything else, especially the large orchestral ones.

In a perfect world the developers of Kontakt etc. would make Linux VST plugins so that Linux users wouldn't have to rely on bridging.

In this "Native Instruments (etc.) will never give a shit about Linux" world, I guess if Cockos wanted to make Reaper for Linux capable of working with all Windows VST plugins that would be nice. I really wouldn't hold your breath though. That's a rather large ask.

In a perfect world the developers of Kontakt etc. would make Linux VST plugins so that Linux users wouldn't have to rely on bridging.

In this "Native Instruments (etc.) will never give a shit about Linux" world, I guess if Cockos wanted to make Reaper for Linux capable of working with all Windows VST plugins that would be nice. I really wouldn't hold your breath though. That's a rather large ask.

In my case, all the Native Instruments plugins I've paid for are working fine in WINE, but I won't purchase anything more from them unless it is native Linux based.

For me WINE is just a stepping stone like 32 bit bridging in Windows was when I moved to 64 bit Windows. I never bought any non 64 bit plugins after that, and I won't buy any non native Linux plugins now.

In a perfect world the developers of Kontakt etc. would make Linux VST plugins so that Linux users wouldn't have to rely on bridging.

In this "Native Instruments (etc.) will never give a shit about Linux" world, I guess if Cockos wanted to make Reaper for Linux capable of working with all Windows VST plugins that would be nice. I really wouldn't hold your breath though. That's a rather large ask.

Man, I‘m so with you on that. I recently did a comparison between Diva Linux/Windows.
The project running the Linux version had 10-15% less CPU.
So, a native Kontakt version would be really awesome. But unfortunately, NI is not interested in Linux.

The problem is really the large amount of Kontakt instances we run. On the long run, this kills Reaper with an non-optimized Wine.

On a different note... I tried to build the arch package from github, but there are a lot libs that aren’t available (anymore?) in Manjaro. Any idea how to get that package complied?

I don't use Arch, sorry. I've used MX Linux (Debian-based), Mint XFCE (Ubuntu-based) and am switching to Xubuntu once I get my new Ryzen 3700X system put together soon. I want to stick to really common, up-to-date distros which require less use of command-line stuff to configure.

I also don't use WINE or any bridging. Native Linux only for me.

Yeah when I switched to Linux I'd done some apples-to-apples comparisons using only Reaper plugins and I got about another 30% CPU in Linux while also having it be more stable at high CPU use (and lower latency than possible in Windows). I didn't realize that would be the case but I was happy.

That site seems to be just wine-rt with a few hacks and it's totally out of date, at least they tried to do something at that time.

A lot of modern Windows plugins need d2d1 which is only implemented in a basic way in current Wine.

d2d1 implementation would be the main thing, and to dothatt requires a programming knowledge of Microsoft's Direct3d etc API's and then translating them into Wine/OpenGL.

Wine is never going to be 100% Windows, so just roll with it and don't expect too much from it, if someone thinks Wine shouldn't exist on a Linux system then don't install it.

The Muse comparison is out of date because Muse didn't do anything with d2d1 based plugins that I know of and didn't contribute d2d1 code as far as I know, Muse was ok in it's day for a Wine based product.

The main Wine development that is going on that can benefit Windows vst's is coming from the gaming community and there is Wine Staging esync and a planned Wine fsync from Steam and things like 3d etc development.

There are a lot of experienced devs working on speeding up Wine and adding things, things like the wineserver response etc.

The Kontakt memory problem seems weird to me.

Kernel 5.2 and rt/zen patches seem to be pretty good with Wine as far as I can tell.

Stock/rt kernels don't really exist with MacOS and Windows as they have low latency built in as standard, and when the Linux kernel gets rt as standard then it will presumably be in the MacOS and Windows latency ballpark, the stock kernel is ok but it can be improved on hence the rt/zen patches that are around and they aren't around for no reason.

Linux native plugins are around and can be very good, but most of the Windows vst devs are not going to be flocking to Linux anytime soon.

The latest version of Seaweed Audio's Fathom synthesizer
was a major update, but it continues to work well when
wrapped by LinVst. It's an example of a developer focussing
on solid code and improvements, rather than arcane
registration schemes, pointless download managers,
and intrusive data mining.

Seaweed is currently a one-man-shop, so producing a linux version
would slow developement of crucial planned capabilities,
like AVX integration, implementing gpu processing power,
and adding a robust sampling solution. Without much hope
of dramatically increased profits directly from linux version
sales.

If we as a group of musicians, fail to buy excellent usable
software tools, simply because wine and linvst are needed,
who loses? I say everybody loses.

Excluding new and excellent software from our toolset
secretly dampens creative potential, lowers the profitability
of brilliant career coders, and could stigmatize linux musicians
as isolationist technophobes, with a misplaced
superiority complex, rather than 'us' being
seen as a group of forward thinking creatives.

Have a great weekend, and consider to demo,
or test a free version of, something new and exciting.
Cheers

If we as a group of musicians, fail to buy excellent usable
software tools, simply because wine and linvst are needed,
who loses? I say everybody loses.

I don't plan to buy any more Windows VST/VSTi plugins, but my reasons are more about efficiency, which was why I sought out and bought a couple hundred bucks worth of new plugins that are native Linux. These were all audio plugins, which can be found.

As for instrument plugins, I still rely on Kontakt and a handful of other Windows VSTi plugins I already have, but whether I run Windows or Linux I have no plans to expand my virtual instruments.

That said, some developer could sure get some money out of me if they came up with a native Linux replacement for Kontakt with a similar stock library of high quality playable sounds.

I don't plan to buy any more Windows VST/VSTi plugins, but my reasons are more about efficiency, which was why I sought out and bought a couple hundred bucks worth of new plugins that are native Linux. These were all audio plugins, which can be found.

As for instrument plugins, I still rely on Kontakt and a handful of other Windows VSTi plugins I already have, but whether I run Windows or Linux I have no plans to expand my virtual instruments.

That said, some developer could sure get some money out of me if they came up with a native Linux replacement for Kontakt with a similar stock library of high quality playable sounds.

Unless a product is fully cross-platform, there is no way
to compare efficiency. At best, with a U-he product, you could compare

But even then the reaper daws are unequal, and no accurate
frame of reference exists among linux systems
with myriad DE's, config genious, config blunders,
kernels of every size shape and color running
who-knows-what from start-up...sometimes have to decide
things on more than efficiency alone.

----------------------------------------------

I didn't plan on getting married, until a friend
introduced me to 'the one'...

I didn't plan on buying Hive until I heard it...

----------------------------------------------

Might be easier to code a Kontakt competitor, than to match
or beat it's library and 3rd-party products,
it seems the three together
will be kings of the hill for quite awhile.
Cheers

Especially with projects where I have near 100 FX patched and every one of them was using LinVST and WINE. Now only a handful of the plugins I use are bridged and I'm seeing the kind of performance now in REAPER for Linux that I was used to seeing in REAPER for Windows. This is on a dual boot machine, so it's the exact same hardware with Windows as it is in Linux.

Very cool results, and under challenging conditions!
The waters get deeper exponentially, once adding the fifth track...

I just did a quick unscientific ballpark comparison
of linux U-he instruments vs the windows versions in
wine-staging 4.14, Mint 18, low latency kernel 4.14,
and using the latest reapers,
using only qjackctl cpu readout, while playing
about with single notes of each instruments default patch,
and attempting 'ballpark accuracy',
as the cpu reading beebops a good deal. Linux % on left
wine/win % on the right:

Hive2 was the only one showing higher cpu use in linux,
and likely as it's a recent and huge update release,
Abique may not have had much time to tweak it's performance.
All in all, the linux ports are unscientifically
doing very well!
Cheers

I recently did a comparison between Diva Linux/Windows.
The project running the Linux version had 10-15% less CPU.

Hi, could you share your test procedure? I'd like to
try something better than what did which I posted above,
to keep more accurately informed. And of course,
gleaning any production tips as they appear!
Cheers

If Reaper/linux would feature an automatic Wine/LinVST bridge for windows plugins, this should be crafted in a way that a sequence of Windows plugins is handled in a single instance of bridge.
-Michael

Maybe this depends on the definition of "better".
Enabling Realtime performance in the Kernel needs to add some CPU demand to have it handle the more complex scheduling.-> worse CPU usage numbers. But when the correct threads are defined to be realtime, the required latency to make them work glitch-free might be a lot better.

The "realtime" thingy is not about reducing CPU usage, but about dedicating CPU resources where you decide you want them.

If Reaper/linux would feature an automatic Wine/LinVST bridge for windows plugins, this should be crafted in a way that a sequence of Windows plugins is handled in a single instance of bridge.
-Michael

There is still Linux to Wine process switching.

I've tried to work out possible bottlenecks including timing process switching with and without wine and testing the wineserver response and testing shared memory and I can't pinpoint large bottlenecks with any of these and it seems to me that some kernels just tend to deal with Wine better than others, hence the 5.2 liquorix kernel comment I made where the performance improvement is very noticeable.

It wasn't that noticeable with the liquorix 4.x kernels but with the 5.2 liquorix kernel it is.

In kernel 5.2 there have been internal changes and maybe some of them help when combined with kernel optimization patches, I'm not sure.

If Reaper/linux would feature an automatic Wine/LinVST bridge for windows plugins, this should be crafted in a way that a sequence of Windows plugins is handled in a single instance of bridge.
-Michael

When I first got all my Windows plugins working in Linux I had just completed a project in Windows with close to 100 plugins. Playing that project in Linux exposed for me the performance hit of bridging that many Windows plugins, which was the exact same experience I had when moving to 64 bit Windows and all my 32 bit plugins were being bridged.

Since replacing all my 3rd party Windows audio plugins with 3rd party native Linux audio plugins, the performance hit I see when using things like Kontakt, Superior Drummer, and other bridged Windows instrument plugins is negligible, because now there are so few instances of LinVST and WINE being used.

Since replacing all my 3rd party Windows audio plugins with 3rd party native Linux audio plugins, the performance hit I see when using things like Kontakt, Superior Drummer, and other bridged Windows instrument plugins is negligible, because now there are so few instances of LinVST and WINE being used.

The problem is there isn't any kind of replacement for Kontakt. Libraries like Spitfire, Cinesamples, OrchestralTools, etc., etc. simply won't run in anything else and there is no way you could convert them to another format. Not with all the custom scripting, GUIs, legato switching etc. It would literally be impossible and I don't use that word lightly.

So, while you are absolutely right in terms of the performance hit, optimizing Windows Vsts/Wine as much as possible and allowing separate Kontakt/Vst instances to share memory is really critical. Just in terms of memory usage, I would need around 300GB to load my Windows template in Linux, vs 100GB in Windows.

The problem is there isn't any kind of replacement for Kontakt. Libraries like Spitfire, Cinesamples, OrchestralTools, etc., etc. simply won't run in anything else and there is no way you could convert them to another format. Not with all the custom scripting, GUIs, legato switching etc. It would literally be impossible and I don't use that word lightly.

So, while you are absolutely right in terms of the performance hit, optimizing Windows Vsts/Wine as much as possible and allowing separate Kontakt/Vst instances to share memory is really critical. Just in terms of memory usage, I would need around 300GB to load my Windows template in Linux, vs 100GB in Windows.

Virtual instruments are the one thing I do still bridge in Linux, and don't expect any kind of native solution for any time soon.

For my own productions I only use Kontakt and other Windows based VSTi's as support behind real instruments, so I don't have the memory requirements or CPU performance needs like someone who is doing complex orchestration.

I've not hit the wall yet and have been able to use all my Windows VSTi's exactly the same way I used them in Windows. That said, I would love to see Windows VST/VSTi support improved in REAPER for Linux, either through direct support within REAPER, or through external support with things like a tweaked for VSTs WINE.

Curious, for the VST software devs that has no plans for Linux, is there such a thing as a second best thing.. can they code their stuff in the future at least in a way to make it easier for WINE and what have we to actually work even better?

The problem is there isn't any kind of replacement for Kontakt. Libraries like Spitfire, Cinesamples, OrchestralTools, etc., etc. simply won't run in anything else and there is no way you could convert them to another format. Not with all the custom scripting, GUIs, legato switching etc. It would literally be impossible and I don't use that word lightly.

So, while you are absolutely right in terms of the performance hit, optimizing Windows Vsts/Wine as much as possible and allowing separate Kontakt/Vst instances to share memory is really critical. Just in terms of memory usage, I would need around 300GB to load my Windows template in Linux, vs 100GB in Windows.

From the Wine docs

All wine processes using the same wineserver (i.e.: same user) share certain things like registry, shared memory and kernel objects.

Also, any instance of a vst needs it's own block of shared memory to copy (that vst instance's) audio etc from a Linux process to a Wine process and the shared memory needs to be large enough to cover the amount (of that vst instance's) audio tracks.

I think I've got the vst instance shared memory at around 5MB or so, and it could go down a bit more.

Ryzen/i9 systems memory throughput would be optimal.

There is overhead in just the Wine video/gui translation and I've seen slower video cards interfere with the latency response, the Wine gamers have Proton or whatever because of the same sort of reasons.

The more modern the hardware is, the more the performance including the video hardware and drivers.

Older dual cores or even quads (10 or more years old etc) are probably ok for very light things but not for more than that and ddr2 systems and older video hardware can be bottlenecks (I have a motherboard that can take ddr2 or ddr3 to compare).

Memory spread out across 2 banks can halve the cpu load more or less (Reapers cpu load) as compared to having all the memory in a single bank, because of the shared memory and how memory banks tend to work.

I don't know if I could get a 1000 Kontakt instances running ok on my Windows 10 systems, I've never tried 1000 instances of anything.

Curious, for the VST software devs that has no plans for Linux, is there such a thing as a second best thing.. can they code their stuff in the future at least in a way to make it easier for WINE and what have we to actually work even better?

From a stricktly users experience, the less a plugin/app relies
on windows code, filesytem, and paths, the better.
Fathom Synth contains everything under one main folder,
except for an .xml config file.
U-he products are also highly consolidated.

Then there exists Native Instruments parade of zombie-coders,
who limply toss bits and bobs of code everywhere. Massive X,
their new 'flagship' synth, ships presets in an iso file, and the main installer doesn't even prompt for it.
Wavetables are in some 'Common Files' path, presets are in
Users/Public/Documents, various program code in Program Files/Native Instruments, some cache is in Users/you/appdata/low, and likely a few more locations are filled in for luck.

And what a vipers pit the whole visual c++ freak-show is...
and then they want tracking data sent, and a stupid auto-updating
install-droid/account manager, to ice the cake. It's so cool
when it all works, but holding your breath when walking on eggs,
doesn't exactly enhance your slowdance with the muse.

I've gone throug a dozen or so Fathom updates, some quite radical,
but solid coding has prevailed, U-he windows versions
likewise always work in wine/reaper, just good old-fashioned genious,
keeping things simple.
Cheers

Another thing is that some Windows vst's have bugs that are ok on real Windows but Wine can't handle them.

The programmer(s) tests the vst on Windows and if it works then it works even if some bugs are present that they have overlooked.

Bring that vst to Wine, where Wine doesn't expect the bug, and the bug(s) can cause problems.

Waves and Melda plugins have painting bugs for instance.

Try running a Melda plugin with the Windows version of Reaper under Wine and it will throw a X11 bad window error when the Melda gui is closed, because of Wine not being able to handle Melda's painting bug.

Waves can hire experienced programmers but the bug is still there in v9 and v10.

Vst's from smaller developers that are sometimes not that experienced in programming (it's pretty easy to leave a bug around even for experienced programmers) might have bugs that Wine can't handle.

Hi, could you share your test procedure? I'd like to
try something better than what did which I posted above,
to keep more accurately informed. And of course,
gleaning any production tips as they appear!
Cheers

I created a project with 3 tracks and recorded some MIDI. Then I put the project in loop while playing back
and wrote down the highest values for RT and total CPU in the performance meter in Reaper.

A general word about wine-lpa:

it could be that it is pretty outdated with all the tweaks, that in the meanwhile might already be part of wine staging. But one of the important things nine7nine was working on, was support for iLok and eLicenser. This is something that the wine developers don’t care for.

My guess would be that since Windows hardware drivers are not supported in Wine (because of many technical reasons) that Muse Research might have got (licensed) programming specs from ILok and then wrote a Linux driver for their receptor system.

If that was the case then it's probably never going to happen with Wine as Wine is not going to license anything.

That's my guess, which might be wrong.

------

Can I use Wine to install drivers for my hardware?

No. Wine requires your hardware to already be working on your operating system. The technical reason for this is that Wine, like most applications, runs in user mode and not kernel mode

-------

>3. Is it basically a computer (motherboard, CPU and hard drive), but with optimized software for running VSTs?

Yes it is an optimized computer... "optimized" is the key word here :wink:

We've developed our own OS based on Linux and WINE that is specifically optimized to play Windows VST plug-ins. We also have our own custom software front end for mixing stacking, tweaking (and saving!) patches as well as display the origin GUI presented by the developers. We also have a custom
version of iLok so that installation is the same for each plug-in. We also have special Ethernet based communication software that enables you to see the Muse Control front end software, and edit everything inside of
Receptor from the comfort of the screen of your host computer. Also, Receptor
has a custom hardware front panel that enables full control from the front of the box.

>Is so, what type of CPU, hard drive, etc?

We are currently utilizing an AMD Athlon 2500. Please note that with our
optimized OS the levels of efficiency outstrip comparable Windows and Apple
systems running on similar processors.

We include a 40GB hard drive (there are 4 USB 2.0 ports on the back if you
need extra space). We ship with 256 MB of RAM, expandable to 2GB.

My guess would be that since Windows hardware drivers are not supported in Wine (because of many technical reasons) that Muse Research might have got (licensed) programming specs from ILok and then wrote a Linux driver for their receptor system.

I was emailing with the guy who did it a few years back. And he said he didn't get any help from PACE. He did the wine tweaks on his own.

Quote:

Originally Posted by osxmidi

All wine processes using the same wineserver (i.e.: same user) share certain things like registry, shared memory and kernel objects.

Also, any instance of a vst needs it's own block of shared memory to copy (that vst instance's) audio etc from a Linux process to a Wine process and the shared memory needs to be large enough to cover the amount (of that vst instance's) audio tracks.

Do this as a test. Load 16 instances of Kontakt on 16 tracks in Reaper with no instruments loaded. On my system (Manjaro/KDE) with latest Wine Staging, each instance of Kontakt takes up 250MB when looking at system memory usage. So it does not seem to be sharing memory. On Windows, the first instance of Kontakt will take 250MB and then every other instance of Kontakt takes a very small amount of memory.

Next test, load two instances of Kontakt, each with the same instrument. In Windows, only the first instrument instance is loaded into memory. The second duplicate instrument shares memory with the first and doesn't add to the memory usage. In Linux/Wine, they each take up the same amount of memory - so double the memory usage. Again, indicating that memory is not being shared in Wine.

Quote:

Originally Posted by osxmidi

I think I've got the vst instance shared memory at around 5MB or so, and it could go down a bit more.

I'm very sorry if I'm not understanding here, but shouldn't the shared memory per VST instance be MUCH higher for instruments like Kontakt? 5MB won't even load the blank plugin with no samples loaded. Having only 5MB of shared memory for multiple Kontakt instances or Omnispheres etc. doesn't seem like it would be of any help at all.

In a perfect world, Steinberg should have done the VST specification in an OS independent way, providing all necessary stuff and disallowing the plugins to use the OS API directly.

If Steinberg had done that, developers would have immediately demanded those restrictions to be removed, especially back in the day when everybody wanted to do their own low level tricks to get performance and "just because". The restricted and sandboxed approach Propellerhead did for their Rack Extensions apparently works "OK", but the Rack Extensions format hasn't really catched on...

Anyway, there's a way to do fairly OS independent VST plugin code : just don't have a GUI for them...

__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

I'm very sorry if I'm not understanding here, but shouldn't the shared memory per VST instance be MUCH higher for instruments like Kontakt? 5MB won't even load the blank plugin with no samples loaded. Having only 5MB of shared memory for multiple Kontakt instances or Omnispheres etc. doesn't seem like it would be of any help at all.

That memory sharing is not about Kontakt's etc internals (which wouldn't know anything about Linux and Wine anyway), but about the streaming audio, MIDI and parameter data. Not much memory is needed for that. (128 channels of 32 bit floating point mono audio with a buffer size of 512 samples would use about 256 kilobytes of memory.)

If the Wine based hosting uses a separate process for each plugin, then the plugin instances can't share memory between each other without some special code added to accommodate that by the plugin developers.

When multiple instances of the same plugin are loaded into the same process, like happens by default on most Windows hosts, the plugin instances can trivially share memory between each other. (Actually that easy memory sharing has been the cause of many bugs in plugins in the past.)

__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

If, there is a synth that works in/on WINE right now then I was hoping then there is such a thing of choosing to rely on the best of the worst components or something of Windows stuff and others could do the same, maby not as simple? heh

Same as steam play proton, such a good idea, but as soon as the devs update the game for the better, they might forget about the proton thing as it was a Windows game from start.. hmm. *whine*

To get more people on to Linux is important so they see business for it worth their time, or, summit.. i'm not into politics.

I was emailing with the guy who did it a few years back. And he said he didn't get any help from PACE. He did the wine tweaks on his own.

Do this as a test. Load 16 instances of Kontakt on 16 tracks in Reaper with no instruments loaded. On my system (Manjaro/KDE) with latest Wine Staging, each instance of Kontakt takes up 250MB when looking at system memory usage. So it does not seem to be sharing memory. On Windows, the first instance of Kontakt will take 250MB and then every other instance of Kontakt takes a very small amount of memory.

Next test, load two instances of Kontakt, each with the same instrument. In Windows, only the first instrument instance is loaded into memory. The second duplicate instrument shares memory with the first and doesn't add to the memory usage. In Linux/Wine, they each take up the same amount of memory - so double the memory usage. Again, indicating that memory is not being shared in Wine.

I'm very sorry if I'm not understanding here, but shouldn't the shared memory per VST instance be MUCH higher for instruments like Kontakt? 5MB won't even load the blank plugin with no samples loaded. Having only 5MB of shared memory for multiple Kontakt instances or Omnispheres etc. doesn't seem like it would be of any help at all.

Did the Ilok tweaks work?

As far as I can tell, the Ilok usb needs Windows drivers from PACE.

Wine can't use Windows hardware drivers, so a Linux driver would need to be written and the driver programming specs would need to come from PACE.

I assume that PACE isn't going to give their driver programming specs to just anyone, so maybe a licensing deal could be done but that leaves WineHQ out.

The shared memory is how Xenakios explained it.

LinVst has local shared memory that has nothing to do with Wine, and it's currently around 5MB per instance and it could go down to around 3MB.