REAPER JSFX · Compatibility
JSFX outside REAPER? ReaJS and ysfx explained
JSFX are source-code effects built for REAPER's own effect runtime, but REAPER is not the only software capable of loading them. Two routes are worth knowing: Cockos' ReaJS in the Windows ReaPlugs bundle, and the independent ysfx host for VST3 or Audio Unit workflows. Neither route turns every JSFX into a conventional plug-in without caveats.
- Published
- Reading time
- 6 minutes
1. REAPER is the reference environment
A JSFX is not a VST or Audio Unit binary. Its source is compiled and run by a JSFX host, and REAPER provides the original runtime, effect browser, automation integration, resource paths, and graphics behaviour against which most scripts are developed.
For Triggerpointed effects, this is the dependable route. The current installers place the effects for use in REAPER, and our published checks and listening examples are made there. If a session must open predictably on another machine, stay with that baseline.
2. ReaJS is Cockos' Windows route
Cockos includes ReaJS in the free ReaPlugs VST FX Suite. ReaJS can load and edit JSFX inside another compatible Windows VST host, with audio, MIDI, multichannel I/O, graphics, and plug-in delay compensation support described by Cockos.
The important limit is age and format. The current ReaPlugs download on the official page is version 2.36 from January 2016 and is offered for 32-bit and 64-bit Windows. A modern host that no longer accepts that VST generation may not load it at all.
3. ysfx provides experimental VST3 and AU hosting
ysfx is an independent open-source JSFX compiler, runtime, and plug-in host. Its upstream project offers development builds for Windows and Linux VST3, plus Universal macOS Audio Unit and VST3 builds. It can initially discover effects in REAPER's user folders and can also use custom Effects and Data directories.
Those downloads are explicitly development builds, and the macOS builds are self-signed. Installation, host scanning, Gatekeeper handling, resource lookup, and long-term project recall therefore need more care than with a finished, notarized commercial plug-in.
4. Test the effect, not only the wrapper window
A wrapper opening successfully is only the first check. Compare parameter ranges, channel routing, MIDI input, automation write and recall, presets, graphical controls, and every external data file the effect expects. Save, close, and reopen a copy of the session before trusting it.
Render a short reference through REAPER and the wrapper at the same sample rate, block size, and settings. A null test can reveal exact agreement, but a listening and level check still matters when routing or host behaviour differs. Keep the original JSFX version with the project so a later update cannot silently change the result.
5. The Triggerpointed support boundary
Gritifier and PulseGrit are currently released and checked for REAPER. We do not distribute ReaJS or ysfx, certify particular wrapper builds, or promise that every control and saved session will behave identically through them.
That does not make wrapper use a bad idea. It makes it an advanced compatibility path: work on a project copy, keep monitoring levels conservative, print important sounds, and retain the REAPER route until the wrapped session has survived a complete reopen and render test.
Next step
Explore the Triggerpointed JSFX