A mechanism to automatically recall plugin states when switching between songs

Does anyone know if VST Live provides a mechanism to automatically recall plugin states when switching between songs, or between different parts of the same song?

Let me explain: I’m a keyboard player and I use several VST synths (around 5–6) plus a rompler with its sample libraries. My live setup basically stays the same across songs, so it doesn’t make much sense to reload the same plugins every time, wasting system resources.

The issue is this: starting from a fixed set of plugins, I need a way to recall the specific state (presets, parameters, etc.) of each plugin for every song or even for each part of a song, exactly as prepared in the studio.

In other words, I would like to select a song and have all my plugins (synths and rompler) automatically configured with the correct sounds for that specific track. This is essential in a live performance context.

Loading multiple instances of the same plugin just to handle different sounds doesn’t seem practical to me. With many songs or parts, this approach could easily saturate system resources right from the start.

Yes, if your layers are not global, they are tied only to the song, just like SONG GROUP in the effects mixer.

When you switch to another part in the same song, you can change the layer and it will be remembered, just like for another song.

In case your setup stays across songs use global parts/layer instead. So you only need to set it up once. Thats also practicable if only one or few songs have a different setup. In that case setup the layers on song level and mute the globals for that specific songs.

Each song is self contained i.e when you load a new song the previous one is discarded along with its plugins, albeit after the delay set in preferences and the release of notes. So resources are released and then reconfigured for the new song rather than being cumulative. It can be slightly confusing that preload parts appears to load every part in every song but that’s just so that plugins are initialised ready for use - they’re not actually all held in memory once this is done.

I guess you’ve already worked out that Layers can have their own plugins or control external modules like your rompler. The resources for a layer controlling external modules are quite small and can be used to select programs or send CC and automation can be applied.

You could have Global Layers controlled by automation but there is a problem if they are VST3 - not all of them will respond to program changes.

When used in a layer all the plugin settings that are exposed by it, including the selected sound, are saved in the layer. This occurs just once when the layer is first loaded so may cause you a problem if the layer is global.

If you have multiple parts in the song then you can have shared layers (i.e. the plugin is only loaded once but shared between the parts) which is probably the most efficient. You can exert control over the shared layers at each part (volume, CC, etc) but if you want to change the loaded sound (program) it’s the same problem as global layers. There are also settings in preferences as to whether shared layer volume and midi controls are common across the song which you may want to investigate.

1 Like

Thank you for the clear explanation. It’s not exactly what I was hoping for, but it seems like an interesting approach. I’ll try working with it a bit to see if and how it can work for my setup.

Hey @Gianluca_132,

There are things you can do depending on what VST you use. If VSTs that you use support Midi Program Change.

I’ll give you some examples of what I do:

For sample based VSTs (Piano, Rhodes etc…) I create them in Global I use Virtual Midi Port as input. For the songs I need them, again I create a layer in song, midi input as keyboard and output as Virtual Midi. Only on the first part of the song I send program change the correct patch for that particular song.

You can extend this same setup to have an automation track in the song to change parameters throughout the song targeting the virtual midi port if you need to adjust cc’s.

Otherwise, for non-sample based, I just create a layer per song and share the layer on all parts. As non-loaded VSTs do not consume cpu, I don’t mind (usually they don’t consume much ram) but sample based VSTs are loaded to ram with the project and consume RAM loaded or not.

Automation track works for shared layers also.

Hope this helps…

1 Like

@CliveJ you beat me to it :slight_smile:

Only thing I will add is you are right that the resources are released, but only CPU wise, RAM wise they are not released, since that is where the preloaded VSTs keep their loaded state.

So you don’t see much ram usage on non sample base VSTs since their ram usage is neglectable, but Sample based consume lot, if more than one instance is loaded throughout the project.

2 Likes

That’s a good reason to steer clear of Kontakt and Halion :joy:

I’m very familiar with the problem. Unfortunately, I use Kontakt 8 with various ethnic sound libraries that change at least from song to song, and sometimes even between different parts of the same song, and it’s a real nightmare. I can’t load a project with all these samples preloaded without exceeding my PC’s limits. So far, the only solution has been to load separate projects for each song, with the inevitable waiting time between songs and that subtle fear that something might go wrong while it’s loading

Too late…:roll_eyes:

I don’t use contact at Kontakt but what I would suggest is, again put Kontakt in global, an if it can be arranged like halion (multi-timbral), do your routings in layers based on midi channels. You can send omni from keyboard and filter to only send to virtual.

You just then need to send program changes, to load state based on per channel per song.

This can be arranged if you plan it and if Kontakt works like Halion…

Well you don’t need 10gig piano sample to fill limited RAM. 10 songs each using 1 gig (ex. arturia piano ) again equals to 10gig. :slight_smile:

They’re supposed to stream from disk - at least the good ones do :grinning_face:

What is your PC spec?

Thanks everyone for the helpful replies.
There are a lot of good ideas to experiment with. Maybe over the weekend I’ll manage to spend some time on all of this and see if I can figure something out. What it seems to me, though, is that there’s basically no real solution that gives you the best of both worlds. What would be needed is the ability to take a snapshot of a plugin exactly as it is, but that’s probably neither simple nor trivial.