Reply to thread

Message: [QUOTE="Shamiso, post: 92688, member: 160"] Zrythm v2 alpha.3 now has an experimental ARM64EC build that runs native Arm code while loading x64 plug-ins inside the same process. It is a fairly unusual middle ground for music software because the host can move onto Windows on Arm without demanding that every existing plug-in in your folder has already been rebuilt for Arm. The important bit is what ARM64EC actually does. The [B][URL='https://goldmidi.com/community/threads/zrythm-v2-alpha-opens-for-public-testing.78064/']Zrythm v2 public testing build[/URL][/B] can use Microsoft's compatibility ABI so Zrythm's ARM64EC code executes natively, while x64 code loaded into the process runs through the x64 emulation built into Windows 11 on Arm. [HEADING=2]ARM64EC keeps old x64 plug-ins in the same process[/HEADING] Microsoft designed ARM64EC around mixed execution. An ARM64EC process can load ARM64EC and x64 binaries together, which is exactly the behavior Zrythm is using for plug-ins. You do not need a separate bridge process simply because a VST3 binary is still x64. The catch is that the x64 plug-in does not magically become native Arm code. Windows still emulates its x64 instructions, so a session can contain native ARM64EC host code beside emulated x64 plug-in code. CPU cost therefore depends on what part of the workload is actually running natively and what is still going through translation. This is why the setup is more interesting than a normal x64 build running entirely under emulation. Zrythm can move its own hot paths toward native Arm execution without waiting for every third-party developer to ship Arm binaries first. The broader idea lines up with [B][URL='https://arxiv.org/abs/2512.00487']mixed native and translated execution[/URL][/B], where selectively running compatible work natively is used to reduce the all-or-nothing cost of cross-architecture emulation. Compatibility still stops at the plug-in formats Zrythm v2 currently hosts. ARM64EC does not restore VST2, DSSI, SFZ, SF2 or Carla hosting, so an old x64 plug-in is only useful here if its format is already supported by the current v2 host. The [URL='https://goldmidi.com/community/threads/zrythm-v2-plugin-support-is-narrower-than-v1.78096/']Zrythm v2 plug-in support changes[/URL] matter before CPU architecture even enters the conversation. [HEADING=2]Windows 11 is the practical floor for ARM64EC[/HEADING] Zrythm's alpha download page labels the Windows ARM64EC installer experimental and lists the general Windows requirement as Windows 10 version 1809 or later, or Windows 11. ARM64EC itself is more specific. Microsoft documents it as a Windows 11 on Arm feature and says it is not available on Windows 10 on Arm. So the generic Windows requirement should not be read as proof that the ARM64EC installer is meant for Windows 10 on Arm. For this build, Windows 11 on Arm is the safer compatibility baseline because the operating system provides the x64 interoperability ARM64EC relies on. There is another architecture wrinkle. ARM64EC code is built to interoperate with x64, but Microsoft says a normal ARM64 binary uses a different ABI and cannot simply be loaded into an ARM64EC process the same way. An Arm-native plug-in is not automatically the ideal match just because the machine itself is Arm based. Arm64X binaries can cover both worlds, but ordinary plug-in vendors may ship x64, ARM64, ARM64EC, Arm64X, or some subset depending on their toolchain. For Zrythm alpha testers, the practical compatibility question is therefore more specific than whether a vendor advertises Windows on Arm. You need a binary that the host process can actually load. [HEADING=2]The experimental label still matters[/HEADING] Alpha.3 is the first Zrythm release to ship these Windows ARM64EC installers, and the project still labels them experimental. New architecture support is landing at the same time as a rewritten host, new native VST3 handling, multichannel routing changes and a long list of alpha fixes. Existing sessions also do not gain a free migration path just because their plug-ins can load. Zrythm v1 and v2 project files remain mutually incompatible, so the [URL='https://goldmidi.com/community/threads/zrythm-v1-and-v2-projects-are-not-interchangeable.78101/']v1-to-v2 project boundary[/URL] still applies on an Arm machine. A useful test is therefore smaller than moving your whole production setup. Start with the ARM64EC build, scan a few x64 VST3 or CLAP plug-ins you actually use, check their interfaces and preset recall, then watch CPU behavior during playback. A plug-in loading successfully proves binary compatibility, not identical performance to an Arm-native build. The interesting part is that Windows on Arm users no longer have to choose between an entirely emulated x64 DAW and waiting for a completely native plug-in ecosystem. Zrythm can run substantial host code natively while keeping compatible x64 plug-ins alive inside the same process, which makes the transition usable before the software around it has all caught up. [/QUOTE]

Name