I know, VST LIVE is more in a beta stadium now, but I just lost the work of several days, when VST Live crashed during saving!
VST Live release 1.0.40
Win 10 Home 64bit
Intel(R) Core™ i7-10750H CPU @ 2.60GHz 2.59 GHz
16,0 GB RAM
The project is our full liveset with 15 songs containing drums, klick and some keys (1 song) as Midi.
Drums, bass and klick exist as additional audiofiles.
The crash occured during saving while alining some audiotracks.
No Crash dump, no backupfile available.
The 2022 FroschGott 002.vlprj file is only 0 bytes now.
All songs were imported from Cubase 12 Pro via VST Live export (with VST Live 1.0.31).
Audiofiles were missing and had to be imported manually (did this with VST live 1.0.40)
This is of course extremely annoying when a working file breaks.
If you have saved your songs as separate song files (you can do this via the Song menu) then you should be able to restore the setlist quickly.
To test the new program versions, I always use separately created test files (copies of files that I also use) to test the functionality. Should a file then break, then it was only a copy.
The last thing we want is things like this to happen. There were no reports of incidences like this at any time during testing and usage whatsoever. So we are very eager to find the cause.
In general, just overwriting existing projects is not advisable as not only the software but also the file system, hard drive etc may fail. That is by no means to say that we put the blame on you. This incident lead to an improvement with the next version to create one (or several) backup files automatically.
We have two questions reg. this issue: a) was transport running (sequencer playing) when this happened? and b) we woukld kindly ask you to check if there are any files in
C:\Users\ (your user name) \Documents\Steinberg\CrashDumps\VST Live…
(any files starting with “VST Live” in that folder) and send it along.
Sorry for the inconvenience. We will do everything possible to prevent that from happening.
Surely however you save the file it is subject to the possibility of hardware failure? Overwriting an existing file should not be an issue but there’s always a case for backing up to a separate location, particularly if the file is hard to reconstruct.
Maybe you could put in an automatic backup similar to the way Cubase does it?
Your right, but I started several attempts (always issues with importing the cubasefiles correctly (tempo- and signature changes) with crashes, but therefore I saved as often as possible and felt save.
Esp. because things get better.
I started with individual songs before and am working this way now.
a. I think this time transport wasn’t running (had that issue before)
b. Yeah, I finally found the crashdump (thought it was in the roaming section).
VST Live Version 1.0.40 2022.8.6 0.3.10.149.dmp (1.3 MB)
Thank you so much. Tried 200 saves today with an w/o transport started, no problems found. Will create a robot emulating ctrl/s user key and apply that to most complex project possible.
But maybe your crashfile will reveal the culprit, again thanks a lot for this. And there will probably be a hotfix for the video issue and that will include auto-backup of the last version, later to be followed by auto-backup of the last 10 or so versions whith the same name.
I bet I’m gonna produce tons of Crashdumps in the future.
Still having lots of trouble with import of tempomapped songs (but that’ll be another topic )
Bluescreen while saving.
No sequencer running. No other programs running.
Vanilla W11 on a high performance machine.
Concerning the post “In general, just overwriting existing projects is not advisable as not only the software but also the file system, hard drive etc may fail.” :
Sorry, please don´t tell nonsense about file systems
or harddisk failures (latter has NOTHING to do with that bug anyway)
Overwriting a file by no means should cause any corruption.
This is normal behaviour and recent file systems are very resilient against software bugs.
Imho. VST Live in it´s current state is a typical case of BANANAWARE.
we are really sorry and we will fix that behaviour as soon as possible. The crash file of @FroschGott-Ralf is very helpful and we currently looking to it. Maybe you can have some crash files, too? Please share them with us.
i´ll do some more testing tomorrow if I find the time and log you the major steps I do on a second machine
to sum up what may be involved ans what NOT
Will forward that as soon as the next crash occurs plus dumps if there are some.
Won´t happen if it ends up in bluescreens, though.
Another thing I found missing (at least until the time signature is based on PART, not on SONG):
Trying to set up a song which starts with just the keyboards and has varying time signatures,
so i tried to have the song be in ¼ for an optical hint to get at least the tempo at the beginning right,
but this won´t work, because the optical beat (well, obviously just a single “1” then shows no pulse.
Acoustic click isn´t an option there
…which is pretty much what I said thereafter. It was an advice. Anything can go wrong so it is better to save multiple projects, which does not say that this is not “normal” to proceed like so at all, as presented here out of context. We therefore add auto backup, and as can be seen in this very unfortunate case, even good resilience against bugs does not help in all cases, and never with hardware failure, which is very rare but known to happen. Peace. Just an advice, user is not to blame.
i was able to reproduce some errors
- When having orphaned MIDI inputs in a project and changing the layer settings,
VST Live might not come up properly if loading the project.
Since I could eliminate the orphaned MIDI Ins,
some hours of working with several saves of Songs and projects were possible without errors.
- Maybe it is worth checking if those MIDI Ins can cause the crash when trying to save or close VST Live?
I found a small bug in the MIDI Monitor (using a quite old XMIDI2, don´t think that´s relevant):
MIDI Monitor Shows incoming MIDI traffic of both MIDI IN 1 and MIDI IN 2, no matter which one I select in the “INPUT” section
just another bluescreen occured:
Saved everything. Closed VST live
To check for rehersal this evening:
- Start VST live, load current project
- Start Task manager, check RAM. Just 7GB, no issue, machine has 32GB on board
- Close VST Live, see RAM decrease … BANG bluescreen
Do you have any crash dumps?
Windows : C:\Users\ (your user name) \Documents\Steinberg\CrashDumps\VST Live
Mac : /Users/your_username/Library/Logs/DiagnosticReports/vstlive
True, MIDI Monitor shows all events on all inputs of the selected ports’ device (but not of other devices). Will check, thanks for hinting.
Hi @FroschGott-Ralf and @mki,
we will release soon a version which will help to backup the project file before saving! That’s an important step to save a project file in the case something will go badly wrong while saving the project. But we need to identify the main problem here. We are still investigating the DMP file from @FroschGott-Ralf. For that we need a project file which results in a crash or (even worse) in a bluescreen. It would be very helpful if you could give us access to such a project file. We just need the file - no media data.
Thank you, Michael.
Got three crashdumps .
Where to send them?
Played around with swapping audio interfaces.
Live showed a popup to chose another. Selecting a connected one worked perfectly.
==> Could not produce any crashes by that kind of changes.
Didn´t try strange things like disconnecting USB or powering down the interface, though.
Strengthens my suspect that my crashes had to do with the orphaned MIDI devices.
Will focus on that by trying with a wireless USB MIDI device when i´ve got time.
please send them to m.spork (at) steinberg.de