Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
faldurn opened this issue Jul 20, 2021 · 3 comments
Labels
bug Something isn't working low priority

Comments

@faldurn
Copy link

faldurn commented Jul 20, 2021

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
Copy link
Owner

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.

@helgoboss helgoboss added bug Something isn't working low priority labels Jul 21, 2021
@faldurn
Copy link
Author

faldurn commented Jul 22, 2021

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
Copy link
Author

faldurn commented Jul 22, 2021

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.

helgoboss added a commit that referenced this issue Nov 22, 2021
#482 Reliably memorize changes if ReaLearn is on monitoring FX chain
#407 Don't mark project dirty on load
helgoboss added a commit that referenced this issue Nov 27, 2021
#482 Reliably memorize changes if ReaLearn is on monitoring FX chain
#407 Don't mark project dirty on load
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working low priority
Projects
None yet
Development

No branches or pull requests

2 participants