I am very angry about the unreliability of saving SVP projects to external files.
When copying new plugins to new tracks, the plugin in the new instance asks how to save the project and in the third case the project did not save after 8 hours. The file is not found in recovery either. It was overwritten by the first instance of the plugin.
That is,
Instance 1 Verse is OK,
Pre-Chorus is OK,
and Chorus is completely filled with the content of Verse 1, even though it has its own Chorus.SVP.
I just lost 8 hours of unique inspiration and I don’t have a single backup of the plugin settings.
This is not possible!
1 Like
I have found an issue that consistently corrupts the saved state of SynthV 2.2.2 Core when an instance is created by duplicating an existing one. I’m not sure whether this also affects the Pro version.
Here are the steps to reproduce the issue:
- In Bitwig Studio 6, create a SynthV Core instance and configure it.
- Duplicate the plugin by dragging or copying the existing instance to another track.
- Modify the duplicated instance so that it contains different data from the original.
- Save the project, close Bitwig, and reopen the project.
Expected behavior:
The duplicated instance should retain its own independent state.
Actual behavior:
After reopening the project, the duplicated instance reverts to the state of the original (parent) instance it was copied from, causing all changes made to the duplicate to be lost.
This behavior is highly problematic because it can silently overwrite work without any warning.
As a workaround, I always insert a brand-new SynthV Core instance directly from the plugin browser instead of duplicating an existing one. This appears to avoid the problem, possibly because the new instance receives a unique internal identifier.
Thank you for looking into this issue.
1 Like
sounds like the SV uses a singleton approach to keeping the instances consistent across thread derived from the primary instantiation. so opening a separate instance (as you’ve demonstrated) would be correct when you want wholly independent instances.
it would be nice if the other spawned threads could have a dirty flag setup so changes in any derived instances would signal a need to save the work - i think the challenge will be how to support the context (content) across them as there are likely internal locks etc…
mayb the short term, SV simply prevents duplication of instances…
While I can’t speak to your specific issues I can confirm I’ve experienced SV crashes and total loss instances. Lesson learned quickly. Besides having a TimeMachine backup running (Mac) I also got very fastidious about making version and time stamped regular (hourly if need) backup .SVP copies of works as I go along. (In addition to doing the same for my DAW files). This at least reduces to “loss” when the crashes strike, to just the most current work after the last save.
I noticed that when I do the mentioned instance copy, a dialog window pops up asking me to where to save the file project, which is the correct behavior. However, the problem later overrides this attempt.
Apparently it’s a bug. I like that the plugin author is thinking about this scenario, but it’s not finished yet.
Now I also save the content externally and then switch to saving to the host. Invested time to the often save is still less price for possible lost hours of work.
Thank you all for the responses.
Nearly the same thing occurred with me yesterday running 2.3.0 (Though it probably would’ve happened with earlier versions as welI’). I lost 7 hours of painstaking word stretching tweaking edits over multiple tracks to make more human sounding. Then it just seized up, splashed a (rendering) message indefinitely on my screen until I was forced to CNTL-ALT-DEL to sign out of the session. The crash overwrote all existing .svp data on that project. 7 hours down the drain.