SynthV instance within Cubase deleted tracks after crash (across projects and backups > unrecoverable)


I was working on a large project within Cubase where 2 instances of SynthV were running.

Because the project is large (130 Cubase tracks) and I can’t turn off real-time processing in SynthV my PC is quickly hitting the limit as soon as I make changes to the vocals. Usually a crash was no problem in older versions, but this time it happened twice that parts of the SynthV project (3 voices per vst instance) got deleted upon reopening the crashed Cubase session.

Now I had a really intense freeze where everything in that SynthV instance got deleted and it doesn’t matter if I open an older backup of it: It’s completely gone, as if it never existed across backups even before the crash.

I just lost so many hours of work because of this and it would be nice if there was a workaround or any way I can prevent this from happening.

(I’m using Win10, Cubase 12 Pro latest version, SynthV latest version)

1 Like

If you need to save on memory and CPU you can render the SynthV output as a wav file and import the wav instead of using the VST version.

You can also bounce your instrumental to a wav and drag that into a standalone instance of SynthV, or drag that instrumental into a new DAW project with the SynthV VST to reduce PC load. There’s really no need to have everything running at once if your PC can’t handle it.


That’s sadly not possible, I write mainly orchestral music and I have to know how it sounds in the mix to make adjustments on the fly. What I need is a function that disables realtime rendering and adds a button instead that says “render now”. :confounded:

It’s really just the real time rendering that causes headaches… there’s hundreds of plugins running in the background and the unnecessary realtime render just grinds everything to a halt the longer the project is, causing system instabilities. It causes many of the plugins unrelated to SynthV to just flat out crash and take the DAW with them.

1 Like

It is not uncommon in music production to bounce CPU-intensive tracks as you work, but if that’s truly impossible for you then try changing the “Render Mode” setting to “Prefer Speed” (in the “Voice” panel), and try working with different numbers of background threads (in the “Settings” panel).

Also keep in mind that having Instant Mode enabled is more CPU-intensive.

1 Like

I know all this, I wasn’t looking for help with performance! (I just added the circumstances how the issue occured in case it matters for the solution or bug fix)

1 Like

I understand this is a bug report.

And claire has already made suggestions, but you’re more interested in not crashing than performance.

But I’ll make a suggestion anyway. :wink: Feel free to ignore it.

Similar to what claire suggested, you can run SynthV in stand-alone mode along with your DAW, and export the .wav files from SynthesizerV into your DAW.

If you want to change the vocal, toggle from the DAW back to SynthesizerV, edit the vocal, and re-render. When you toggle back to your DAW, it should see the .wav file was modified and automatically re-load it.

Since your DAW only sees the .wav files, if for some reason SynthesizerV crashes, your DAW is still happy as a clam.

Plus, the backup files for SynthesizerV are independent of your DAW.

And because you can have multiple tracks in SynthesizerV, it’s less resources for your machine because you only have to have one instace of SynthesizerV running.

Finally, you can split the vocal and aspiration into separate .wav tracks, which is useful because you can run the aspiration through different effects than the vocal, keeping the clarity of the vocal while still being able to use lots of reverb. It’s similar to how some effects put a de-esser before the reverb effects to minimize transients “popping” - only this way, you can keep the crispness of the vocal.

As cool as it is to have SynthesizerV running as a VSTi in your DAW, I’m not sure I’d recommend going that route.


I’m a semi-professional composer, I work in audio every day, I know my own workflow better than anyone else. Maybe I didn’t express my point of concern correctly.

But I thought I made that clear:

I do not care about crashes at the moment. They happen, I can deal with it. I’m used to them at the end of a project, because it’s an incredible amount of processing going on, even if I freeze the majority of tracks.

I wrote this because SynthV lost data on crash across multiple backups, even before the crash happened. I wrote this thread because a crash should not cause already saved data to be lost.

Lost/unrecoverable data and the fact that my numerous backups didn’t prevent the data loss is a major issue.

Usually VSTs save their data within a project file, but this clearly didn’t happen here.

By accident I found out that I accidentally UNchecked the option to save data within a project file.

This still doesn’t explain why the externally saved data got deleted.

1 Like

I realize that your main issue is the loss of progress. Nobody is claiming that Dreamtonics shouldn’t investigate and fix that. However, you quite clearly also expressed the need for a workaround.

Usually when people express the need for a workaround they aren’t so opposed to being provided with workarounds, and it seems to me like stopping the software from crashing in the first place would fall under “any way I can prevent this from happening.”

Apologies if I misunderstood.

1 Like

If the data wasn’t saved inside host / within the project file you have a “linked” svp file. Backups of the Cubase cpr files don’t matter in this case. Do you have multiple backups of the svp or just the cpr file?

1 Like

You can try going to the recovery folder to find the project recovery files, but my personal advice is still to save them regularly.

  • Windows:%USERPROFILE%\Documents\Dreamtonics\Synthesizer V Studio\recovery

  • macOS:/Library/Application Support/Dreamtonics/Synthesizer V Studio/recovery


I didn’t have a backup of the svp, because I didn’t know they existed independently from data in the cpr.
The svp’s for that project are empty though which is why it’s unrecoverable.

The svp for that project is empty, which is the problem! :confounded:

Oh no, sorry. I meant a workaround for not losing files/saving it internally (I was in the heat of the moment when I wrote that post and admitettly pretty angry that this data loss even happened). Sorry if my other posts came across as rude or anything I was just super stressed out that day!

1 Like

Thank you to the community for helping us without saying “please” or “thank you” :slight_smile:

I say THANK YOU and Merry Christmas to all :slight_smile:

1 Like