ReaBlink conflicts DrivenByMoss4Reaper

[wallacewinfrey]

I'm using Reaper 6.43 on MacOS 11.6.1, using the latest commit of ReaBlink, fd1b3e531fb38cd476b9490ca878cd20743d0d82.

After building reaper_reablink-x86_64.dylib, and moving it into place at ~/Library/Application Support/REAPER/UserPlugins/, I then add the ReaBlink lua scripts to my Action List.

After selecting & running ReaBlink_Monitor.lua I get the ReaBlink Monitor window. Regardless of whether or not Reaper is master or puppet, or when the designation was set (I tried adding reaper.Blink_SetMaster(true) to the ReaBlink_Monitor.lua script as suggested in the Reaper forums), Reaper will successfully start & change BPM without issue.

However, the moment Reaper's transport is stopped, whether by pressing Stop in Reaper's transport bar, running the ReaBlink_StartStop.lua Action script, or pressing stop in a Link-ed application, Reaper will suddenly close. This happens regardless of whether Reaper is the only participant in the Link session, or one among many.

I get the exact same behavior when using the provided, pre-built reaper_reablink-arm64-x86_64.dylib plugin.

Here's an example of the crash output I get when this happens: https://pastebin.com/raw/TBVPrPqY

[ak5k]

Does this happen when you use REAPER Start/Stop transport command (spacebar by default)? If not, then it should be fixed in ReaBlink v0.4.1 release.

EDIT:

Or this ReaBlink v0.4.2 release.

[wallacewinfrey]

Apologies for not following up more quickly, but I tried both the 0.4.1 & 0.4.2 releases, as well as doing a pull from the main branch and building from the most recent commit, 0158d3ac92d0955edf505ce8ad9b2b22a8699d16, and I'm getting the same behavior. Let me know if I can provide any other debugging information.

[ak5k]

Hi! Unfortunately I'm unable to replicate the issue. Tested with clean install on macOS 11.5.2. Once you've enabled ReaBlink Monitor, you should not need to use any of the helper scripsts for basic operation; ReaBlink captures native transport start/stop commands and native actions for increasing/decreasing tempo by 1.

The crash could be a result of some specific Transport related setting in REAPER, or perhaps a Transport related conflict with another extension or script. Or something Undo/Redo related.

If you can, test with a clean/separate REAPER install, and if it works, then gradually bring in your REAPER settings/scripts/extensions and see what breaks things. Although, that could require unreasonable amount of effort depending on your level of customization.

You could also try modifying the source code and make a custom build at least for debugging purposes. In file BlinkEngine.cpp commenting out lines 200 and 206 cause ReaBlink not to write any undo information; if the problem lies there. Commenting out line 320 will cause ReaBlink not to issue a transport stop (on Link session stop); this will break functionality, but if it survives, it will reveal if this is a transport control conflict.

[wallacewinfrey]

Eliminating plugins revealed that ReaBlink crashes Reaper when the DrivenByMoss plugin is present in the UserPlugins folder. It doesn't have to be enabled in Preferences->Control/OSC/web, or any controllers configured.

Just the presence of the drivenbymoss-libs folder, resources folder, java-runtime folder, and reaper_drivenbymoss.dylib dll in UserPlugins is enough to cause the crash when stop is initiated (by clicking the play button or by clicking the stop button while the transport is engaged).

[ak5k]

Can you try building commit 1119179e3f91c30cf7b02b9b2b2f94de9faafc6d and see if it survives DrivenByMoss4Reaper?

[wallacewinfrey]

It did not, unfortunately

[ak5k]

Ok, after installing DrivenByMoss I am able to replicate this, but I'm not entirely sure if this is within my scope/abilities to fix. The crash happens when ReaBlink commits undo state once playback is stopped. It would seem DrivenByMoss also does this, and these processes may conflict or perhaps end up in race condition. Commenting out/removing lines 200 and 206 in BlinkEngine.cpp and making new build is a workaround, but it might not be a permanent solution; without these, the undo list can be flooded with individual actions ReaBlink takes.

[ak5k]

Maybe v0.5.0-rc.1 available in releases works better? I was no longer able to replicate the issue with ReaBlink v0.5.0-rc.1, REAPER 6.47 and DrivenByMoss 15.5.0.

[brownkp]

Hello @ak5k, thank you for all the hard work developing this extension. Unfortunately, I'm encountering the same error as @wallacewinfrey with DrivenByMoss v21.2.0, Reaper v6.82, and ReaBlink v0.4.6 . I don't see v0.5.0-rc.1 in the Github releases. Was this release removed?

[ak5k]

Hello @ak5k, thank you for all the hard work developing this extension. Unfortunately, I'm encountering the same error as @wallacewinfrey with DrivenByMoss v21.2.0, Reaper v6.82, and ReaBlink v0.4.6 . I don't see v0.5.0-rc.1 in the Github releases. Was this release removed?

Hi! v0.4.6 calls stop function from main thread (like 0.5.0, which is no longer available), so there shouldn't be conflict with stop function. Or does crash occur in some other situation?

[brownkp]

I'm seeing crashes when using the play, pause, or stop buttons on the GUI in Reaper. It doesn't happen every time, but reliably happens after a couple start/stops. The clock is rock solid when it's playing and responds to tempo changes in linked software.

[ak5k]

I'm seeing crashes when using the play, pause, or stop buttons on the GUI in Reaper. It doesn't happen every time, but reliably happens after a couple start/stops. The clock is rock solid when it's playing and responds to tempo changes in linked software.

With current implementation I don't think this can be easily fixed. ReaBlink Master/Puppet modes issue (unsafely) transport commands from audio thread, to maintain accuracy and good sync. Running Master/Puppet modes on main/GUI thread wouldn't be that accurate, and would probably defeat the purpose. It is possible to disable Master/Puppet modes, and try to write some case specific workaround with ReaBlink API.