Bug in Sound Forge 11 - any ideas for workaround?

Hi all,

A user of my plugins has let me know that my plugins no longer work properly in Sound Forge 11 (they worked in Sound Forge 9). When rendering the plugins, they switch to the default plugin settings. Here's some information on the bug from a different manufacturer:

1) Parameter reset when rendering
For rendering, Soundforge does not use the Plugin instance that you can see. It opens the plugin a second time without showing it. Normally all parameters in that second instance should be set to the same values as in the visible one. It seems that this does not happen when the plugin does not make use of the standard VST default presets. We do not use these VST presets, as we have our own internal preset management.

I don't make use of the internal presets, either.

Quite frankly, this seems like a Sound Forge bug, but it seems like Sony has no inclination to fix the bug, even when told about it. So I figured I'd ask here and see if anyone has suggestions on how to work around this, in a way that won't crash stuff for hosts that don't have this "feature."


Sean Costello

Certainly looks like a Sound Forge bug to me!

If a host wants a duplicate of an instance of a plugin, it needs to copy the state from the old one. Can't really see why they wouldn't do that..

I have a similar bug I'm trying to track down, namely that if I:

Open my plugin, change from default settings, then press OK (applying the effect and closing the GUI), then reopen the plugin, all settings are back to default (!)

Other plugins in SoundForge do not exhibit this behaviour.

Ideas ?

The JuceDemoPlugin exhibits the same exact behaviour, i.e. it is possible to apply the settings, however when opening it up again, the default values are active.

Is it ever calling the load/save state methods? Perhaps it calls them is a silly order, perhaps restoring the state too early?

Yes, it does. In a silly order :) When the plugin is instantiated, SF first calls save (on an obviously "default" object), then it calls load with the state from the save call (!)... Hrmf. It appears to be a confirmed problem with SF (http://www.sonycreativesoftware.com/forums/showmessage.asp?messageid=777922)

Ok... Not sure what we could do about that. Is there an obvious workaround we could add?

No, I don't think so really... this should be fixed by Sony.

Just a follow up about this particular bug, which has hit us even in late 2017:

What we could see is that Sound Forge 11 did NOT call getStateInformation() / setStateInformation() to copy the state from the “visible” plug-in that it uses to preview the outcome, to the “headless” one that it uses to apply the final processing to the track.

On the bright side, the same plug-in used in Sound Forge 12 behaved as expected, so we suggested to our user to upgrade to SF 12 without investigating the issue further (i.e. I don’t know whether SF 12 still uses two instances but correctly copies the state from one to the other, or if it uses a single instance now)