Problem Mulab unspecific memory crahes/backup strategies

[tatanka]

Hello Jo,

I have again reached the point where Mulab crashes cause of unspecific memory problems. Happens when (under win 7 32 bit) I come somewhere inbetween of 3,5 and 4 GB RAM use (I have 8 GB but seems to be the 32 bit problem), CPU use no problem in this case.

Over the time I have accepted that for each project I will have to slowly check out this point, yesterday it was just adding a mulab factory drum rack (ethnic), curiously the error message when mulab crashes blamed rapture, but o.k., thats just the way it is, evry system has its borders.

My main problem is the backup strategy in Mulab. The backup project is a great help for a lot of cases and has rescued me a lot of times but not for this special case.

The problem: in some cases the program not at once crashes but you only realize the problem when you try to save the project. You just get the message "projct could not be saved", save as a new project dont work either. And then it is too late cause in the background the automatic backup has ruined the backup project too.

This way I lost the work of two evenings and the main problem I could not really remember the settings (which of the hundreds of rapture guitars was it.....) of the nights before. I try to save evry new state of a project in a new folder with new date but you get crazy when then a crash happens and you have to search for the last working project/backup project.

So just the question, anyway to improve this backupstrategy in Mulab ? Maybe kind of internally check for the last "working" version and dont overwrite if there are any problems occuring in the meantime ?

Kind regards,

Richard

[MuTools]

I have again reached the point where Mulab crashes cause of unspecific memory problems. Happens when (under win 7 32 bit) I come somewhere inbetween of 3,5 and 4 GB RAM use (I have 8 GB but seems to be the 32 bit problem), CPU use no problem in this case.

That's absolutely a not recommended situation! On a 32bit windows machine you can only use up to 3.5GB of ram, iirc. If you need that much ram, better to switch to a 64 bit system.

So just the question, anyway to improve this backupstrategy in Mulab ? Maybe kind of internally check for the last "working" version and dont overwrite if there are any problems occuring in the meantime ?

When MuLab saves a project the previous saved version is first renamed to ProjectName.MuProject.Backup.
So in case there is a prob during save you still have that ProjectName.MuProject.Backup file. Duplicate that file, remove the ".Backup" extension so it has the .MuProject extension again and go from there.

But again: Eventhough i do my very best to make rock solid stable code, flirting with the RAM limits is highly not recommended and not supported, for various technical reasons.

[tatanka]

When MuLab saves a project the previous saved version is first renamed to ProjectName.MuProject.Backup.
So in case there is a prob during save you still have that ProjectName.MuProject.Backup file. Duplicate that file, remove the ".Backup" extension so it has the .MuProject extension again and go from there.

In the case I mentioned that is the problem: that dont work when Mulab not directly crashing, in the background the backup overwrites the muproject.backup with an already damaged file. When you try to save the project and get the message "project cant be saved" the backup file is already crippled and cant be opened like the original file.

Of course you are right better not to touch the limits. Its just the problem of finding the right balance between ram (sample) intesiv vsti and cpu intensiv synths. I am not quite sure if maybe there are strategies (like using a rack, but for example rapture pro dont have multioutput channels as far as I remember, with kontakt that maybe could help) too improve fewer ram use. Any help would be appreciated.

Kind regards,

Richard

[MuTools]

I don't see what's wrong with the backup strategy. It all sounds like consequences of being on ram limits, which can cause problems in various parts of the whole system, lots of parts out of my control. If you want to continue to play in the danger zone, then you'll have to check yourself whether a project has been saved well each time after saving a project.

[MuTools]

PS: If the ProjectName.MuProject.Backup turns out to be corrupt it means that it already was corrupt when it was renamed from ProjectName.MuProject to ProjectName.MuProject.Backup

[tatanka]

Yes, thats right and that was the point where I just wanted to aks if maybe this might be a point to improve the already great backup strategy.

I just cant realy understand how mulab CAN overwrite (save) the project.backup file with the already crippled open project file that could NOT be saved anymore manually.

If it only happens with overused RAM, o.k., then it is my turn to dont touch that dangerzone or bear the consequences, but I thought maybe it could happen in other situations too, so I was just asking...

[MuTools]

The ProjectName.MuProject.Backup is not "saved", it only is a renamed version from of ProjectName.MuProject before that ProjectName.MuProject is overwritten with the new save data.

[tatanka]

O.k., good to know, now I can imagine how it is possible to cripple that file too. If something is wrong in saving then that crippled file is just renamed and cant be opened too.