Reply to thread

Message: [QUOTE="Queen, post: 90774, member: 27"] Steinberg shipped preview Linux support in the VST3 SDK back in March 2017, which makes native Linux plugins a retrofit rather than a founding idea. Nine years is not long in plugin terms. Before that, running commercial plugins on Linux meant emulation or nothing at all. The formats that grew up on the platform, LADSPA first and later LV2, were built by the free software community and largely ignored by the companies actually selling plugins. That history still shapes what lands on your machine. A native Linux build is genuinely worth having, and it is also narrower than the same vendor's Windows or macOS offering in ways the spec sheet never spells out. [HEADING=2]There is no Linux equivalent of Audio Units[/HEADING] Look at any cross-platform plugin listing, and you will see VST3 for Windows, VST3 and AU for macOS, then VST3 alone for Linux. That asymmetry is not laziness on anyone's part. Audio Units is part of Core Audio. It is Apple infrastructure, welded to macOS, and no version of it exists for anything else. A vendor supporting Linux therefore has exactly one commercial format available, and that format is VST3. LV2 is the alternative, and it is the only modern plugin API genuinely native to Linux. It carries well over a thousand plugins, most of them free software, and almost no proprietary vendor ships it. Only two hosts, Qtractor and Zrythm, handle every major API at once. VST2, meanwhile, is closed. Steinberg stopped issuing SDK licenses in October 2018 and said it was shutting the format down for good, so the old fallback of hunting for a VST2 build is a shrinking pool rather than a plan. VST3 did not exactly arrive to applause either. The SDK is large, it enforces UTF-16 for strings, and it redesigned MIDI handling with no fallback to the older approach, so anyone maintaining both formats faced real engineering rather than a recompile. CLAP is the newer answer to that. It is an open format picking up support across free and commercial software alike, which finally gives Linux a second modern option that nobody has to license from a competitor. [HEADING=2]Running Windows plugins through a bridge works, until it does not[/HEADING] The other route is [B]running Windows plugins through a Wine bridge[/B], and the standard tool for that job is yabridge. It handles VST2, VST3, and CLAP, including 32-bit plugins loaded into a 64-bit host. It also works inside tight margins. Version 5.1.1, released in November 2024, is tested against Wine Staging 9.21, and the project states plainly that Wine 9.22 and Wine 10.x do not work with it. Upgrading your distribution can quietly break your plugin rack. The exceptions list is specific rather than hand-wavy. iZotope and D16 Group plugins cannot be authorized because of Wine limitations. Waves V13 VST3 plugins have memory problems and will likely crash at random. Flatpak packages are not supported at all. None of that makes bridging pointless. It makes bridging a maintenance job, and that is the honest difference between a bridged plugin and one compiled for the platform you are running. [HEADING=2]The distribution version on a spec sheet is a hard wall[/HEADING] Here is the part that catches people out. When a vendor lists Ubuntu 22.04 or newer, that is not a note about desktop environments or package managers. It is a statement about glibc. Ubuntu 22.04 ships glibc 2.35. A binary compiled against that version will not load on a system carrying an older one, because glibc compatibility runs forward only, never backward. The plugin simply fails to appear, usually without an error you can act on. Copying the folder somewhere else will not help. Neither will a symlink, a permissions change, or a rescan of your plugin paths. The binary is asking the system for symbols that are not present. So when [B][URL='https://goldmidi.com/community/threads/m-media-audio-dropped-reference-player-third-rail-tube-eq.76097/']a plugin shipping a native Linux build on day one[/URL][/B] turns up, the number printed after the distribution name carries more weight than anything else in the listing. Every other line assumes the binary loaded in the first place. The consequence lands hardest on the people least likely to expect it. Long-term support releases are the sensible, boring choice for a machine that has to keep working through a session, and they are exactly the systems that fall behind a vendor's build baseline first. The more conservative your setup, the sooner native Linux plugins start quietly refusing to show up in your scan. [/QUOTE]

Name