Turn Autosave ON by default (and some other improvements)

[unfa]

Simple as that.

I guess no user will be happy for saving extra 100 kB of disk for the cost of loosing extra 5 hours of work ;)

Make Autosave Feature ON by default!

And if you can - make it also save w few files, and prevent it from overwriting (without a warning!) itself when having two or three instances open. Every instance could have a random session ID and save the autosave files with this session-ID prefix like:

 57567-recovery-01.mmpz
 57567-recovery-02.mmpz
 57567-recovery-03.mmpz
 96817-recovery-01.mmpz
 57567-recovery-02.mmpz
 12422-recovery-01.mmpz
 29500-recovery-01.mmpz

Also a dedicated folder for autosave files could be nice, and a button for opening file browser in that directory would be great too.

[mikobuntu]

Unfa iirc the decision was made to turn the autosave function off by default because users who did not have much ram or cpu had crashes or freezes whenever autosave run in the background and they were using a cpu intensive plugin, e.g VeSTige . i think it was originally set to 1000ms intervals. Maybe some changes have been done since.
the interval time could be extended to perhaps every 5 minutes or such.

[mikobuntu]

@unfa on initial retesting the old high cpu spike seems to be gone. I tried with a 1 bar loop repeating in the BB_Editor with Crystall.dll vst(i) and automation of one of its filters. I let this run for a long time and also loaded some more instruments and all seemed fine. How are your findings so far Unfa?

[unfa]

Oh, somehow I must have missed that discussion.
However the unique-ID and multiple files saved could be a good option regardless of the default toggle of the whole thing.

[eagles051387]

I think the easiest solution is that it is given as an option the user can
enable them by default problem solved imho

On Tue, Jan 28, 2014 at 2:24 AM, mikobuntu notifications@github.com wrote:

Unfa iirc the decision was made to turn the autosave function off by
default because users who did not have much ram or cpu had crashes or
freezes whenever autosave run in the background and they were using a cpu
intensive plugin, e.g VeSTige . i think it was originally set to 1000ms
intervals. Maybe some changes have been done since.
the interval time could be extended to perhaps every 5 minutes or such.

Reply to this email directly or view it on GitHubhttps://github.com//issues/181#issuecomment-33442896
.

Jonathan Aquilina

[unfa]

Disabling autosave by default? I don't think it's a satysfying solution.
We're talking here about protecting the users precious work, and working to
make him feel secure while he's working. If he feels like the program can
hit him in the face with an anvil anytime - he won't be a LMMS user for
long.

There's nothing as frustrating as the fact that hours of your work are
gone, because someone didn't make the autosave on by default, or someone
didn't consider the fact that you had a second instance of LMMS running
somewhere and that instance has overwritten the recovery file with nothing,
*spraying your blood onto the sand. This is how it feels like. *I know
because I've been through.

I almost quit LMMS at some point because of this. Crashes happen, we may
never know when and why -* I think that more attention should be drawn
towards this particular safety feature.* I seriously think that we may be
loosing users because of poor crash handling.
What LMMS has is already far better than what a lot of other programs do
(nothing, but stability) - it asks to recover the previous session, but it
won't work if you have 2 instances opened, and won't work unless you dig
the options menu and enable it!

I believe that if we want to be considered a serious project, we need to
take good care of how crash handling works and make sure that the user
will not pull-off his hair when a crash occurs.

Please, if this feature causes problems, let's find out why or display a
warning, that autosave might cause system hiccups, but it's a safety belt
so better keep it on.

I'd rather stay with the old automation system than not have a decent crash
recovery in LMMS. Even though I'm delighted with the new automation system.
Why? Because it still crashes. And we can't make sure it will never crash
again.

If I knew how - I'd code this it myself, because it shoudn't be very
complicated (no DSP stuff). If someone wants to guide me into the LMMS
code, I'd like to volunteer myself.

I hope this message will be taken seriously, because I am stone cold
writing all this.

Sincerly,

• unfa

2014-01-28 eagles051387 notifications@github.com

I think the easiest solution is that it is given as an option the user can
enable them by default problem solved imho

On Tue, Jan 28, 2014 at 2:24 AM, mikobuntu notifications@github.com
wrote:

Unfa iirc the decision was made to turn the autosave function off by
default because users who did not have much ram or cpu had crashes or
freezes whenever autosave run in the background and they were using a cpu
intensive plugin, e.g VeSTige . i think it was originally set to 1000ms
intervals. Maybe some changes have been done since.
the interval time could be extended to perhaps every 5 minutes or such.

Reply to this email directly or view it on GitHub<
https://github.com/LMMS/lmms/issues/181#issuecomment-33442896>
.

Jonathan Aquilina

Reply to this email directly or view it on GitHubhttps://github.com//issues/181#issuecomment-33466282
.

Tobiasz unfa

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
!N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
b+>+++ DI>+ D+ G e h-->- !r y--()
------END GEEK CODE BLOCK------

[eagles051387]

True then in that case I think we should try and tweak as much as possible
the auto save for those on older hardware and hardware with lower ram
specifications.

On Tue, Jan 28, 2014 at 12:19 PM, unfa notifications@github.com wrote:

[image: Obraz w tre¶ci 2]

Disabling autosave by default? I don't think it's a satysfying solution.
We're talking here about protecting the users precious work, and working
to
make him feel secure while he's working. If he feels like the program can
hit him in the face with an anvil anytime - he won't be a LMMS user for
long.

There's nothing as frustrating as the fact that hours of your work are
gone, because someone didn't make the autosave on by default, or someone
didn't consider the fact that you had a second instance of LMMS running
somewhere and that instance has overwritten the recovery file with
nothing,
*spraying your blood onto the sand. This is how it feels like. *I know
because I've been through.

I almost quit LMMS at some point because of this. Crashes happen, we may
never know when and why -* I think that more attention should be drawn
towards this particular safety feature.* I seriously think that we may be
loosing users because of poor crash handling.
What LMMS has is already far better than what a lot of other programs do
(nothing, but stability) - it asks to recover the previous session, but it
won't work if you have 2 instances opened, and won't work unless you dig
the options menu and enable it!

I believe that if we want to be considered a serious project, we need to
take good care of how crash handling works and make sure that the user
will not pull-off his hair when a crash occurs.

Please, if this feature causes problems, let's find out why or display a
warning, that autosave might cause system hiccups, but it's a safety belt
so better keep it on.

I'd rather stay with the old automation system than not have a decent
crash
recovery in LMMS. Even though I'm delighted with the new automation
system.
Why? Because it still crashes. And we can't make sure it will never crash
again.

If I knew how - I'd code this it myself, because it shoudn't be very
complicated (no DSP stuff). If someone wants to guide me into the LMMS
code, I'd like to volunteer myself.

I hope this message will be taken seriously, because I am stone cold
writing all this.

Sincerly,

• unfa

2014-01-28 eagles051387 notifications@github.com

I think the easiest solution is that it is given as an option the user
can
enable them by default problem solved imho

On Tue, Jan 28, 2014 at 2:24 AM, mikobuntu notifications@github.com
wrote:

Unfa iirc the decision was made to turn the autosave function off by
default because users who did not have much ram or cpu had crashes or
freezes whenever autosave run in the background and they were using a
cpu
intensive plugin, e.g VeSTige . i think it was originally set to
1000ms
intervals. Maybe some changes have been done since.
the interval time could be extended to perhaps every 5 minutes or
such.

Reply to this email directly or view it on GitHub<
https://github.com/LMMS/lmms/issues/181#issuecomment-33442896>
.

Jonathan Aquilina

Reply to this email directly or view it on GitHub<
https://github.com/LMMS/lmms/issues/181#issuecomment-33466282>
.

Tobiasz unfa

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
!N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
b+>+++ DI>+ D+ G e h-->- !r y--()
------END GEEK CODE BLOCK------

Reply to this email directly or view it on GitHubhttps://github.com//issues/181#issuecomment-33469884
.

Jonathan Aquilina

[unfa]

I agree with you on these points. Please file them as issues on the
tracker. both the autosave and the crash handling. As well for the auto
save we need to enable some sort of recovery of the files that were not
saved just like word and libreoffice do wiht documents.

On Tue, Jan 28, 2014 at 12:19 PM, Tobiasz Karoń unfa00@gmail.com wrote:

[image: Obraz w treści 2]

Disabling autosave by default? I don't think it's a satysfying solution.
We're talking here about protecting the users precious work, and working
to make him feel secure while he's working. If he feels like the program
can hit him in the face with an anvil anytime - he won't be a LMMS user for
long.

There's nothing as frustrating as the fact that hours of your work are
gone, because someone didn't make the autosave on by default, or someone
didn't consider the fact that you had a second instance of LMMS running
somewhere and that instance has overwritten the recovery file with nothing,
*spraying your blood onto the sand. This is how it feels like. *I know
because I've been through.

I almost quit LMMS at some point because of this. Crashes happen, we may
never know when and why -* I think that more attention should be drawn
towards this particular safety feature.* I seriously think that we may be
loosing users because of poor crash handling.
What LMMS has is already far better than what a lot of other programs do
(nothing, but stability) - it asks to recover the previous session, but it
won't work if you have 2 instances opened, and won't work unless you dig
the options menu and enable it!

I believe that if we want to be considered a serious project, we need to
take good care of how crash handling works and make sure that the user
will not pull-off his hair when a crash occurs.

Please, if this feature causes problems, let's find out why or display a
warning, that autosave might cause system hiccups, but it's a safety belt
so better keep it on.

I'd rather stay with the old automation system than not have a decent
crash recovery in LMMS. Even though I'm delighted with the new automation
system.
Why? Because it still crashes. And we can't make sure it will never crash
again.

If I knew how - I'd code this it myself, because it shoudn't be very
complicated (no DSP stuff). If someone wants to guide me into the LMMS
code, I'd like to volunteer myself.

I hope this message will be taken seriously, because I am stone cold
writing all this.

Sincerly,

• unfa

2014-01-28 eagles051387 notifications@github.com

I think the easiest solution is that it is given as an option the user can
enable them by default problem solved imho

On Tue, Jan 28, 2014 at 2:24 AM, mikobuntu notifications@github.com
wrote:

Unfa iirc the decision was made to turn the autosave function off by
default because users who did not have much ram or cpu had crashes or
freezes whenever autosave run in the background and they were using a
cpu
intensive plugin, e.g VeSTige . i think it was originally set to 1000ms
intervals. Maybe some changes have been done since.
the interval time could be extended to perhaps every 5 minutes or such.

Reply to this email directly or view it on GitHub<
https://github.com/LMMS/lmms/issues/181#issuecomment-33442896>
.

Jonathan Aquilina

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/181#issuecomment-33466282
.

Tobiasz unfa

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
!N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
b+>+++ DI>+ D+ G e h-->- !r y--()
------END GEEK CODE BLOCK------

---

WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.

http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk

---

LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel

Jonathan Aquilina

[unfa]

Yes, LibreOffice does this well IMHO.
I will put these on Github tomorrow.
On 28 Jan 2014 13:32, "Jonathan Aquilina" eagles051387@gmail.com wrote:

I agree with you on these points. Please file them as issues on the
tracker. both the autosave and the crash handling. As well for the auto
save we need to enable some sort of recovery of the files that were not
saved just like word and libreoffice do wiht documents.

On Tue, Jan 28, 2014 at 12:19 PM, Tobiasz Karoñ unfa00@gmail.com wrote:

[image: Obraz w tre¶ci 2]

Disabling autosave by default? I don't think it's a satysfying solution.
We're talking here about protecting the users precious work, and working
to make him feel secure while he's working. If he feels like the program
can hit him in the face with an anvil anytime - he won't be a LMMS user for
long.

There's nothing as frustrating as the fact that hours of your work are
gone, because someone didn't make the autosave on by default, or someone
didn't consider the fact that you had a second instance of LMMS running
somewhere and that instance has overwritten the recovery file with nothing,
*spraying your blood onto the sand. This is how it feels like. *I know
because I've been through.

I almost quit LMMS at some point because of this. Crashes happen, we may
never know when and why -* I think that more attention should be drawn
towards this particular safety feature.* I seriously think that we may
be loosing users because of poor crash handling.
What LMMS has is already far better than what a lot of other programs do
(nothing, but stability) - it asks to recover the previous session, but it
won't work if you have 2 instances opened, and won't work unless you dig
the options menu and enable it!

I believe that if we want to be considered a serious project, we need to
take good care of how crash handling works and make sure that the user
will not pull-off his hair when a crash occurs.

Please, if this feature causes problems, let's find out why or display a
warning, that autosave might cause system hiccups, but it's a safety belt
so better keep it on.

I'd rather stay with the old automation system than not have a decent
crash recovery in LMMS. Even though I'm delighted with the new automation
system.
Why? Because it still crashes. And we can't make sure it will never crash
again.

If I knew how - I'd code this it myself, because it shoudn't be very
complicated (no DSP stuff). If someone wants to guide me into the LMMS
code, I'd like to volunteer myself.

I hope this message will be taken seriously, because I am stone cold
writing all this.

Sincerly,

• unfa

2014-01-28 eagles051387 notifications@github.com

I think the easiest solution is that it is given as an option the user
can
enable them by default problem solved imho

On Tue, Jan 28, 2014 at 2:24 AM, mikobuntu notifications@github.com
wrote:

Unfa iirc the decision was made to turn the autosave function off by
default because users who did not have much ram or cpu had crashes or
freezes whenever autosave run in the background and they were using a
cpu
intensive plugin, e.g VeSTige . i think it was originally set to 1000ms
intervals. Maybe some changes have been done since.
the interval time could be extended to perhaps every 5 minutes or such.

Reply to this email directly or view it on GitHub<
https://github.com/LMMS/lmms/issues/181#issuecomment-33442896>
.

Jonathan Aquilina

Reply to this email directly or view it on GitHubhttps://github.com//issues/181#issuecomment-33466282
.

Tobiasz unfa

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
!N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
b+>+++ DI>+ D+ G e h-->- !r y--()
------END GEEK CODE BLOCK------

---

WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.

http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk

---

LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel

Jonathan Aquilina

[mikobuntu]

Unfa you have made a strong argument on the autosave function being ON, i have to agree with you that it should be on by default! And the unique ID's , is a good idea too, at least that way if a project becomes so corrupted somehow, you can at least revert to a previous time in your crashed project and will have saved a good amount of work. I wonder what way this would work, 1 method could be to write this new unique ID file out whenever a certain amount of info ( kb / mb ) has been added to the project, so this would need some kind of feedback from the Autosave function and method 2 could be timebased for example every 10 mins a new file is written into a crash directory and maybe this along with the last one are kept while the previous is deleted ?

so this would be zero starting point a file 124587.mmpz is saved as soon as a new project is created, 10 mins later 124523.mmpz is created in the same folder. now another 10 mins pass 214563.mmpz is created and the 1st file 124587.mmpz is deleted as it is no longer required. this cycle will loop until the song is closed.

[unfa]

I'd add a lmms/backup/ folder in with all files are stored with
uniqueID-prefixes.

I've got an idea of a custom-sized "backup buffer".
User would have a slider to set how much space he wants to be dedicated to
backup copies:
1 MB, 2 MB, 5 MB, 10 MB, 20 MB, 50 MB or 100 MB.

When the space limit is reached, LMMS deletes the oldest file in the folder
and re-tries saving. If placeholders (another safety-increasing idea I got)
are ON, it also deletes placeholder files first. and adds them to fill up
the buffer.
The placeholder files could be 10 KB blank files that occupy the space on
disk until LMMS needs that space. They'll help guarantee that when LMMS
needs to save a backup file - it'll have a way to free up some disk space
to do that.

If the disk is full, and recovery has to save a 55kB file, LMMS can delete
6 placeholder files (60kB total) and save that file even if the disk had 0
bytes left. Unless some other process can use up the space faster...

The placeholders can have different sizes too (1 kB, 10 kB, 100 kB, 1MB, 10
MB) to reduce the amount of files.

The zero bytes left was an issue to me sometimes (I made a track of that
title).

Maybe just one file could be used:

LMMS needs to save a backup?

1. It deletes the placeholder file
2. It saves whatever it needs to save
3. It checks how much free space is now left in the buffer
4. It writes an empty file that has the exact size of the space left for
   the buffer
5. Repeat from 1 ;)

This could be problematic if another process tries to write data to disk
agressively - it could eat all the space before LMMS saves the backup.

2014-01-28 mikobuntu notifications@github.com

Unfa you have made a strong argument on the autosave function being ON, i
have to agree with you that it should be on by default! And the unique ID's
, is a good idea too, at least that way if a project becomes so corrupted
somehow, you can at least revert to a previous time in your crashed project
and will have saved a good amount of work. I wonder what way this would
work, 1 method could be to write this new unique ID file out whenever a
certain amount of info ( kb / mb ) has been added to the project, so this
would need some kind of feedback from the Autosave function and method 2
could be timebased for example every 10 mins a new file is written into a
crash directory and maybe this along with the last one are kept while the
previous is deleted ?

Reply to this email directly or view it on GitHubhttps://github.com//issues/181#issuecomment-33503950
.

Tobiasz unfa

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
!N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
b+>+++ DI>+ D+ G e h-->- !r y--()
------END GEEK CODE BLOCK------

[eagles051387]

Keep up the good work Unfa :) this for sure is a great addition to lmms

On Wed, Jan 29, 2014 at 12:27 AM, unfa notifications@github.com wrote:

I'd add a lmms/backup/ folder in with all files are stored with
uniqueID-prefixes.

I've got an idea of a custom-sized "backup buffer".
User would have a slider to set how much space he wants to be dedicated to
backup copies:
1 MB, 2 MB, 5 MB, 10 MB, 20 MB, 50 MB or 100 MB.

When the space limit is reached, LMMS deletes the oldest file in the folder
and re-tries saving. If placeholders (another safety-increasing idea I got)
are ON, it also deletes placeholder files first. and adds them to fill up
the buffer.
The placeholder files could be 10 KB blank files that occupy the space on
disk until LMMS needs that space. They'll help guarantee that when LMMS
needs to save a backup file - it'll have a way to free up some disk space
to do that.

If the disk is full, and recovery has to save a 55kB file, LMMS can delete
6 placeholder files (60kB total) and save that file even if the disk had 0
bytes left. Unless some other process can use up the space faster...

The placeholders can have different sizes too (1 kB, 10 kB, 100 kB, 1MB, 10
MB) to reduce the amount of files.

The zero bytes left was an issue to me sometimes (I made a track of that
title).

Maybe just one file could be used:

LMMS needs to save a backup?

1. It deletes the placeholder file
2. It saves whatever it needs to save
3. It checks how much free space is now left in the buffer
4. It writes an empty file that has the exact size of the space left for
   the buffer
5. Repeat from 1 ;)

This could be problematic if another process tries to write data to disk
agressively - it could eat all the space before LMMS saves the backup.

2014-01-28 mikobuntu notifications@github.com

Unfa you have made a strong argument on the autosave function being ON, i
have to agree with you that it should be on by default! And the unique
ID's
, is a good idea too, at least that way if a project becomes so corrupted
somehow, you can at least revert to a previous time in your crashed
project
and will have saved a good amount of work. I wonder what way this would
work, 1 method could be to write this new unique ID file out whenever a
certain amount of info ( kb / mb ) has been added to the project, so this
would need some kind of feedback from the Autosave function and method 2
could be timebased for example every 10 mins a new file is written into a
crash directory and maybe this along with the last one are kept while the
previous is deleted ?

Reply to this email directly or view it on GitHub<
https://github.com/LMMS/lmms/issues/181#issuecomment-33503950>
.

Tobiasz unfa

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
!N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
b+>+++ DI>+ D+ G e h-->- !r y--()
------END GEEK CODE BLOCK------

Reply to this email directly or view it on GitHubhttps://github.com//issues/181#issuecomment-33539931
.

Jonathan Aquilina

[Sti2nd]

Close?

[diizy]

I think autosave needs to be disabled during playback.

[Sti2nd]

Yeah, for some it crashes LMMS, so autosave off during playback would be nice

[musikBear]

I think autosave needs to be disabled during playback.

YES 💯 !

[unfa]

Or maybe the autosave can be handled by a separate thread, that operates on low priority (high nice value) so that it won't block DSP processing during playback?

[softrabbit]

Autosave is disabled during playback, right? https://github.com/LMMS/lmms/blob/master/src/gui/MainWindow.cpp#L1343

[musikBear]

Autosave is disabled during playback, right?

autosave should be disabled in all situations except 'idle' ..(hard to define) . And definitively be optional.
If autosave kicks in as you are moving a block in edit-mode, The block 'drops' off, In automation editor, you draw wrong. It is completely annoying, and must be optional, also a user time setting for like 5, 10, 15, 30 mins between autosave, would be advice able - (?? how long are current intervals??) But !!
Definitively optional as it is now
I think a tiny icon in main bar, just flashing a couple of times, would be better, then the user has the choice to do a version save, or a regular save, or nothing.
Here are autosave profiles for cpu usage (0.9 i believe it was..in 2012 anywhitch.. Toby gracefully gave me an exe where it was disabled, then it became optional)

[Sti2nd]

Wait, what is wrong with using your processor again?

[musikBear]

@Sti2nd -you are right, nothing wrong with that, but (on my system at least) this process results in lmms un-responsiveness, and a break in the functionality for ~1-2 secd -Thats the bad thing, about it, but i have a new angle on this, i just have to formulate this new proposal for a new kind of autosave.

[musikBear]

I have redone the auto v manual saving winx32 on @Umcaruje Master of 01.07.15

there is still quite some usage, and also influence on the work being done in lmms at the time of auto-save-event, but it is definitely improved!
imho autosave takes place far to often
Other programs auto-backup every 5-10 min
But again: Why not make this a user option ?
Another quite strange decision is to use the name 'recover.mmp'
Why is the recover-file-name, not a string-concat of the hardcoded string 'recover' and the user project-name
So 'MyProject.mmpz' is saved as recover-files as MyProject_recover.mmp
Users are loosing the recover.mmp, because they try to open a new file, after a fail, and then the recover-feature is useless
Recover need to be

• user-optional like 1..20 minutes
• preserved as a concat-named string

If it should be a real fail-safe

[Spekular]

+1 for these suggestions.

[zonkmachine]

I've fixed some of the issues mentioned in this thread. Nothing merged yet though.
Work done here #2176

Or maybe the autosave can be handled by a separate thread, that operates on low priority (high nice value) so that it won't block DSP processing during playback?

👍 I don't know how problematic it is though considering that we're multi platform and here we have to call the OS directly so this would probably be done differently depending on what OS we're working against. And I suck on OS's. I basically use my mouse to whack the computer...
@musikBear I don't think just watching the CPU usage history tells us that much. If you install BOINC which is a system that let's you lend your free CPU time to render projects online and now watch your usage you will see it just flat out at max ( or whatever percentage you allow it to ) but you won't notice any difference in how the computer behaves. This is because the processes are run at a very low priority. See unfas comment above.

[musikBear]

@zonkmachine no the measures are more empiric, eg comparing prior to current. I can however tell you that in the case of autosave in lmms, there has always been a serious connection to usability and lag. Back when autosave first was implemented, the lag was so awful that it was impossible to do editing (I got a lot on that story, because Toby extremely kindly made me a special .exe back then :)

[zonkmachine]

I trust you all on the "it's been bad" part. I haven't actually used autosave myself until now. I also haven't addressed any of the problems concerning performance when the autosave kicks in but I can see it can be a bit of a problem to fix. The autosave needs to take a snapshot of a project before it changes so it has to work hard and fast. Someone who has really big projects like Unfa will be most impactd. Maybe we need different priority levels of autosave. First a low priority one that will try and save a couple of times with low priority to not interfere at all and then after failing too many times hands over to the big bad 'now we really need to save this' function to finish the job.

[tresf]

If you're using signals and slots to set priority: http://doc.qt.io/qt-4.8/qthread.html#Priority-enum

There are several places in our code which are fired by a particular priority and should be lowered (or raised).

Here's a good conversation on it: #1600 (comment)

-Tres

[zonkmachine]

If you're using signals and slots to set priority: http://doc.qt.io/qt-4.8/qthread.html#Priority-enum

There are several places in our code which are fired by a particular priority and should be lowered (or raised).

Here's a good conversation on it: #1600 (comment)

Thanks! I'll look into this. For the auto save I think running it on a low priority means you'd need some method to counter for when the project is modified while a save is going on. Something like two saves and a successful compare of checksums equals a new recoverfile.

If autosave kicks in as you are moving a block in edit-mode, The block 'drops' off, In automation editor, you draw wrong.

@musikBear I don't see this. Do you still get this?

I've started optimising the logic of the auto save here #2512 to see if I can counter possible performance issues.

[musikBear]

@zonkmachine Autosave will still make the pc 'hang' for a few seconds. The event looks like this

on your binary g23d2824.
Yellow is a manual save, the two red are autosaves
But imo the worst problem is that autosave still overwrites 'recover.mmp'. The idea about having a timestamp, or similar concatenations, added to the filename, has not been implemented. eg #2174 #2176 has been closed without fix.

[zonkmachine]

Yellow is a manual save, the two red are autosaves

Yes. But what about when you drag something and the autosave kicks in?

But imo the worst problem is that autosave still overwrites 'recover.mmp'. The idea about having a timestamp, or similar concatenations, added to the filename, has not been implemented. eg #2174 #2176 has been closed without fix.

#2174 was closed as what I perceived as the main cause of that particular issue was that LMMS didn't warn before closing and deleting a recovered project and this was fixed. The rest of that issue is covered here already. #2176 was closed as it was a good place to stop. Many bug fixes and I've explained it in the first post of that issue. For now I'm into performance issues only. Multiple save files will have to wait but will probably come true around 1.3

on your binary g23d2824.

I don't know this one. Link?

[musikBear]

Yes. But what about when you drag something and the autosave kicks in?

yes, and all other running programs are heavily influenced too

For now I'm into performance issues only

Understood

I don't know this one. Link?

Its your repository that Tresf made into a windows binary. I thought it was your id-stamp tresf used. I have no idea what the id-stamp covers, though 8|

[grejppi]

@zonkmachine @musikBear 23d2824 is the commit that build was made from.

[zonkmachine]

yes, and all other running programs are heavily influenced too

#2512 should make your work in lmms be less affected by the autosave, but for the case where other applications are affected that's not something I can fix easily.
You could try something like: http://www.wikihow.com/Change-Process-Priorities-in-Windows-Task-Manager and run LMMS in it's entirety on a lower priority but I've never done this in Windows and I don't know how the saves could be compromised by this.

23d2824 is the commit that build was made from.

Thanks! I thought searching a commit hash was the thing but you're apparently supposed to use it a s a link directly.

[musikBear]

Following 2512 with high interest, because fail-save is an important feature. If i understand correctly @zonkmachine you have managed to omit autosave events during editing, and an autosave will only happen, if lmms is truly idle. I like that! 👍
There are still things that need to be 'fixed' Especially concatenated saving-names, and a user scheduled time-interval between each autosave, and then it properly wont be an issue any more at all, because a tiny delay every 5 mins or so, is not a big deal. Word also flashes a short 'Please wait' as it autosave :p
I cant resist making one of my, for some, notorious stupid input, alternative thinking imo :p
So.. In case autosave never reach a reasonable usability:
Autosave could be omitted, and replaced by a tiny red diode, that simply would start to flash, after a user-set period of time, just telling the user, that a manual save would be a wise thing to do.

[zonkmachine]

If autosave kicks in as you are moving a block in edit-mode, The block 'drops' off, In automation editor,
you draw wrong.?

Sorry, I didn't get your answer to this so I ask again. Do you still drop things? Yes/No

@zonkmachine you have managed to omit autosave events during editing, and an autosave will only happen, if lmms is truly idle. I like that! 👍

Auto saves already will happen only when lmms is idle. It's just more likely to be idle when you press the stop button so I force a save there. The problem is that (a) these are workarounds for the ineffective saves and not real fixes, and (b) The auto save function is getting a bit over complex under my care.

[musikBear]

The auto save function is getting a bit over complex under my care.

I think you done fine. Placing an auto-save event just after pressing stop is good, imo.

Do you still drop things? Yes/No
@zonkmachine

Yes, when i wrote no difference that was also for the dragging of a block ao. drawing in automation. Incidentally, any other proggie running, will also do a 'hickup'
I have a cracy idea, that im going to fiddle with tonight at home, but thats propl. just one of my usuals
In short: What happens if mmpz is chosen.

[zonkmachine]

#3032 I had a go at fixing recover files for multiple instances of LMMS. It's currently a bit rudimentary but working. Feedback, testing and ideas welcome. Here or there... 🐷

[jasp00]

The solution to recover projects should be:

1. Fix the undo/redo system.
2. Save journal entries to disk as they are created, like a database, including undo/redo entries.
3. On recovery, replay the journal.

[zonkmachine]

That makes sense but is probably not within my coding abilities. That would solve any performance issues discussed here previously, wouldn't it? How much work would that involve?
The undo/redo system should be fixed anyway so that's a separate post.

[jasp00]

That makes sense but is probably not within my coding abilities. That would solve any performance issues discussed here previously, wouldn't it? How much work would that involve?

You have the abilities, it is a matter of lots of free time.

[zonkmachine]

Make Autosave Feature ON by default!

As of c54171b auto-save is on by default. The default behaviour is also to save while playing which can be disabled if you experience any issues with this.

Leave this issue open for now.

[Umcaruje]

As of c54171b auto-save is on by default. The default behaviour is also to save while playing which can be disabled if you experience any issues with this.

it seems that this is not the case anymore, it was probably changed again somewhere in the subsequent commits.

[zonkmachine]

OK, I'll look into it.

[tresf]

This was closed a while ago by #3551. Closing.