Reply to thread

Message: [QUOTE="Shamiso, post: 92682, member: 160"] Zrythm v2 alpha.3 supports VST3, CLAP, LV2, LADSPA, and AudioUnit plug-ins, while VST2, DSSI, SFZ, and SF2 remain unported. The format list looks decent at first glance, but it is not the same plug-in setup longtime Zrythm users had in v1. A lot of confusion comes from Zrythm's own older pages. The main features page still talks about Carla and advertises a wider collection of formats, while the current v2 codebase has moved away from that architecture. If you are testing the alpha now, the [B][URL='https://goldmidi.com/community/threads/zrythm-v2-alpha-opens-for-public-testing.78064/']Zrythm v2 alpha testing release[/URL][/B] is the useful baseline, not a v1 manual page that happens to rank well. [HEADING=2]The v2 plug-in stack no longer depends on Carla[/HEADING] Alpha.1 started the rewrite with VST3, LV2, LADSPA, and AudioUnit support through the new host architecture, while CLAP received native support. Alpha.3 pushed VST3 much further, adding resizable embedded editors, bypass controls, A/B state comparison, persistent program tracking, searchable presets, parameter groups, and a diagnostics row showing DSP load and latency. Tempo-aware plug-ins also get better host information now. Alpha.3 sends play state, tempo, time signature, and musical position to VST3 and CLAP plug-ins, so an effect or instrument that syncs to the project has more of the timing context it expects. CLAP plug-ins can also use the host's thread-pool extension when they support parallel processing. Alpha.3 fixed a nasty first-cycle bug too. Plug-in parameters could previously be zeroed when processing started, resetting patches in plug-ins such as Surge XT. It is worth knowing if you tested an earlier alpha and wrote off the host after seeing a saved sound come back wrong. Routing changed underneath this too. Plug-in bus changes at runtime can detach and revive ports without throwing away their connections, while sidechain buses are kept out of automatic track-chain wiring and connected explicitly. Those details matter more than another checkbox in a format table once you start using multi-output instruments or sidechain-heavy effects. Plug-ins without their own interface are not dead ends either. Alpha.2 added a generic parameter editor for plug-ins without a native UI, and alpha.3 added type and format filters with persisted search in the plug-in browser. It is a small quality-of-life change, but it makes a mixed folder of instruments and effects less annoying to navigate. For everyday testing, browsing, opening, and troubleshooting plug-ins now feels closer to a normal DAW workflow. Carla is the clean break. Alpha.3 removed Carla hosting after it had already been disabled, so old instructions that treat Carla as the route to extra formats no longer describe v2. The [URL='https://goldmidi.com/community/threads/zrythm-v2-is-still-missing-key-v1-features.78094/']current list of missing v1 features[/URL] also makes the consequences pretty plain. [HEADING=2]VST2 and SoundFonts are still outside the current set[/HEADING] VST2, DSSI, SFZ, and SF2 support remain on the not-yet-ported list. A collection built around old VST2 effects or SoundFont instruments therefore needs more checking than a newer rack built around VST3, CLAP, or LV2. Linux users have an extra wrinkle because a plug-in format and an actual Linux build are separate things. Zrythm can host VST3, but the plug-in vendor still has to ship a compatible Linux binary, and [URL='https://goldmidi.com/community/threads/what-a-native-linux-vst3-build-actually-gets-you.76199/']native Linux VST3 support has its own compatibility limits[/URL] around platform builds, libraries, and distribution baselines. AudioUnit belongs to the supported list as well, but it is an Apple format rather than a portable option you can carry across all three desktop systems. If your projects have to move between macOS, Windows, and Linux, VST3 or CLAP usually gives you a cleaner starting point when the same plug-in vendor actually ships those builds. [HEADING=2]Plug-in sandboxing is still a missing safety layer[/HEADING] Optional plug-in sandboxing has not returned from v1. Without that isolation layer, you should be more conservative with unstable third-party plug-ins during an alpha test, especially in projects you care about keeping intact. The idea behind [B][URL='https://arxiv.org/abs/2003.00572']process isolation for untrusted native code[/URL][/B] is well established outside music software too. Running risky code across an isolation boundary can reduce the blast radius when it fails, although the design has to respect performance costs and communication overhead. Zrythm v2 currently has a separate plug-in scanner process, but scanning and sandboxed real-time hosting are different jobs. A scanner can probe plug-ins before you instantiate them without automatically giving every loaded instrument or effect its own crash-resistant process during playback. Windows ARM adds one more odd but useful detail. Alpha.3's experimental ARM64EC build runs Zrythm natively on ARM64 while still loading x64 plug-ins in-process, which can make an existing Windows plug-in folder more usable during the architecture transition. It does not restore VST2 or sandboxing, but x64 plug-ins can remain usable on Windows ARM without a separate compatibility bridge around the host. [/QUOTE]

Name