Nope, just some simple old content farming. That can entail a wide variety of all the fertilizer you mentioned. I see no screenshot. Save the rest of it. In only a low number of posts, you were already on ignore list. Despite the nice features here, I can't put you on ignore twice.

For you to even type something when a simple screenshot of shell would take 10 seconds, it's pretty obvious how you should proceed.

When you make comments like this one, then to try to play the victim, trolling.

 

Last edited: Nov 4, 2025 at 9:05 PM

How can insulting your fellow craftsmen for their choice of tools make you a better craftsman, let alone human being. This is just plain pathology.

But for you curious fellow Linux enthusiasts, I uploaded these two snippets
https://limewire.com/d/7iCMi#ciqo7x5oO2

 

Last edited: Nov 4, 2025 at 10:05 PM

Let's get on to the gaslighting. This is the sort of thing that got you ignored in the first place, I'm sure.

Still no screenshot? When I see one, i will waste more of my time.

 

If you have any decency left you will apologise now, but if it's too much for your overinflated sense of grandeur, I'm looking forward to being ignored by you.

 

Yep. It is an Apple M1 with Linux Asahi on it. Well done!

 

I've just added a video of a rerun of a test that AS member Martel and I did around two years ago. We then compared max channel count on his Windows laptop vs my M1 iMac running MacOS.

We used Reaper as a DAW. Every channel had one instance each of ReaControlMIDI, ReaSynth, and ReaDelay, playing a 2-bar long 4-note chord. 44.1 kHz/24-bit, 1024 samples.

I managed to squeeze over 1100 channels before getting audible clicks. However, it was summer and I had no aircondition in a tiny room. Later in the winter I repeated the test in an unheated room and got 1475 channels on the same iMac.

Tonight I got 2835 channels using the same test project in Reaper, but this time on my M1 Pro MacBook Pro (8 performance cores) running Asahi Linux, in a moderately heated room.

https://limewire.com/d/7iCMi#ciqo7x5oO2

 

Last edited: Nov 4, 2025 at 11:27 PM

Thanks for the compliment!
I'm now getting it done on Linux but it's way less easy as I know it from windows, at least on Arch Linux.
Tried to install Bitwig over there, ended up unpacking the *.deb archive and moving the files manually
because Arch doesn't support debian packages. And for every step I had to run processes elevated
and type in my password (which I then removed through root access via the bootloader).

I might switch partly to linux as a 2nd OS but I keep beeing a windows user with a heavily modified
windows for getting rid of all that crap like automatic updates, bitlocker, online account enforcement,
TPM, AI, recall, copilot, defender, etc.

 

Only took 24 hours to come up with a workaround for a simple screenshot that would have date, and other embedded ways of showing it was actually what it is purported to be? What a surprise, still no screenshot. And only at the cost of exposing why the new user account.
And running a plugin collection that looks like it is from the Salvation Army.

Regular Mac VST3 and AU plugins cannot be loaded or bridged under Linux on M1 or Modern Apple Silicon processors. There is no macOS to Linux equivalent bridge because of Apple’s licensing and closed frameworks. Now you are going to use a Apple Silicon Mac to Run Linux, to then run a regular Windows bridge like Yabridge to run Windows plugins on a Mac. That sounds efficient.

Regular Mac VST3 and AU plugins cannot be loaded or bridged under Linux on M1. Keep that part in mind. Now emulation of Windows ARM plugins? Nice stacking of abstraction layers.

So if you are using your DAW as a tape recorder, then have over 200 channels of audio sounds impressive to idk who. Probably someone who doesn't know MacOS, but realizes they now make very fast processors for reasonable prices. That's why you are stuck running freeware software that even the PC Linux users won't even bother with inside a DAW other than Protools, Logic, Cubase. But you can always flip back to that "unimpressive" MacOS and use some real effects and synth plugins when you need to.

This makes lots of sense.

 

Last edited: Nov 5, 2025 at 12:24 AM

24 hours?
No screenshot?
New user account?

Are you drunk or simply losing it?

Look, your entire crusade is based on no direct experience with music production on Asahi Linux whatsoever, so the whole time you have been talking out of your rear end, but what you are saying now is downright pathetic.

You have made a fool of yourself and whatever you write from now on, no matter what topic, will have to be taken with a huge pinch of salt, because you don't seem to be able to control your output at all when there's something or someone you find annoying for whatever reason.

 

Last edited: Nov 5, 2025 at 12:39 AM

I migrated to Linux like 5 months ago and felt compelled to create an account to reply to this lol.

My experience so far has been great, but it's very closely related to who I am as a person (and how I see music making).

First off: migrating to Linux made me rethink how I approach music making and creativity in general. It made me more minimalistic with my plugin count, while also giving me a huge incentive for using DAW stock devices to their full extent (in my case, I use Renoise and Bitwig).

But not because the plugins don't work (I'd say 95% plugins I tried to bridge worked flawlessly, some DRM caveats). Instead, because there's a substantial loss of performance for several plugins, and specially in VST3. When I migrated I was very persistent on making Windows stuff work, and even managed to make most of the plugins work fine. Now I'm like: "if it's not Linux native I'm not bothering, unless it's something REALLY missable.". I've been dropping non-Linux native plugins like crazy. Stuff I thought I needed but never really did, and was only getting on the way of my creative process. I don't need 20 different compressors, 20 EQs, 20 reverbs, etc. I need a couple good ones of each. If you have this mentality, it helps.

So here's tip number #1: Use a DAW that has good native devices. Bitwig is perfect for Linux for this reason. I barely need any 3rd party plugins with the amount of power it has to offer.

Tip #2: If you really need to use Windows plugins (with Carla or Yabridge), stick to VST2. The performance gain is HUGE in comparison to VST3, an the UI problems are way less frequent. Ask a LLM why if you're curious, I won't bore you with the details.

Tip #3: Create separate Wine prefixes for different plugin brands - this ensures samey plugins use the same dependencies and prevents you from breaking the prefix while trying to fix a certain brand that need specific packages (such as the DXVK, which btw crashes VST3 UIs lot on my AMD GPU). You can easily do this by opening the terminal and doing this:

WINEPREFIX=<path> wineboot

Then, when installing the plugins, do

WINEPREFIX=<path-to-prefix-you-just-made> wine "Installer Name (Please Stop Putting Spaces On Installer Names, Guys).exe"

By the way, Tip #4: Use winetricks to install and manage packages for your Wine prefixes. Most plugins will work fine on a clean Wine-staging 9.21 prefix, but others will need specific stuff. The following packages are notable for fixing problems when a clean prefix doesn't work out for your desired plugin: corefonts, vcrun2022, vcrun6sp6 (some installers will give you a MFC140.dll error without this package), dgiplus, and dxvk (only as a last resort when I have the "black GUI" bug - which is fairly common on VST3s). For example, if you have the MFC140.dll error when installing plugins from a certain group:

WINEPREFIX=<path-to-prefix-you-just-made> winetricks corefonts vcrun6sp6 vcrun2022

Now just add the plugin DLL path to yabridge using the yabridgectl command (check the github for instructions) or drag and drop the DLLs to Carla Rack plugin. Ez.

People will say "Linux is a nightmare!! !1 !"

But, honestly?

Skill issue, laziness or lack of time.

If you want to get rid of your shitty OS, it will take an effort.

In fact, OS companies are profitable because people are too lazy to do their homework (or maybe they just don't have time for it, which is understandable) and want to live in a comfortable position in which the companies just handle them what they want in terms of software, customization, etc. Personally, that's lame - specially in the times we're living, where companies own more and more of our time and personal affairs. But to each, his own.

Peace out and hope this was helpful.

PS: The whole reason why I started typing this was to recommend ZL Equalizer as a full on alternative to FabFilter Pro-Q, but totally forgot while yapping.

Go check it. Has linear phase mode, different processing modes, etc. Worth checking.

 

You’ve been using Linux for five months, you say? Who says Linux is so difficult? Look at you, you seem to have figured it out just fine....

Getting rid of your terrible OS is as simple as grabbing a flash drive. Download a distro ISO to create a live-Linux pendrive. Use Rufus, Balena Etcher, Ventoy, or any USB tool you like. You could even dust off the good old UNetbootin, though that’s been around so long before your epiphany those five months ago, it's nearly obsoleted. Once at a shell, fire up a partition tool like GParted, GNOME Disks, or libparted, wipe any partitions, rebuild the table, and format the disk however you want. Install the bootloader your distro recommends—Grub is standard—and drop the installer onto the brand-new partition. Done in an hour or less. Debian-style upgrades? apt-get update && apt-get dist-upgrade—and you’ll still have months left to ponder how “masterful” you are. Be happy you don’t even know what LiLo is, because that part of Slackware really did suck.

But now for the truly laughable puffery from MacOS guy, more specifically:

Why would anyone in 2025 install Linux on the slowest, oldest Apple Silicon MacBook—maybe even a MacBook Air—just to run REAPER and open-source plugins, when people on the newest, fastest M4 Max Apple Studio Macs are complaining that anything under Rosetta is unbearably slow? On that Air, you’re running non-native ARM64 builds that are often slower and less efficient than Intel plugins inside Rosetta2. You’ve also tossed all the AU plugins baked into macOS, which are deeply optimized, low-latency, and studio-proven. That’s a massive downgrade in performance and workflow.

And the payoff? Essentially nothing. Almost no professional-grade plugins exist as native ARM64 for Linux or Windows, so there’s no practical gain. Track count benchmarks on non-ARM64 laptops are purely academic, artificially generated numbers that rarely reflect a real project. Nobody in a real studio cares how many tracks a laptop can purport to show, and those numbers are seldom verified objectively. In the end, this is Running Linux to Say You’re Running Linux 101: slower plugins, fewer options, zero real-world benefit, and yet somehow the bragging rights you are trying to cling to. That dual boot is still dual boot for a reason. And still no....well you get the idea.

 

"Mommy, mommy, those boys over there play with their ugly toys and I tell them that my toys are so much better and they still play with their stupid ugly toys and I tell them they are stupid and they still play with them boohoo mommy nobody loves me!"

 

Last edited: Nov 5, 2025 at 2:33 PM

That's very interesting... I wish I knew it earlier, my entire plugins catalogue (200+) is VST3 or sometimes CLAP. I ain't got time now to reinstall all of them, even if some are actually bundles . I wonder what's causing it - if it's some CPU thing, then that would explain my experience with disabling SMT. Right now I do not feel the need for more performance, but maybe if I get to the point where everything starts grinding to a halt, I might.

What hardware are you using? RAM/CPU?

Yeah, that's exactly what I'm doing with bottles! Although honestly it's like 3 prefixes for now - 1) stuff that works with wine 10, 2) stuff that works with wine 9.21 3) stuff that needs special attention
And bottles lets me do all that managing without remembering long command chains and exact package names :sweat_smile:
plug with the wineloader script, I can have more than one wine runner for different plugins.

yup, a different forum was very impressed with ZL EQ, too, but I love some of the fabfilter features, AND their presets ‍chef's kiss
if TAL-EQ can match those, I'd probably grab that one instead.

EDIT: I wish this forum supported (UTF-)emojis :D

 

Last edited: Nov 5, 2025 at 11:40 AM

Yes, it was. Thank you! I did not know about VST3 being more performance demanding than VST2. I always thought it was the other way around so I would not install VST2. Good to know!

I also was surprised by the easiness of getting comfortable with Linux for daily use. And also my experience is that most of windows plugins work out of the box under Wine. Only when special libraries are needed it can get difficult. But a lot of windows users seem to "forget" that they also have to install some extra libraries to get those plugins working.

What it makes extra difficult in Wine is that your setup can work, but the plugin doesn't. Or the installer terminates with an error that says nothing. If the error tells you that some .dll file is missing, you can probably solve that without too much knowledge. But no error, no clue what to install extra.

Funny: you mention the black window. I don't recognize that in Reaper. In my case not working plugins show a white window, for example Pianoteq 9. And then I have two possibilities: the UI button works and shows al the parameters in table style which is doable for some VST's but not so much for VSTi's. Or I get a white windows with nothing further. And those situations cannot be solved without help of experts. And I can understand that these situations will spoke off a lot of potential new Linux users......

 

VST3 in Cubase and Nuendo - Technical Background

In 1996 Steinberg introduced the first version of the audio plug-in standard VST (Virtual Studio Technology). Three years later VST2 allowed for using virtual instruments for the first time.

VST3, introduced in 2008, is the latest standard for effect plug-ins and virtual instruments. It marks an important milestone in virtual studio technology and incorporates countless updates, enhancements, changes and new features. Following is a brief overview of the major new features included with VST3 and a FAQ section.

Improved Performance

Some current plug-ins are known to be heavy on CPU load. Managing large plug-in sets and multiple virtual instruments on typical project studio computer systems can often be difficult because of CPU performance limits. VST3 helps to improve overall performance by applying processing to plug-ins only when audio signals are present on their respective inputs. So instead of always processing input signals, even when there is only silence present, VST3 plug-ins can apply their processing economically and only when it is needed.

Multiple Dynamic I/Os

VST3 plug-ins are no longer limited to a fixed number of inputs and outputs. Their I/O configuration can dynamically adapt to the channel configuration they're inserted in. For example, the new VST3 plug-ins in Cubase 4 can work in stereo-mode when inserted into a stereo channel, but switch to 6 channels when inserted into a 5.1 channel. In any case, each audio channel is processed independently. Interaction between channels depends on the type and design of the plug-in. While it is still eligible to have dedicated surround plug-ins, basically any VST3 plug-in can be surround-capable with true multi-channel processing. In addition to their flexible audio bussing capabilities, VST3 plug-ins may also offer a dedicated event bus. Typically, this is a MIDI input for control/modulation but these busses are no longer restricted to MIDI standard only. Future plug-ins may replace the common MIDI interface with alternative control methods.

Activating/Deactivating Busses

A typical issue with current virtual instruments is their audio output bussing system and how they are connected to the mixer after loading. Especially virtual samplers with multiple outputs often occupy more mixer channels than needed. The VST3 interface offers the possibility to deactivate unused busses after loading and even reactivate those when needed. This cleans up the mixer and further helps to reduce CPU load.

Routing Possibilities

Plug-ins can be connected to the host environment in many different ways: Future VST3 Instruments can have audio inputs. As an example, a synthesizer that offers a built-in vocoder will be able to directly receive an audio signal to control the effect. A VST3 plug-in may have multiple MIDI inputs at the same time.

Note Expression (since VST 3.5)

With Note Expression, each individual note (event) in a polyphonic arrangement can contain extensive articulation information, which creates unparalleled flexibility and a much more natural feel of playing. Articulation messages are no longer bound only to channels, but can now be used for every single event.

All our sequencers since version 4 are installed with a complete new set of plug-ins, according to this new VST3 specification. You can still use VST2 plug-ins and instruments as well of course. Please note the FAQ below for additional information to this. For plug-ins, which have been created according to the very old VST1 specification, please note that correct functionality is not warranted anymore.


VST3 - Frequently Asked Questions

With VST (Virtual Studio Technology), Steinberg established the world's leading and most widely supported standard for plug-ins and virtual instruments. Here are just the key facts about VST3 as well as some answers to frequently asked questions:

What is VST3?
VST3 is the next major revision of Steinberg's Virtual Studio Technology and follows VST 2.4, which is the latest current version of VST. VST3 is a plug-in standard, not a product or host application. In order to run VST3 plug-ins or instruments, the host application must also support VST3.

Can I still use my existing plug-ins and instruments?
Yes. Existing VST 2.4 plug-ins and instruments are fully compatible with our current host sequencers. Any plug-in or instrument older than VST 2.4 must be tested and potentially updated.

Can I load projects from my previous Cubase version?
Yes. Projects created in Cubase SX or later can be opened in Cubase and Nuendo 4 or later and included plug-ins should work as expected if they were designed and tested for VST 2.4.

Can my old plug-ins and instruments also use the benefits of VST3?
Yes, they can. Although they do not offer the exclusive features of VST3 such as sample-accurate automation, improved performance or dynamic I/Os. VST2 plug-ins may benefit from VST3s new preset handling. FXB or FXP presets can be converted into VST3 preset format.

Is VST still an open and free standard?
Yes. VST is still an open and free standard.

Where are VST3 plug-ins installed?
In contrast to VST2 plug-ins, all VST3 plug-ins share the same installation folder. So it's easy for both host sequencers and users to find the VST3 plug-ins. These are the installation paths defined in the VST3 specifications:

• Windows 64 Bit: C:\Program Files\Common Files\VST3
• Windows 32 Bit: C:\Program Files (x86)\Common Files\VST3
• Mac OS X: Library/Audio/Plug-ins/VST3

Source: https://helpcenter.steinberg.de/hc/...ST3-in-Cubase-and-Nuendo-Technical-Background

 

Thanks for the explanation PulseWave, but I still do not understand how VST2 is performance wise better than VST3?

 

Yes, forget to confirm that. I sadly experienced that at first with Kontakt. It worked just out of the box. Then I had a problem installing a new plugin and another one. I got them working but then I noticed that Kontakt had stopped working. Bummer. Now I know......

 

I still need to convince you a little more; it's more modern and faster than VST2:

Spoiler: Source: Grok KI

The confusion is understandable—VST3 is technically more efficient in almost every way, and Steinberg (the creators) market it as the superior, modern standard. Yet, in real-world DAW performance, many users and benchmarks report that VST2 plugins often use less CPU than their VST3 counterparts. Here's why this happens, even though VST3 was designed to be better:

Why VST2 Can Outperform VST3 (in practice)

Factor VST2 VST3 Why VST2 Wins in CPU

Silence Processing No concept VST3 must process silence if told to VST3 plugins cannot skip silence unless the host explicitly tells them. Many hosts (especially older ones) don’t optimize this, so VST3 keeps processing even when silent → wasted CPU.

Event-Based Processing Processes every block Only processes when input changes VST3 can theoretically save CPU by skipping unchanged audio, but only if the plugin is coded to detect silence. Poorly coded VST3s process every sample anyway.

MIDI CC Handling Simple buffer Precise timestamps + event lists VST3’s precision is great for timing, but more complex = more overhead per event.

Host Implementation Mature, universal Varies wildly by DAW Many DAWs (even modern ones) have buggy or incomplete VST3 hosts. Cubase is best; others lag.

Plugin Developer Habits Lightweight, predictable Over-engineered or sloppy Many devs copy VST2 code into VST3 without optimizing for event-based processing → VST3 version is heavier.

Real-World Example (Waves Plugins)

• Waves CLA-2A (VST2): ~0.8% CPU (idle)
• Waves CLA-2A (VST3): ~1.5% CPU (same settings, same silence) → VST3 version keeps processing silence because Waves didn’t implement silence detection properly.

When VST3 Is Better


Scenario Winner
Heavy modulation (LFOs, envelopes) VST3 (event-based = less CPU when parameters change slowly)
High track counts with automation VST3 (if host supports it)
MIDI precision (e.g., arpeggiators) VST3
Multitimbral instruments VST3 (native multi-output)

Bottom Line
VST2 is often lighter not because the format is better, but because:

1. It forces no silence processing → predictable low CPU.
2. It’s simpler → less room for inefficient code.
3. Hosts and plugins are more mature in VST2.

VST3 has higher potential efficiency, but only when:

• The plugin is coded to skip silence/events.
• The host (DAW) fully supports VST3 optimizations.

Pro Tip

• Use VST2 for CPU-heavy static plugins (compressors, EQs with no modulation).
• Use VST3 for dynamic plugins (synths, delays with tempo sync).
• Test both versions in your DAW with your workflow.

Let me know your DAW and plugin examples—I can check specific benchmarks!

 

Lets summarize shall we?
- VST3 helps to improve overall performance by applying processing to plug-ins only when audio signals are present on their respective inputs. VST3 plug-ins can apply their processing economically and only when it is needed.
- VST3 plug-ins are no longer limited to a fixed number of inputs and outputs.
- The VST3 interface offers the possibility to deactivate unused busses after loading and even reactivate those when needed. This cleans up the mixer and further helps to reduce CPU load.
- A VST3 plug-in may have multiple MIDI inputs at the same time.
- with VST3 Articulation messages are no longer bound only to channels, but can now be used for every single event.

 

Yes, VST3 is better, but you need to put Wine into the equation. In my experience so far, VST2 has been a lot less buggy in Wine than VST3.
For example, Addictive Drums 2 UI doesn't even load on VST3 version for me until I install DXVK. And, after that, the UI gets buggy for clicking and the plugin eventually crashes. But VST2 works perfectly. Yabridgectl documentation tells to stick to VST2->VST3->CLAP when possible, but that was not the experience I had so far. Other samples: Sonible, Devious Machines, DMG Audio... None of these work properly for me under Wine-staging 9.21 on VST3 versions. When I switch to VST2, boom, all these problems are gone...

I recommend just giving it a try and doing tests for yourself. Carla Rack can also measure DSP load so you can have a more objective comparison.
VST3 is good, yes, but it was never thought for Wine bridging.

Since we're groking:

Spoiler: Source: Grok

Adding Wine (via yabridge or Carla) into the mix introduces an extra layer of complexity to the VST2 vs. VST3 debate, since you're now bridging Windows plugins into a Linux DAW environment. This can amplify the original issues (like immature host support and poor silence detection) while adding Wine-specific overhead for process management, IPC (inter-process communication), and GUI rendering. However, tools like yabridge are specifically built to minimize this, often flipping the script in favor of VST3's theoretical advantages. I'll break it down based on real user reports, benchmarks, and dev notes from the Linux audio community.

Why the Equation Changes with Wine/Yabridge/Carla
Wine runs Windows DLLs (plugin binaries) in a compatibility layer, which inherently adds ~5-10% baseline CPU overhead compared to native Linux plugins—mostly from emulation, threading, and memory mapping. Yabridge (a Wine-based bridge) and Carla (a multi-format host that can wrap Wine-bridged VSTs) handle this differently:

• Yabridge: This is the gold standard for transparent VST bridging on Linux. It sandboxes each plugin in its own Wine process but optimizes heavily. Recent versions (5.x+) reduce VST2 overhead dramatically (down to near-native levels), but VST3 shines here because its event-based design aligns better with yabridge's concurrent architecture—leading to lower latency spikes and better multi-instance sharing.
• Carla: More flexible (can rack/bridge VSTs internally), but it adds another abstraction layer on top of Wine. This can increase CPU by 2-5% extra for complex event handling, making VST3's precision a double-edged sword (more overhead if not optimized). Carla + yabridge is a common combo for stability.

In short: Native DAWs (e.g., on Windows/macOS) often favor VST2 due to maturity. In Linux bridging, VST3 can pull ahead if the setup is tuned, but VST2 remains the "safe" low-CPU choice for glitch-free operation.

Even with yabridge’s optimizations, VST2 often wins on stability and lower effective CPU in Wine setups. Here's why your gut feeling is backed by data and community consensus:

VST3 uses more Win32 calls → Wine GUI thread blocks
Parameter automation lag → Event queue backlog in high-track projects
Random crashes → Poorly wrapped VST3 DLLs (e.g., iZotope, older NI)
Carla rack bloat → Double-bridging: DAW → Carla → Wine → VST3

VST3 "should" save CPUOnly if the plugin and host and Wine bridge all play nice. In practice: rarely.
VST2 is "legacy"But it’s predictable, lightweight, and battle-tested in Wine.

Also, yes, white window on Reaper, but on Renoise it's black ;)
Same bug, though. Lots of times solved with DXVK or switching back to VST2.

 

Last edited: Nov 5, 2025 at 7:29 PM