Any loaded instance of Realearn causes a project loaded immediately after launching Reaper to show as modified

[faldurn]

In some repeatable circumstances a subsequent abort of Reaper can be triggered.

Environment:
ReaLearn v2.9.1/x86_64 rev 9a2582 (2021-05-16 10:18:22 UTC)
Reaper v6.32 (win10)

The bug may possibly be related to a recent Reaper update (2 of which have occurred since July 6, 2021).

The easiest way to replicate the problem is to insert an instance of ReaLearn in Monitoring FX, then exit Reaper. It is not necessary to add an input or any mappings. Then relaunch Reaper, open any existing project, and it will show immediately as modified (without any undo history). An instance of ReaLearn previously saved on the Master track or any other track of the loaded project has the same effect. Subsequent opening of another project without relaunching Reaper will not result in the incorrect modified status.

With one of my projects (only when the incorrect modified status is showing), initiating play results in an abort of Reaper after playing 1.75 bars, but first saving the project to clear the incorrect modified status prevents the abort. The abort only seems to occur if the loaded ReaLearn instance has input and mappings. I have yet to assess whether the Reaper abort might involve a specific VSTi unique to this project in combination with the incorrect modified status.

[helgoboss]

The "show as modified" thing is something I've observed for some time already but it didn't bother me. However, good that there's an issue now.

I doubt that it's connected to any REAPER crashes though. If you can reproduce the crash with ReaLearn and REAPER stock plug-ins, let me know.

[faldurn]

My presumption of a causal connection between the modified status and the Reaper abort is based on the following observations:

The abort only occurs if the modified status is showing. This suggests to me that Reaper panics about an inconsistency in internal flags. Saving the project appears to clear the presumed inconsistency. Without saving, other actions such as playing a blank part of the project also seem to prevent the abort. The abort also only seems to occur when ReaLearn has active mappings, thus the modified status by itself is not enough to trigger the problem.

As soon as I can manage, I'll try to create a minimal Reaper project and minimal ReaLearn preset to replicate the crash conditions.

Thanks for your enlightened design and implementation that opens the door to significant new paradigms in music creation.

[faldurn]

My apologies. This might teach me to be more thorough in designing and documenting my tests:

I've been able to replicate the Reaper crash without any instance of ReaLearn loaded. ReaLearn is innocent.