Reply to thread

Message: [QUOTE="Shamiso, post: 92739, member: 160"] Nagi 0.15.0 lists Windows 10 and 11 x64, macOS Ventura or later, and Ubuntu 24.04 among its current platform requirements and verification points. The headline sounds simple because the app runs across all three desktop systems, but the details are not identical once CPU architecture, plugin format, and DAW support enter the picture. Windows users are expected to have at least 4 GB of free memory, while the macOS listing also recommends 4 GB or more. Linux is described differently. Ubuntu 24.04 is the distribution Nagi has been verified on, which is useful evidence of support but not a promise that every Linux distribution will behave the same way. The project itself can target Windows, macOS, and Linux with VST3 and CLAP output, either through a local setup or an isolated container. Anyone still sorting out basic export and DAW checks should use the [URL='https://goldmidi.com/community/threads/your-first-nagi-plugin-does-not-need-c.78147/']first Nagi plugin build[/URL] as the starting point, because platform compatibility only matters after the plugin itself works. [HEADING=2]Windows on ARM still produces an x64 plugin[/HEADING] Windows is the clearest place where “supported” needs a footnote. Nagi currently targets Windows 10 and 11 x64, and its product information says ARM64 Windows machines run the application through emulation rather than through a native ARM64 build. More importantly, plugins built from Nagi on those ARM64 machines are still x64. If you are using a Snapdragon-based Windows PC, the app running successfully does not suddenly turn the exported VST3 or CLAP into an ARM64 plugin. Distribution architecture still matters after the editor opens. The distinction is not academic busywork. [B][URL='https://doi.org/10.1145/3062341.3062371']Research on dynamic binary translation for ARM systems[/URL][/B] shows why software can bridge incompatible instruction sets efficiently, but translation remains a separate compatibility layer from running native code. Nothing in Nagi's current requirements supports claiming native Windows ARM plugin output. Standard VST3 installation on 64-bit Windows normally uses the Common Files VST3 directory under Program Files. Dropping a build into the expected folder only solves discovery, though. The host still needs to load that architecture successfully, so scanning and running are two separate checks. Label Windows builds accurately when you share them. An x64 binary is an x64 binary even if it was created on an ARM64 computer, and anyone testing release candidates should use the same architecture and host combination their intended users will actually run. [HEADING=2]macOS support still depends on the DAW format[/HEADING] The macOS requirement is Ventura or later, with 4 GB or more of free memory preferred. Nagi's [B][URL='https://goldmidi.com/community/threads/minimal-instruments-has-introduced-nagi-plugin-builder.78128/']cross-platform plugin-building workflow[/URL][/B] currently exports VST3 and CLAP, so operating-system support alone does not tell you whether a particular Mac DAW can load the result. Logic Pro is the obvious trap. Apple's current documentation describes third-party Logic plug-ins in the Audio Units format, while Nagi's present output list does not include AU. A VST3 or CLAP build from Nagi therefore does not become a Logic plug-in merely because both products run on macOS. VST3 itself is perfectly valid on macOS, with standard user and system plugin folders defined for hosts that support the format. The problem is not macOS rejecting VST3 as a platform. It is choosing a host whose plugin formats actually match what Nagi builds. Other Mac hosts can support VST3 or CLAP, so the same exported project may be perfectly usable elsewhere. Check the actual host format before treating “macOS compatible” as the finish line. Distribution introduces another layer too, especially signing and notarization, which the existing [URL='https://goldmidi.com/community/threads/apples-rules-push-small-plugin-devs-to-windows-first.75894/']macOS plugin release requirements[/URL] article covers in more depth. [HEADING=2]Linux verification is narrower than universal support[/HEADING] Nagi is currently verified on Ubuntu 24.04. Wording matters here because Linux compatibility depends on more than a kernel version, and a successful Ubuntu test does not automatically certify every distro, desktop stack, package set, or DAW combination. VST3 itself has standard Linux locations, including the user-level $HOME/.vst3/ directory and system locations under /usr/lib or /usr/local/lib. A correctly built plugin still needs a host that scans the relevant format and a system environment that satisfies whatever the binary expects at runtime. CLAP has become a useful Linux option as host support has expanded, while VST3 remains widely relevant. The broader [URL='https://goldmidi.com/community/threads/linux-plugin-support-stopped-being-a-workaround.75888/']state of native Linux plugin support[/URL] matters here because format availability and host support are separate from whether Nagi can produce a Linux target. Local and container builds also solve different problems. Building locally ties the process to your installed toolchain and operating environment, while Nagi's isolated-container option is meant to make output more reproducible. If Linux is part of a real release, install the finished plugin on a clean target system and load it in the exact host you plan to support rather than treating one successful build as platform validation. [/QUOTE]

Name