More spurious "ReaScript: Run" in Undo History

[JustSayin]

ReaScript: Run should appear in the Undo History ONLY when a script changes the REAPER memory state.

Unfortunately, there are many examples highlighted in this forum where these highly annoying and spurious Reascript: Run messages corrupt the Undo History. Please fix.

Here's one more (totally vanilla REAPER 6.75, running on either Mac and Windows):

• Open a fresh project (Undo History: ---Initial state---)
• Create a track using "Track: Insert new track" (40001). (Undo History: Add new track).
• Load the following script into the action list and click the Run button

  reaper.CountTrackMediaItems(reaper.GetTrack(0,0))

And voilà, you now have a corrupted Undo History with ReaScript: Run!



This script simply counts the number of items on the newly created track and DOES NOTHING to change the memory state of REAPER.

There is no meaning to "undoing" something that didn't DO anything!

And furthermore, if reaper.CountTrackMediaItems or reaper.GetTrack ARE doing something to the REAPER memory state as undocumented side effects, then those are also bugs that need to be fixed.

[X-Raym]

This is how to have a script without undo:

function Main()
  reaper.CountTrackMediaItems(reaper.GetTrack(0,0))
end

reaper.defer(Main)

I thin "history corruption" is a strong work as it implies the history doesn't work anymore.

[JustSayin]

Originally Posted by X-Raym

This is how to have a script without undo:

function Main()
  reaper.CountTrackMediaItems(reaper.GetTrack(0,0))
end

reaper.defer(Main)

That is only useful if you want to defer an operation (which, by the way, takes many milliseconds and is very slow when doing time sensitive operations). It also changes the order of execution. So that is not at all a solution to this serious and fundamental bug.

It is corruption, because it does not reflect reality. It is fundamentally incorrect.

[JustSayin]

After further experimentation, I have confirmed that in this case the ReaScript: Run undo history corruption is caused by spurious side effects of reaper.CountTrackMediaItems.

This bug, and any others like it, need to be fixed.

The work-around for now is to add the following line to your code to undo whatever spurious nonsense the reaper API function has created.

reaper.Undo_OnStateChange("ReaScript: Run")

[X-Raym]

@JustSaying

It is corruption, because it does not reflect reality.

Corruption means data has been altered which is not the case there.


----

The defer script works.

-- Your actual code
reaper.CountTrackMediaItems(reaper.GetTrack(0,0))
-- End of your code
reaper.defer(function() end)

The code main code will run under 2.0000152289867e-006 seconds and without any undo point.

--


This question has already been answer by Justin himself:
https://forum.cockos.com/showpost.ph...02&postcount=4


Just like my answer, it may not be satisfying I suppose. But it is what we got. We're on the same boat so don't blame me if there is no better way.

[FeedTheCat]

Originally Posted by X-Raym

-- Your actual code
reaper.CountTrackMediaItems(reaper.GetTrack(0,0))
-- End of your code
reaper.defer(function() end)

Yep, that's the way. The only downside to this approach is that it can occasionally pop up the "ReaScript task control" that asks if you want to terminate instances etc (only happens when the user runs the script twice really fast). This dialog is very confusing to users already, even more so if it's a one-off script that shouldn't run in the background...

Really hope we'll get an option to answer this dialog on the script side... Here's the FR

[Meo-Ada Mespotine]

I once described how to recreate this behavior.

I noticed that the undo-points have stuff like sws cycle-actions in them, so the project is changed, but by something completely unrelated.

Can you post the undo state? You can get it by opening the undo-list, right clicking the undo state and hit Show undo state information or something similar.
Then a window appears with lines that have + at their beginnings.
Copy n paste this, so I can add this to my old bugreport as another hint at the behavior.

Edit: the example in the opening post should be the SWS-cycle actions added to the undo point from what it looks like.

[X-Raym]

I'm definitely +1 this FR. It is pretty rare that a script need two instances. I can only see heda's notes reader for that, and even this comes in several action in the action list to allow that ^^

[Meo-Ada Mespotine]

Originally Posted by X-Raym

I'm definitely +1 this FR. It is pretty rare that a script need two instances. I can only see heda's notes reader for that, and even this comes in several action in the action list to allow that ^^

wrong thread? 😅

[X-Raym]

@mespotine
It in fact seems to initialize the project by adding extension data for cycle actions:


Here is the diff log

<EXTENSIONS
...
     {ABEDA7BC-CA7A-46C8-9E8D-C94BFC0C241A} 0 "" "" ""
     {28590BE8-97D4-4376-A63A-E965ACFB6190} 0 "" "" ""
     {30766988-F13F-43D5-A090-E7CA2B3D3940} 0 "" "" ""
     >
+    <S&M_CYCLACTIONS
+    0 0 0 0
+    0 1 0 0
+    0 2 0 0
+    0 3 0 0
+    0 4 0 0
+    0 5 0 0
+    0 6 0 0
+    0 7 0 0
+    >
 >

[X-Raym]

This means that on a saved project, the issue doesn't appear.

reaper.CountTrackMediaItems(reaper.GetTrack(0,0))

Will display no undo entry.




🧐weird, it seems to only do that in first tab. For the other tab, even unsaved it doesnt display any undo point.






EDIT: I removed my cycle action and it doesnt trigger the undo entry anymore.

[FeedTheCat]

Originally Posted by X-Raym

It is pretty rare that a script need two instances. I can only see heda's notes reader for that, and even this comes in several action in the action list to allow that ^^

All the scripts that have the defer trick should ideally be answered with "New instance". Then explain that to a user that has to google what an instance is

[FeedTheCat]

Originally Posted by X-Raym

This means that on a saved project, the issue doesn't appear.

Yes, the undo point will only be created when there is an "uncommitted" undo state that wasn't previously included in a block.

I think of it like git. Anything you "git add", will be included in your next commit

Let's say you run a script that changes item selection, but doesn't create undo points using the defer trick.

When you now run

reaper.CountTrackMediaItems(reaper.GetTrack(0,0))

these item selection changes will be included in the "Reascript run" block.

Unfortunately though, it's not just irresponsible coders messing up their undo blocks, REAPER has a lot of these "uncommitted" states by itself.

Which is why the recommended approach by Justin doesn't work in practice. You can "put everything back into place", but if there are previous "uncommitted" changes.... you end up with an undo block. Nothing you can do about it (except using the defer trick).

[Justin]

Originally Posted by FeedTheCat

Unfortunately though, it's not just irresponsible coders messing up their undo blocks, REAPER has a lot of these "uncommitted" states by itself.

If you find these, tell us!

(fixing the one from creating a new track, oops)

[Justin]

Originally Posted by JustSayin

There is no meaning to "undoing" something that didn't DO anything!

And furthermore, if reaper.CountTrackMediaItems or reaper.GetTrack ARE doing something to the REAPER memory state as undocumented side effects, then those are also bugs that need to be fixed.

They aren't doing anything -- if the reascript just does "x=1" then it wlil have the same behavior.


Having said that, if you'd like, you can begin all of your ReaScripts with:

reaper.Undo_OnStateChangeEx("Blame Canada",-1,-1)

This will let you make sure that any changes your script does are included in the "Run: ReaScript" block (which will be omitted if your script doesn't change anything), and any latent changes that were left around are categorized accordingly.

[Meo-Ada Mespotine]

Originally Posted by Justin

If you find these, tell us!

(fixing the one from creating a new track, oops)

SetExtState triggers such undo-points, when uncommitted changes exist. That was the one with whom I found out about cyclactions in the undo-state.

Edit: here's my old bugreport

https://forum.cockos.com/showthread.php?p=2517876

[FeedTheCat]

Originally Posted by Justin

If you find these, tell us!

(fixing the one from creating a new track, oops)

Will do, didn't know this was considered a bug.

Originally Posted by Justin

(fixing the one from creating a new track, oops)

Nice, that is the obvious one. Just in case you missed it, SHOWINMIX only occurs when the mixer is visible.

-    SHOWINMIX 1 0.6667 0.5 1 0.5 -1 -1 -1
+    SHOWINMIX 1 0.6667 0.5 1 0.5 0 -1 -1
     REC 0 5088 1 0 0 0 0 0
     VU 2
-    TRACKHEIGHT 0 0 0 -1 -1 0
+    TRACKHEIGHT 0 0 0 0 -1 0

[Justin]

Originally Posted by Meo-Ada Mespotine

SetExtState triggers such undo-points, when uncommitted changes exist. That was the one with whom I found out about cyclactions in the undo-state.

Edit: here's my old bugreport

https://forum.cockos.com/showthread.php?p=2517876

SetExtState can't possibly modify undo state.

Just tested it -- it behaves exactly the same if you replace the script with a no-op "x=1". Do the blame canada method and there you go.

Edit: hmm, actually, the API that extensions can use to register their state... that shouldn't be subject to the undo system, IMO. Project state set by scripts is already excluded.

[JustSayin]

Originally Posted by X-Raym

@JustSaying

Corruption means data has been altered which is not the case there.

It is precisely the case here. Data has been altered, namely the incorrect data placed in the Undo History. As Justin has already stated, he will fix this bug.

But there are several other such cases that produce spurious and erroneous undo history corruptions with "ReaScript: Run" and they have been reported many times here in the forum. But there seems to be some strong desire to ignore these obvious, long-standing, annoying, and continuing fundamental bugs.

Not sure why.

The principle is really very simple, if the internal state of a project has not changed (i.e. were the project to be saved out to its RPP file, nothing in the file would have changed), then there should be no undo history entry, end of story.

Any behavior other than this is a corruption of the undo history.

[Meo-Ada Mespotine]

@Justsayin
Could you be a little more polite?

Undo is difficult and in most cases I observed, no one posted the undo-state-information to get the actual added data that shouldn't be there.

But if you know otherwise, well, post a link to these reports that show it more detailed, as it's otherwise damn difficult to find out about that.
It took me days to figure out the SWS-Cyclactions-undo-issue as it was really difficult to tackle. Other such bugs might even be more difficult to trigger.

It's easy to say "Undo is corrupted" but if that's the only information to work from, there's not much you can do with it. You need more details.

[schwa]

Originally Posted by JustSayin

But there seems to be some strong desire to ignore these obvious, long-standing, annoying, and continuing fundamental bugs.

There's really no need to be so choleric.

[X-Raym]

You are confusing corruption and alteration. Yes undo history is altered, cause it changed, but not corrupted, cause it still works. Corruption means data reading errors. It is not the case here.

We all agree that unecessary undo points should be erased. All is needed is propper bug reports. Rudeness isnt helpful in any way.

[nicholas]

Originally Posted by X-Raym

We all agreee that unecessary undo points should be erased. All is needed is propper bug reports. Rudeness isnt helpful in any way.

So true.

But I fear that in this case youy are flogging a dead horse.

[JustSayin]

Originally Posted by X-Raym

You are confusing corruption and alteration. Yes undo history is altered, cause it changed, but not corrupted, cause it still works. Corruption means data reading errors. It is not the case here.

We all agree that unecessary undo points should be erased. All is needed is propper bug reports. Rudeness isnt helpful in any way.

It's not that the undo points are "unnecessary" it's that they are incorrect.

REAPER is a state machine. As @Justin and @Schwa have pointed out on several occasions, the Undo History is supposed to exclusively report when that internal state changes. If it contains entries reporting state changes that do not exist, then it is incorrect (aka "spurious" or "corrupted") and cannot be relied upon to accurately report state changes.

With all due respect, I believe it is you who is misunderstanding here.

[White Tie]

Its not very fair to move the goalposts from 'corrupt' to 'incorrect' in a pointless effort to score semantic points against X-Raym who's not even using his native language.

Your VPN will only get you so far, we're not stupid. Be nice.

[Meo-Ada Mespotine]

incorrect

Is it you, Cohler?

[vitalker]

Originally Posted by Meo-Ada Mespotine

Is it you, Cohler?

Maybe Curtis or Bri8. Who knows.

[vitalker]

English is not my native language, but even I understand that "corrupted" and "incorrect" are pretty much different words. Corrupted is kind of error and incorrect is just different value.

[schwa]

Putting aside the semantics, to be clear and restate what has already been said in this thread:

Every entry in the undo history represents a change in state from the previous entry. The undo history is not corrupted and the undo states are correct.

The issue or bug in this case is that the undo states are not labeled correctly.

Checking the entire project state is costly; it's effectively the same process as saving the project. So for efficiency, actions only update the undo history for the parts of the project state that they could possibly have affected. For example, moving a volume knob is not going to check the FX undo state.

Occasionally, an action might change parts of the project state but not update the undo history completely. That's a bug, and we fix actions like that when we come across them. But when it happens, the latent or pending undo state is included in the next undo point that includes the same kinds of changes as the latent ones.

"ReaScript: Run" by design checks all of the project undo state, so it effectively collects any pending undo changes. The obvious fix for this on our side is to check the project undo state before running the script as well as afterwards. The practical result will be that where currently a reascript that does not change the project state results in an occasional "ReaScript: Run" undo point, instead that undo point would be labeled something like "Undo: Sync".

[vitalker]

Originally Posted by schwa

The obvious fix for this on our side is to check the project undo state before running the script as well as afterwards. The practical result will be that where currently a reascript that does not change the project state results in an occasional "ReaScript: Run" undo point, instead that undo point would be labeled something like "Undo: Sync".

Wouldn't this affect performance for deferred scripts and the whole project while such scripts are running?

[schwa]

Not really, no.

[FeedTheCat]

Originally Posted by schwa

"ReaScript: Run" by design checks all of the project undo state, so it effectively collects any pending undo changes. The obvious fix for this on our side is to check the project undo state before running the script as well as afterwards. The practical result will be that where currently a reascript that does not change the project state results in an occasional "ReaScript: Run" undo point, instead that undo point would be labeled something like "Undo: Sync".

I think an option for scripts to bypass this collection of pending undo changes would be really useful. E.g. a special flag to Undo_EndBlock where all changes to project state inside this block would become latent. This would allow us to write scripts (or blocks inside a running defer script) that never create undo points, guaranteed. Any changes to state would then be collected by the next project state change.

Depending on how the undo system is designed, this might be close to impossible though. And maybe it's not a good idea to give us this power & responsibility

I will say though, I have spent far too many hours tricking REAPER into not creating an undo point...

Figuring out stuff like using:

reaper.SetMediaTrackInfo_Value(track, 'I_SELECTED', 1)

instead of

reaper.SetTrackSelected(track, true)

(if that's a bug, please don't fix it :P)

So, if it's possible to add, please consider adding it.

[JustSayin]

Originally Posted by schwa

The issue or bug in this case is that the undo states are not labeled correctly.

...

Occasionally, an action might change parts of the project state but not update the undo history completely. That's a bug, and we fix actions like that when we come across them. But when it happens, the latent or pending undo state is included in the next undo point that includes the same kinds of changes as the latent ones.

Thank you @Schwa for this detailed explanation. So, just to be clear, while the internal state of REAPER has not been corrupted, the reports available to users using ReaScript API commands to access Undo History are incorrect in the sense that they indicate state has changed in some instances when it has not, e.g. the "ReaScript: Run" example of this thread.

[schwa]

Originally Posted by JustSayin

Thank you @Schwa for this detailed explanation. So, just to be clear, while the internal state of REAPER has not been corrupted, the reports available to users using ReaScript API commands to access Undo History are incorrect in the sense that they indicate state has changed in some instances when it has not, e.g. the "ReaScript: Run" example of this thread.

No. The undo entries each represent a change in state from the previous undo entry. The issue is that an undo entry labeled "ReaScript: Run" may in fact include state changes that properly should have been included in an earlier undo point.

[JustSayin]

Originally Posted by schwa

No. The undo entries each represent a change in state from the previous undo entry. The issue is that an undo entry labeled "ReaScript: Run" may in fact include state changes that properly should have been included in an earlier undo point.

If that were true, then undoing the "ReaScript: Run" in the example given should cause a state change, and it does not.

[FeedTheCat]

Originally Posted by JustSayin

If that were true, then undoing the "ReaScript: Run" in the example given should cause a state change, and it does not.

It does Mr. Cohler... right click on the undo list entry > Undo state information.

[JustSayin]

In the example given at the top of this thread, there is just one track in the project. No items, no envelopes, no FX, no markers, nothing...

If you examine the track state chunk using

reaper.GetTrackStateChunk

before and after the "ReaScript: Run" there are no changes.

[FeedTheCat]

Originally Posted by JustSayin

In the example given at the top of this thread, there is just one track in the project. No items, no envelopes, no FX, no markers, nothing...

If you examine the track state chunk using

reaper.GetTrackStateChunk

before and after the "ReaScript: Run" there are no changes.

Maybe the latent change that causes this was a project state change, not a track state change. Again, check the "Undo state information" to see what caused it.

Btw, in the latest dev version, the above example does not create an undo point here.

[X-Raym]

@JustSayin

So, just to be clear, while the internal state of REAPER has not been corrupted,

Everyone here has call out your rudeness. It would be advised that you don't just ignore these feedbacks has if you were alone in this discussion. Making apologies is socially welcome, especially now that you seem to understand the point I was trying to explain you. Just saying...

[JustSayin]

Originally Posted by JustSayin

In the example given at the top of this thread, there is just one track in the project. No items, no envelopes, no FX, no markers, nothing...

If you examine the track state chunk using

reaper.GetTrackStateChunk

before and after the "ReaScript: Run" there are no changes.