ReaEQ is not idempotent! Please PLEASE fix.

[tehsux0r]

ReaEQ instances change their Base64 data content on *every* save even when nothing has changed. Because ReaEQ is utterly ubiquitous in my projects, this causes me endless time-consuming headaches when trying to merge two copies of the same project worked on with different computers. Is there any good reason why this happens or is there just an unnecessary datestamp of some sort embedded in ReaEQ's data?

[schwa]

I don't think that's accurate. The state contains elements that you may not be expecting, like the UI size, but it's not random.

[tehsux0r]

Thanks for the quick reply.

Just to be fair, I didn't claim it was random, just unnecessary.

Unless I'm missing something, there shouldn't be a UI size in individual plugins' states because it's implied by the containing FX window. I could understand if some aspect of the plugin UI were resizeable or pane-based, but AFAICT ReaEQ has no such facility; its UI layout seems to be determined entirely by the available space in the FX window.

At any rate, I'm not in the habit of moving/resizing FX windows very often at all. To prove my point, I just did the following:

- open a project
- open an FX window containing only a ReaEQ instance
- File->Save the project and close REAPER
- copy the RPP file to a new name as a control
- reopen REAPER and the original RPP file
- File->Save and quit again without doing ANYTHING else
- compare the two files

I've attached a screenshot of the resulting diff. Obviously the REAPER_PROJECT change might have a good reason to be there, but all three ReaEQ instances in the project resaved different data despite me not touching the UI for any of them and not even having two of the UIs open.

[tehsux0r]

I just did the following to prove that this problem survives to the latest release:

- download and install REAPER v6.61, Windows, x64 from the website
- do a portable install
- rename the bundled ReaEQ.dll to ReaEQ.dllx to prove that that's the one this install is using
- start REAPER and load any project

REAPER protested about ReaEQ being referenced but missing. I then renamed the plugin back and repeated the test procedure given above. Once again, the ReaEQ instances all resaved changed data despite the project literally not being touched before resave.

[nofish]

Originally Posted by tehsux0r

- open a project
- open an FX window containing only a ReaEQ instance
- File->Save the project and close REAPER
- copy the RPP file to a new name as a control
- reopen REAPER and the original RPP file
- File->Save and quit again without doing ANYTHING else
- compare the two files

I've attached a screenshot of the resulting diff. Obviously the REAPER_PROJECT change might have a good reason to be there, but all three ReaEQ instances in the project resaved different data despite me not touching the UI for any of them and not even having two of the UIs open.

Justin/schwa can probably tell you what exactly changed in ReaEQ in your test but I can say I tried above and for me the only thing that changed is the REAPER_PROJECT data, everything else stayed the same, including ReaEQ data.

[Justin]

There was a rounding error that could occur when loading state, but rest assured the significance of that rounding error was at approximately -320dB, which means even if the error occurred every time (which it doesn't), you could load/save 1000 times with this error and the cumulative error would still be -260dB, or a million times for -200dB...

[tehsux0r]

Originally Posted by Justin

There was a rounding error that could occur when loading state, but rest assured the significance of that rounding error was at approximately -320dB, which means even if the error occurred every time (which it doesn't), you could load/save 1000 times with this error and the cumulative error would still be -260dB, or a million times for -200dB...

Hey Justin. Before I go on, I'm a 20+-year C++ programmer and my mission from about 1999 was to write the best, fastest DAW. I tried REAPER in 2007 and saw the way you'd made all the design decisions, and it wasn't long before I crossed that mission off my list! Thanks so much for making REAPER happen.

In response, I never thought for a moment that it would be significant (little is with FP64 unless you're doing DFTs!); it's just that every unnecessary single-bit error is more noise in the project changes, and since the plugin-state format's binary I have to take those changes seriously in case something significant *was* done. These aren't always my own projects, and I've spent the last 10+ years seeing spurious changes every time I save. I don't know why nofish couldn't replicate it, but it's extremely consistent for me. If it helps, I'm on W10-64.

I know all the reasons not to fix something like this, but with home recording becoming the norm, everyone's working on multiple computers now, and whether version-controlling the project or just using sync tools to move between machines, every conflict costs precious time because I can't always remember every knob I touched in a session.

Despite my very best efforts, I still occasionally forget to sync before/after working, and this latest one cost me about an hour to resolve because of all the noise, so I decided to put in the effort to investigate and report it at long last.

Let me know if there's anything I can try to isolate the problem further for you.

[schwa]

This issue should be fixed in the currently available 6.62 release candidate builds.

https://forum.cockos.com/forumdisplay.php?f=37

[tehsux0r]

Originally Posted by schwa

This issue should be fixed in the currently available 6.62 release candidate builds.

https://forum.cockos.com/forumdisplay.php?f=37

I redid the test on 6.61 to verify the previous behaviour, and then tried 6.62RC2 and had to repeat the test because it seemed too good to be true. I don't know who did what but ALL the spurious diff noise on all the plugin states is gone! This is a game-changer for me and those I do tech support for. Many blessings upon your houses.