OA Labs officially supports OA-Phosphor-1 on macOS and Windows, with VST3 on both platforms and Audio Units available on Mac. Linux exists too, but the developer still describes that build as untested rather than part of the normal supported lineup.
Plugin compatibility is easy to flatten into a row of operating-system logos. In practice, your DAW has to understand the format you install, your operating system has to run the build, and an experimental build deserves a different level of trust from one the developer actually supports.
For the OA-Phosphor-1 v1.2 synth release, the safest reading is narrower than “Windows, macOS, and Linux” suggests. Mac and Windows are the ordinary supported choices, while Linux is presently closer to public testing.
Mac users have two normal choices because OA Labs supplies both VST3 and AU. Logic Pro and GarageBand users should expect the Audio Unit version, while DAWs such as Live can handle VST3 as well, so installing the format your actual host uses is more useful than treating every available build as mandatory.
Format choice also matters when sessions move between operating systems. An Audio Unit instance belongs to the Apple environment, so a project built around the AU version cannot simply expect Windows to load the same plug-in instance even though a Windows VST3 build of OA-Phosphor-1 exists.
Audio software developers have been dealing with this fragmentation for years. Research on maintaining cross-platform audio plugins in an academic paper describes the repeated compiling, testing, and packaging burden created by supporting multiple operating systems and plug-in formats, which is why “the synth exists on both computers” is not the same promise as “every session moves cleanly between them.”
For collaboration, VST3 is therefore the more sensible common denominator when both sides use DAWs that support it. You still need compatible host versions and the same plug-in state, but you avoid deliberately building the session around a Mac-only format.
Installing the VST3 file will not make it appear as a normal Pro Tools instrument. AAX is the native plug-in format Pro Tools expects, so a successful VST3 installation on the same Windows or Mac computer does not remove the format mismatch.
A wrapper or secondary plug-in host may provide a workaround in some setups, but it changes the session dependency chain. Anyone reopening the project may now need OA-Phosphor-1, the wrapper, compatible versions of both, and the same routing arrangement, which is a poor trade if predictable session recall matters.
The absence of AAX is therefore more than an installer inconvenience. Producers who move projects between Pro Tools and another DAW should treat rendered audio, stems, or printed synth parts as safer interchange options until OA Labs ships native AAX support.
Current testing is aimed at basic host scanning, interface rendering, audio operation, and differences between Linux setups. Distribution version, graphics system, audio stack, and the system libraries available on a machine can all matter when a build has not yet accumulated the testing coverage of its Mac and Windows siblings.
Early user reports can be encouraging without turning an experimental build into a guarantee. A successful load on one Linux distribution and DAW tells you that combination works for somebody, not that every distribution, Wayland or X11 setup, PipeWire or JACK configuration, and VST3 host has been cleared.
If you depend on OA-Phosphor-1 for sessions that must reopen reliably, Mac or Windows is the lower-risk choice today. Linux users can absolutely test the native build, but keeping rendered versions of important parts is sensible until the developer moves Linux from an openly untested build into the regular supported platform list.
Plugin compatibility is easy to flatten into a row of operating-system logos. In practice, your DAW has to understand the format you install, your operating system has to run the build, and an experimental build deserves a different level of trust from one the developer actually supports.
For the OA-Phosphor-1 v1.2 synth release, the safest reading is narrower than “Windows, macOS, and Linux” suggests. Mac and Windows are the ordinary supported choices, while Linux is presently closer to public testing.
VST3 is the common route on Mac and Windows
Windows users get VST3, so the first compatibility check is whether your DAW can host a 64-bit VST3 instrument. Current versions of Ableton Live, Cubase, Studio One, Reaper, Bitwig Studio, and many other mainstream hosts support VST3, making this the broadest route into OA-Phosphor-1 on Windows.Mac users have two normal choices because OA Labs supplies both VST3 and AU. Logic Pro and GarageBand users should expect the Audio Unit version, while DAWs such as Live can handle VST3 as well, so installing the format your actual host uses is more useful than treating every available build as mandatory.
Format choice also matters when sessions move between operating systems. An Audio Unit instance belongs to the Apple environment, so a project built around the AU version cannot simply expect Windows to load the same plug-in instance even though a Windows VST3 build of OA-Phosphor-1 exists.
Audio software developers have been dealing with this fragmentation for years. Research on maintaining cross-platform audio plugins in an academic paper describes the repeated compiling, testing, and packaging burden created by supporting multiple operating systems and plug-in formats, which is why “the synth exists on both computers” is not the same promise as “every session moves cleanly between them.”
For collaboration, VST3 is therefore the more sensible common denominator when both sides use DAWs that support it. You still need compatible host versions and the same plug-in state, but you avoid deliberately building the session around a Mac-only format.
Pro Tools is still outside the native support list
Pro Tools users hit a simpler limit. OA-Phosphor-1 does not currently ship as AAX, and OA Labs explicitly says Pro Tools support is not available yet, with AAX presented as something users can register interest in rather than something already delivered.Installing the VST3 file will not make it appear as a normal Pro Tools instrument. AAX is the native plug-in format Pro Tools expects, so a successful VST3 installation on the same Windows or Mac computer does not remove the format mismatch.
A wrapper or secondary plug-in host may provide a workaround in some setups, but it changes the session dependency chain. Anyone reopening the project may now need OA-Phosphor-1, the wrapper, compatible versions of both, and the same routing arrangement, which is a poor trade if predictable session recall matters.
The absence of AAX is therefore more than an installer inconvenience. Producers who move projects between Pro Tools and another DAW should treat rendered audio, stems, or printed synth parts as safer interchange options until OA Labs ships native AAX support.
Linux works differently because the build is still being tested
A Linux build is available, but OA Labs is actively asking users to test it rather than presenting Linux beside Mac and Windows as equally supported. The developer has described it as VST3 and standalone only, with no CLAP or LV2 version at present.Current testing is aimed at basic host scanning, interface rendering, audio operation, and differences between Linux setups. Distribution version, graphics system, audio stack, and the system libraries available on a machine can all matter when a build has not yet accumulated the testing coverage of its Mac and Windows siblings.
Early user reports can be encouraging without turning an experimental build into a guarantee. A successful load on one Linux distribution and DAW tells you that combination works for somebody, not that every distribution, Wayland or X11 setup, PipeWire or JACK configuration, and VST3 host has been cleared.
If you depend on OA-Phosphor-1 for sessions that must reopen reliably, Mac or Windows is the lower-risk choice today. Linux users can absolutely test the native build, but keeping rendered versions of important parts is sensible until the developer moves Linux from an openly untested build into the regular supported platform list.
