PLANET-H.COM

Hello.

I accidentally wiped out a whole bunch of updates due to some carelessness caused by the consistency of layout between the Load, Save, and Clr menus. I would like to see G-Stomper (and its sister apps) add some more safeguards to protect me from myself.

What happened was that I made a bunch of changes to my patterns and song arrangement in G-Stomper Studio. I went to the Main Menu to save my changes and did not realize that the Load tab was active instead of the Save tab. I selected my existing song and clicked OK to save, and G-Stomper happily reloaded the existing song, and in so doing wiped out all of my recent unsaved changes. Please add some logic to check to see if there are unsaved changes and then present the user with a confirmation prompt to warn that there are still unsaved changes that will be overwritten by the current operation; this would have been enough warning for me to realize I was using the Load operation instead of the Save operation. Also, please add a similar safeguard to the CLR operation as well when there are unsaved changes, to make sure that the user truly intended to invoke the Clear pattern/song operation.

Thanks.
Tony

Welcome to the forum, tonedef71
And thanks for your message

tonedef71 wrote:Hello.

I accidentally wiped out a whole bunch of updates due to some carelessness caused by the consistency of layout between the Load, Save, and Clr menus. I would like to see G-Stomper (and its sister apps) add some more safeguards to protect me from myself.

What happened was that I made a bunch of changes to my patterns and song arrangement in G-Stomper Studio. I went to the Main Menu to save my changes and did not realize that the Load tab was active instead of the Save tab. I selected my existing song and clicked OK to save, and G-Stomper happily reloaded the existing song, and in so doing wiped out all of my recent unsaved changes. Please add some logic to check to see if there are unsaved changes and then present the user with a confirmation prompt to warn that there are still unsaved changes that will be overwritten by the current operation; this would have been enough warning for me to realize I was using the Load operation instead of the Save operation. Also, please add a similar safeguard to the CLR operation as well when there are unsaved changes, to make sure that the user truly intended to invoke the Clear pattern/song operation.

Thanks.
Tony

Thanks a lot for your message.
Yes, I agree with you and I’m aware of that.
It was a long time a problem to implement such a flag since it wasn’t possible to separate automations from movements by a real user.
But due to some resent changes in the UI, it is now possible to apply that flag.
I’ll integrate that as soon as possible.

Thank you!

--ToneDeF

FWIW this has happened to me as well.

dag wrote:FWIW this has happened to me as well.

Not only to you;)
To me and to others as well.

Therefore this feature is on the high priority list. It's already in progress.

I can now officially confirm that the overwrite protection will be part of the next release.
In addition to the warnings, you get a small indicator at the left hand side of the main out VU meter (below the start/stop/record), that shows you at every time if your current set is dirty (has unsaved changes = red) or if it's ready to be closed (no unsaved changes = blue).
The first Beta of the upcoming release can be expected next week.