SURGE VST loosing settings

Last week I háve update for the latest versiin of GP3 and alsó for latest versiin of Surge synth vst. I háve štarte to háve problém with loosing of setting of rackspaces and mkstly with surge synth. When I am selecting a song it is loading the rackspaces. The main configuration is the sám as saved but the plugins háve otjer sounds selected as I háve saved. I háve nőt tested áll the rackspaces but I háve a feeling that this issue is mostly present in Surge vst. Háve you experience a similar problém?

Have you reported the issue on the Surge forums? We would be astonished if this was a GP issue as users would be seeing this with every plugin.

I really like Surge and use it in several rackspaces. I have no problem with it in GP3 and GP4.
The vst Windows version used is 1.9.0.9106918.

I also don’t have any issues with Surge.
Perhaps this is again another try to store plugin settings in variations? Sounds almost like it…

Did you update to a major release of Surge?

I have updated from 1.6something to 1.9.0. Everithing worked fine, but after closing down the computer on the next day I have had this problem than corrected everithing, saved the gig file, next day I have had the same issue…interestingly not with all of the songs but mostly with the newly edited created or edited songs.
Can it be connected with my editing method? Last songs I have created that I have opened a previous rackspace similar to the new rackspace I need , duplicated it than edited the new rackspace to my needs.
Do I have to save each rackspace separately or it is enough to save the gig?
Previously I have saved only the gig files. At the moment I have approx 50 songs created and approximately 60 rackspaces.

You have to take care - or better the developer of VST - that the so called state is compatible from older versions to new version.
As GP does not store a preset name to reference to patch used in the plugin but the so called state it is important that the plugin developer takes care of the state.
This ould explain why ypu do not get the same patched.

When ypu build a new gig with the new surge and save it and reopen it, is the correct sound restored ?

Interestingly when I saved the gig with Save as lrgacy formát, after reipening the gig it was OK. I háve tried to savé the gig with štandard Save, but never worked after reipening. Can anyone explain IT, why it does nőt Work with standard way?

You’ll have to ask the Surge people.

Gig Performer requests the state of the plugin and saves that information as part of the gig file.
When the gigfile is reloaded, that saved state is sent back to the plugin which such restore the settings of the plugin to exactly what it was before.

This is basic behavior that every plugin must implement. If that is not happening, then the plugin (not Gig Performer) has a bug!

I just tried, it is saved correctly and reopened correctly.

Can you try this gig?
Surge.gig (111.7 KB)

I will try it during the weekend. I have reported this issue to Surge team. They have not recognized any similar issue but in their opinion the possible reason is that I have used the VST2 from the 1.6 version and now I am using VST3 (only vst3 is installed).
Do I have to make a new gig file with new rackspaces or there is easier way?

I found on another forum some similar issue with Kontakt, in that case the problem was the predictive loading. I have tryed to switch off the predictive loading, and now it seems that there is no issue with loosing selected presets. I am using surge near in each rackspaces and sometimes 3x in one rackspace.
The problem is that without predictive loading there is higher CPU load what i want to avoid.
Any idea how to eliminate this problem with predictive loading?

Thank you in advance!

Frank

Yes, get them to fix the plugin :stuck_out_tongue_winking_eye:

1 Like

But in my opinion the bug is in the GP in the predictive loading function. Or ám I wrong?

Yes you are wrong

2 Likes

Based on this discussion I am not sure:

I don’t think that you can actually relate to the thread with this “Kontakt” issue…

  1. The discussion was about using two diffrent plugin versions (V5 and V6) at the same time

  2. Kontakt is a sample based plugin which makes the sounds and libraries huge, compared to a sound created with The Surge - this is also the reason why “Predictive loading” won’t offer you a significant advantage and why you could disable it without running into issues. The “job” of Predictive loading is to load a big amount of data (= mostly plugins with sample libraries) before you actually need them - it won’t save you CPU cycles (at least as far as i know).

And: If there was a real problem with GP4 losing presets, it would be systematic, means it would pop up every time and a lot of users would complain about it.
There were actually some cases when plugins showed issues if they ran in the environment of Gig Performer, but didn’t in “normal DAWs”.
This has always been caused by the fact that the developers of the plugins didn’t properly implement all the specifications that should be mandatory for a plugin to run in “every” hosting software.
In short: There are certain rules for plugins, but not all of the plugins follow them - but this is what GP is expecting.

1 Like

If you’re seeing significantly higher CPU levels when you have Surge (or indeed any plugins) in rackspaces that are not “Active”, then one or more of the plugins in those other rackspaces is poorly implemented. When you switch away from a rackspace, all plugins that other rackspace have their audio processing disabled. However, if they are still using a lot of CPU cycles, that means that they have lots of other threads running all the time as opposed to just when (a) audio processing is needed or (b) the plugin GUI editor is open.

Here’s a screen shot showing this where I have the Arturia CS80 in one rackspace and nothing in another. When I switch away from the rackspace with the CS80, the overall CPU utilization decreases.
(NB it takes 3-5 seconds before the activity monitor updates and so I deleted several seconds of video where nothing was actually happening, just to save time)

CPUCycles

Further, a properly implemented plugin will reduce CPU cycles even when the rackspace is active if no sound is being produced.
you

Here’s a quick video I made with the same rackspace but now I’m triggering the CS80 – you’ll see the audio processing CPU cycles increase while there is sound and then decrease again when the sound goes away.

https://youtu.be/qUeZ24JOeVc