[FIXED] ReaScript API: GetSetProjectData_String for storing script state

[MonkeyBars]

Currently, there is nowhere to save custom script data outside the tracks in a project whose deltas are registered by the Undo History. Project ExtState, Project Info, Project Info Strings, and Master Track P_EXT are all outside the Undo History.

Many scripts need to track their special data's state in the project that updates along with the users' actions. Doing so in a hidden dummy track or item is a sloppy workaround prone to disastrous errors when users clean up their projects.

I propose a simple GetSetProjectData_String function that works like the rest of the GetSet functions, offering P_EXT and any other interesting parameters the Reaper devs deem may be useful to devs.

[MonkeyBars]

Found a decent workaround to store P_EXT values in the Master Track Tempo Envelope. It doesn't appear possible to deactivate it, so it seems like the perfect permanent place to store project data whose changes you want picked up by undo points.

[FeedTheCat]

+1

Originally Posted by MonkeyBars

Found a decent workaround to store P_EXT values in the Master Track Tempo Envelope. I doesn't appear possible to deactivate it, so it seems like the perfect permanent place to store project data whose changes you want picked up by undo points.

What a nice find! I'll definitely try this, sounds like a great workaround.

[MonkeyBars]

You're welcome, FTC! So glad the legendary dev of Update Utility can use this little finding!

I have been testing it and this solution appears to have solved the undo bugs that plagued my project before.

[FeedTheCat]

Originally Posted by MonkeyBars

You're welcome, FTC! So glad the legendary dev of Update Utility can use this little finding!

I have been testing it and this solution appears to have solved the undo bugs that plagued my project before.

Haha, not sure about my legend status This workaround seems to be really solid so far. I tried some stuff to break it (clearing the tempo envelope etc.) but I haven't found any downsides so far.

[Meo-Ada Mespotine]

Why not using ProjExtState? This sounds like tge thing you asked for?

[MonkeyBars]

Originally Posted by Meo-Ada Mespotine

Why not using ProjExtState? This sounds like tge thing you asked for?

Please read OP carefully

[Meo-Ada Mespotine]

And the undo-functions don't create an undo-point either? Like putting it between
https://mespotin.uber.space/Ultrasch...ndo_BeginBlock
and
https://mespotin.uber.space/Ultrasch...#Undo_EndBlock
?

If not, I'd rather consider this a bug.

[MonkeyBars]

Originally Posted by Meo-Ada Mespotine

And the undo-functions don't create an undo-point either?.

No they do not

[Meo-Ada Mespotine]

Found that too. I think, this should be considered as either a bug or oversight, as using the undo-functions for this should be the way to go for all the functions you mentioned.
Especially as they change the project.

So in my opinion, I wouldn't want to have another function, but have the functions you mentioned being supportable using the Undo-functions.

I might have an idea, that I'll check. Maybe a workaround is possible but I need to test it out first...
Basically something like, running a function, that changes track-selection, which is undo-function-compatible, might include changes to ProjExtStates too, when both done within the undo-functions.

I'll test it tonight to see, if my idea works or if it's rubbish.

[MonkeyBars]

Very interesting, but actually imo it's desirable to have both data types (persistent and undo-compatible) available to script devs for varied use cases.

[Meo-Ada Mespotine]

Well that would be easy:

Persistent, use the functions as of yet.

Undoable, put the function inside Undo_BeginBlock and Undo_EndBlock.

That way, you can decide yourself between persistent and undoable.

Especially, if you use different ids, like different section-key-combinations in ProjExtState, it should be easy to differentiate between undoable ProjExtStates and persistent ones.

Unless I missed something.

Haven't thought it through with the other functions, though, so I don't know, if they wouldn't work like that per design.

[Meo-Ada Mespotine]

No luck with my workaround idea as I couldn't trigger an undo-point for ProjExtStates, only for P_EXT on regular tracks.
But after thinking about it a little further, keeping the current behavior could be the better idea,
as some scripts might have functions like SetProjExtState inside of Undo_BeginBlock and Undo_EndBlock
under the assumption, that it never creates undo points. So they would break or at least behave
unexpected, if out of a sudden, undo would be supported for ProjExtStates.

But, I made another interesting find.

From your OP, I assume, that you tried to use P_EXT on the master-track to trigger an undo-point, just as it
does on normal tracks, but it doesn't.
The reason for this behavior is: P_EXT isn't supported on the master track itself in the first place, only
on envelopes of the master track(like in your workaround), from what I saw. The GetSetMediaTrackInfo_String is
confusing in that case, as it returns true when trying to set P_EXT on master track, even if it doesn't create
it and should return false instead.

So, I would propose something, that might help you get your wished behavior without hacks but with undo and a reliable data-location:
adding P_EXT support for the master track itself.

This would have several benefits:

1) The master track can't be deleted so all its P_EXTs are safe
2) P_EXT on other tracks already support UNDO-blocks optionally, so adding that to the master track is basically a
continuation of the P_EXT-behavior of regular tracks.
3) as this is a feature added, it will not break existing scripts, as no script expects P_EXT to work on master track, and
even if it did, it should know, that P_EXT could be made undoable using undo-functions and act accordingly.
If it doesn't, it should be considered a buggy script.
4) We don't need yet another function to store data into the project but rather use existing concepts and structures.
Which is also easier for scripters, who could be confused, why two functions, who basically do the same, exist, and
which one to use.

So adding P_EXT-support on the master-track could be your solution and might be easier to implement for the devs.
Unless the devs already considered the option and decided against it due some issues, back when they added P_EXT.

BTW: thanks for bringing this up. Will add to my API-docs the information surrounding the potential undo-problems,
so the information doesn't get lost in the forum's old-threads-nirvana.

[MonkeyBars]

Originally Posted by Meo-Ada Mespotine

The reason for this behavior is: P_EXT isn't supported on the master track itself in the first place, only
on envelopes of the master track(like in your workaround), from what I saw. The GetSetMediaTrackInfo_String is
confusing in that case, as it returns true when trying to set P_EXT on master track, even if it doesn't create
it and should return false instead.

Thanks so much for your extensive research!

However, what you report here is not what I found. Master Track P_EXT works just fine for me, but is outside the undo system – unlike its envelopes (which does make sense to me actually – of course all envelopes need to live in the undo system). I reported this here: https://forum.cockos.com/showpost.ph...7&postcount=30

[Meo-Ada Mespotine]

Hmm, that's odd.

Is it still available when you save, close and reopen the project?

If yes, then P_EXT isn't stored in projectfiles in the render-queue(which I used for my experiments) and would explain, why I observed something different.

But yeah, if it is, undo-capabilities for the master-track's P_EXT should be added then.
Especially for usecases like yours and consistency in behavior.

[MonkeyBars]

Originally Posted by Meo-Ada Mespotine

Is it still available when you save, close and reopen the project?

Ah that's a good point – very thorough! Confirmed that Master Track P_EXT does NOT save with the project. That's very strange to me – so is all P_EXT only available per project load??

I just tested the master tempo envelope P_EXT as well and it's GONE on project reload. That's a bug for sure imo.

Regular track P_EXT DOES save on project reload.

Bug report: https://forum.cockos.com/showthread.php?p=2504245

[MonkeyBars]

Update: This bug is already fixed in the current prerelease, 6.42+1107! What a crazy coincidence

[Meo-Ada Mespotine]

Nice.

Had the bugreport just finished XD