FRCTL Audio ships GRN 4.0.0 as a separate GRN4 plug-in, so projects already using GRN 3 continue opening the older version. Existing sessions are not pushed onto the new engine simply because you install the update. For anyone with half-finished mixes, archived cues, or client revisions, that separation is the useful part.
The separate GRN4 plug-in release also carries over the existing serial, trial status, and user presets. You can therefore install GRN4 without treating it as a clean-slate purchase or rebuilding your preset collection by hand. Old project recall and new-version access remain two different jobs.
GRN4 does not replace the GRN 3 instance already saved inside a project. You get the new processor for new inserts while the older processor remains available for sessions that already depend on it.
Keeping GRN 3 installed is therefore part of the safety story. GRN4 sitting beside it does not substitute for a GRN 3 component if you later remove the older plug-in from the system. A project can only recall what the host can still find.
For important sessions, the sensible move is boring but reliable. Leave GRN 3 installed, open a few older projects after adding GRN4, and confirm the original instances load with the expected preset state and automation. If a track matters enough to revisit months later, print a safety render before changing its granular chain and keep it with the project.
This arrangement also means there is no reason to convert every existing insert immediately. A song already sounding right with GRN 3 can stay there, while GRN4 can handle new parts or deliberate replacements. Migration becomes a choice at the track level instead of a forced project-wide event.
GRN4 also introduces a substantially different grain engine, including selection-bound playback, micro-loops, a larger grain pool, per-grain filtering, and new modulation behavior. Reusing an older preset inside GRN4 therefore belongs in the category of deliberate auditioning, not silent replacement. The safer expectation is access to familiar settings while the older instance remains responsible for reproducing the session that originally used it.
Trial status carrying over matters for the same reason. GRN4 is presented as the next version of the product rather than a separate entitlement that requires another purchase, while remaining a separate plug-in at the host level. Existing owners receive the update without losing the older processor their sessions call.
A practical migration pass can stay simple. Duplicate the track, leave the GRN 3 insert untouched on one copy, load GRN4 on the other, then compare the result at similar output levels before committing. If the new engine changes a texture you actually preferred, the original version is still sitting there.
Projects built around the GRN 3 MIDI Audio Unit deserve a little more care than a basic audio-effect insert. Keep GRN 3 available until you have intentionally rebuilt and checked any MIDI routing you want to move into GRN4. A working old route is more valuable than a tidy plug-in folder.
The cleanest long-term setup is to treat GRN 3 as a compatibility dependency for old work and GRN4 as the active version for new work. Remove GRN 3 only after the projects you care about have been rendered, archived with sufficient safeguards, or deliberately migrated and checked.
The separate GRN4 plug-in release also carries over the existing serial, trial status, and user presets. You can therefore install GRN4 without treating it as a clean-slate purchase or rebuilding your preset collection by hand. Old project recall and new-version access remain two different jobs.
GRN4 does not replace the GRN 3 instance already saved inside a project. You get the new processor for new inserts while the older processor remains available for sessions that already depend on it.
Separate plug-in identity protects old session recall
A DAW normally recalls the plug-in instance saved with the project rather than choosing a newer product because its name or controls look related. The broader host and plug-in architecture model treats the host and audio processor as distinct components connected through a defined interface. FRCTL's decision to ship GRN4 separately fits that basic architecture cleanly.Keeping GRN 3 installed is therefore part of the safety story. GRN4 sitting beside it does not substitute for a GRN 3 component if you later remove the older plug-in from the system. A project can only recall what the host can still find.
For important sessions, the sensible move is boring but reliable. Leave GRN 3 installed, open a few older projects after adding GRN4, and confirm the original instances load with the expected preset state and automation. If a track matters enough to revisit months later, print a safety render before changing its granular chain and keep it with the project.
This arrangement also means there is no reason to convert every existing insert immediately. A song already sounding right with GRN 3 can stay there, while GRN4 can handle new parts or deliberate replacements. Migration becomes a choice at the track level instead of a forced project-wide event.
Presets and licenses move differently from plug-in instances
FRCTL says the serial, trial, and user presets carry over to GRN4. Preset continuity is useful because it removes much of the housekeeping normally attached to a major version change, but it should not be confused with automatic session conversion. Your old project still asks for GRN 3 even when the same preset collection is available to GRN4.GRN4 also introduces a substantially different grain engine, including selection-bound playback, micro-loops, a larger grain pool, per-grain filtering, and new modulation behavior. Reusing an older preset inside GRN4 therefore belongs in the category of deliberate auditioning, not silent replacement. The safer expectation is access to familiar settings while the older instance remains responsible for reproducing the session that originally used it.
Trial status carrying over matters for the same reason. GRN4 is presented as the next version of the product rather than a separate entitlement that requires another purchase, while remaining a separate plug-in at the host level. Existing owners receive the update without losing the older processor their sessions call.
A practical migration pass can stay simple. Duplicate the track, leave the GRN 3 insert untouched on one copy, load GRN4 on the other, then compare the result at similar output levels before committing. If the new engine changes a texture you actually preferred, the original version is still sitting there.
macOS MIDI routing changes only on new GRN4 work
GRN 3.2.0 used a separate GRN MIDI Audio Unit on macOS for hosts that needed note input. GRN4 changes that arrangement by using a single Audio Unit that can also accept MIDI, while the ordinary VST3 and CLAP versions remain available alongside AU support. New GRN4 sessions can therefore use the consolidated AU design without rewriting the plug-in identity stored in older projects.Projects built around the GRN 3 MIDI Audio Unit deserve a little more care than a basic audio-effect insert. Keep GRN 3 available until you have intentionally rebuilt and checked any MIDI routing you want to move into GRN4. A working old route is more valuable than a tidy plug-in folder.
The cleanest long-term setup is to treat GRN 3 as a compatibility dependency for old work and GRN4 as the active version for new work. Remove GRN 3 only after the projects you care about have been rendered, archived with sufficient safeguards, or deliberately migrated and checked.
