I have a conceptual question about VST development and I’d appreciate some insight from people with more experience in this area.
I don’t have deep knowledge about writing VSTs yet, so my question is mainly about whether this idea is technically possible and how complex it would be.
The idea
I’m thinking about creating a VST that simply hosts another VST instrument inside it (for example Kontakt).
The wrapper plugin itself would do almost nothing else besides hosting that instrument.
The main motivation is related to plugin state saving:
As far as I understand it, when a DAW saves a project (or performs autosave), it requests the plugin state from each plugin instance.
For large instruments like Kontakt, this state can be very large, even if nothing has changed.
What I want to achieve
The idea is:
The wrapper VST hosts another VST instrument (e.g. Kontakt)
When the DAW asks for the plugin state:
The wrapper plugin does not forward the full hosted plugin state
Instead, it returns a very small or minimal state, basically saying “nothing changed”
The actual full state of the hosted plugin is only saved explicitly, for example:
via a “Save Preset” function inside the wrapper
or some other manual save action
As long as the hosted plugin hasn’t changed, regular DAW project saves or autosaves would only store the small wrapper state, not the full hosted plugin state again and again
When reopening the project, the wrapper would know:
which plugin it hosts
where its internally stored state is
and then restore the hosted plugin from that stored state
The core question
Is it technically possible for a VST plugin to:
Host another VST instrument
Intercept or replace the state that is reported to the DAW
Decide not to serialize the hosted plugin’s full state on every DAW save
And instead manage that state internally / manually?
Or are there limitations in the VST specification or typical DAW behavior that would make this impossible or unreliable?
Complexity / caveats
I’m also very interested in:
whether this would break expectations of the VST host
whether DAWs would even accept such behavior
and roughly how complex this would be to implement (high-level only)
I’m not looking for a full solution — just trying to understand if this idea is fundamentally viable or a dead end.
1.) yes, with juce it is fairly easy to create a plugin that hosts another plugin
2.) yes and no. You can forward a different state to the host. But it would be rather pointless.
The state is a black box to you. The hosted plugin could write binary data, even encrypted if it choses to.
3.) This is not possible. You could return an empty state, but that would mean, when the session is restored, the state is gone and the hosted plugin starts with a blank instance.
4.) This is not advicable. The problem with plugins for all this shenanigans is, they can be closed without warning. So leave it to the host to decide, when it is appropriate to save the state or not.
Thanks a lot for taking the time to write such a detailed reply — I really appreciate it.
Just to clarify the practical use case behind this idea:
I’m working with a fixed project template containing a large number of Kontakt instances (often 100+).
During actual project work, Kontakt is never modified at all — any changes are done only at the template level.
Every new song is always created from the same static Kontakt configuration.
In this setup, state serialization becomes a real workflow issue:
A single project save can easily reach 200–300 MB
With autosave enabled, the DAW regularly freezes for 10–15 seconds
Background saves and backups can quickly grow into multiple gigabytes for an otherwise very small project
Because Kontakt is never changed while working, the hosted plugin does not need to be re-serialized at all during normal project saves.
The idea behind the wrapper plugin is therefore very controlled:
Serialize the hosted plugin’s full state once
Store that state as a separate file on disk
Report only a small, stable wrapper state to the DAW during normal saves
Restore the hosted plugin from that stored state on project load
If I ever do need to modify the hosted plugin, I would explicitly save its state via the wrapper plugin.
As long as this is done intentionally, the project can always be reopened and the last saved state will be restored correctly.
I understand that this goes against the usual expectation that plugins are fully self-contained, and I’m not suggesting this as a general-purpose solution.
I’m mainly trying to understand whether this approach is technically feasible at all, or fundamentally incompatible with how hosts expect plugins to behave.
Thanks again for your insights — they’re very helpful.
You can absolutely wrap the plugin and intercept the state, for example just using some hash as a key to your own persistent storage. Tricky thing would be the parameter mapping for automation, as you can’t change the set of parameters your wrapper plugin reports dynamically.
If it’s only supposed to work with a specific Kontakt version, you can manually replicate the parameters though. Or if you don’t need automation or controller mapping at all, you can probably just skip that altogether.
