[7.24] Sends Stop Loading in Larger Projects with Send Routing on 7.24

[Vorticist]

I've encountered an issue in Reaper 7.24 affecting larger projects that use send routing between bus tracks. When loading these projects with effects set to online, some or all sends fail to load on higher-level buses. I’ve noticed this problem in twice in my mix sessions since updating to 7.24.

If this is linked to specific plugins, this might be hard to reproduce with my specific project file, but I feel confident that if you open a previously saved session with a good number of fx and sends, you’ll find some disappearing in version 7.24.

Steps to Reproduce:
1. Open the attached example RPP project file with effects set to online: https://www.dropbox.com/scl/fi/dxj0s...bvw33z482&dl=0
2. Observe that sends on higher-level buses stop loading at a specific, repeatable point during the project loading process.
3. Reload the project with effects set to offline and note that all sends load correctly.

Note that the issue occurs in projects with a large number of tracks and fairly extensive send routing.

Expected Behavior: All sends should load properly with the project, maintaining the intended routing, regardless of effects being online or offline, and irrespective of the project's size or routing complexity.

Actual Behavior: When effects are online, sends stop loading at a certain point during project loading, particularly on higher-level buses. This issue is observed in projects with extensive send routing and a high number of tracks/sends.

Details:
Reaper Version: 7.24 (64-bit)
Operating Systems:
Mac: macOS Ventura 13.6.1
Hardware:
Mac: M2 Max, 32 GB RAM
Plugins Involved:
A list of plugins used in the project is attached/included below.

Troubleshooting Steps Attempted:

Loading with Effects Offline:
All sends load correctly when the project is opened with effects set to offline.
Reverting to Reaper 7.22:
On Mac:
Reverting without restarting did not resolve the issue.
Restarting the machine after reverting to 7.22 resolved the issue.

Additional Information:

Below are screenshots showing some of the missing sends when the project is loaded with effects online vs offline:
- Sends load when FX offline:
- Sends not loading when FX online:
-Apologies for the large project file size, it does seem like this bug might be linked to the relative complexity
-Project plugin list attached below.
-No error messages or logs are generated when the issue occurs.

[Tone Ranger]

Funny, I opened a large session this morning that I'd been working on last night and a bunch of the sends at the end of the project were missing. I thought I may have deleted them by accident....guess that's not the case. Thanks for sharing!!

Reaper 7.24
Mac OS 12.7.6
2019 iMac 3.6 GHz 8 Core i9
128 GB RAM

I should note as well that the send routing is quite complex on this project (but no more complex than usual for me, first time this has been an issue).

[CAlexanderParra]

I reproduced it on the RPP provided and also on a different mix project of mine too. Has something to do with how reaper is opening FX I believe? I have other mixing projects that load up fine too.

My RPP with the same issue:
https://www.dropbox.com/scl/fi/1nln9...9ajmfudwk&dl=0


Reaper Version: 7.24 (64-bit)
Operating Systems:
Windows 10 Pro 22H2
Hardware: AMD Ryzen 9 5950X, 64GB Ram

[Tone Ranger]

Here's a link to my session that has the issue:

https://www.dropbox.com/scl/fi/8n3p4...lv5ih67xm&dl=0

It's definitely repeatable - but smaller sessions (with equally complex send routing) DO open fine.

I'm reverting to an earlier version of Reaper until it's resolved as well...

[schwa]

This is going to be difficult for us to debug if the behavior depends on the presence of a bunch of third party plugins. What would be ideal is a way to reproduce using only stock plugins, if that's possible.

Also a more specific description of what the failure state looks like would be helpful, like "the send from track X to track Y is not loaded."

[Justin]

Do you have any deferred scripts running?

We should have a development build available soon which may fix, your testing of that would be appreciated!

[Justin]

Can you try 7.24+dev1009, available at https://landoleet.org to see if that resolves this issue? Thanks!

[Tone Ranger]

Thanks so much for the quick response, Schwa and Justin!!

Justin - 7.24+dev1009 fixed the issue for me, my session opens fine using that version. Let me know if either of you need any more testing done, but whatever you did there worked. Thank you!!

[CAlexanderParra]

I closed all scripts and it didn't make a difference for the bug. New dev build works for me now though! Thanks Justin!

[Vorticist]

Seems to be working for me as well, I'll edit this at the end of the day if anything changes but back to work. Thanks Justin and schwa for the quick turnaround!

I'll try and up my test project game in the future for ya.

[akademie]

It seems like it was a serious bug corrupting the projects.

Justin, schwa, can we have more info why this started to happen in v7.24, please?
And does the fix taking care of the problem completely and reliably?

[Tone Ranger]

@akademie - in case you're worried about corrupting your sessions, this bug didn't damage my sessions at all. It was a bug with loading the session in that particular version of Reaper, when I rolled back to 7.22 or used the dev version the session opened just fine (even versions of the session that had been saved using the version of Reaper with the bug).

Just wanted to clarify that you don't have to worry about damaging your sessions! 🙂

[Justin]

Originally Posted by Tone Ranger

@akademie - in case you're worried about corrupting your sessions, this bug didn't damage my sessions at all. It was a bug with loading the session in that particular version of Reaper, when I rolled back to 7.22 or used the dev version the session opened just fine (even versions of the session that had been saved using the version of Reaper with the bug).

Just wanted to clarify that you don't have to worry about damaging your sessions! 🙂

Hmm are you sure about that? In theory if you save it with those sends gone, they should be gone (though saved in the undo history and any backup copies).

[Justin]

Originally Posted by akademie

It seems like it was a serious bug corrupting the projects.

Justin, schwa, can we have more info why this started to happen in v7.24, please?
And does the fix taking care of the problem completely and reliably?

From what I can tell, this is not a new bug, however there may be some changes in 7.23 which cause it to be more likely to occur.

The explanation is: when loading a project, each track's state is loaded, and it includes a list of receives. If the receive is from a track that is a higher index, that track doesn't exist yet, so it initializes the send but without a link to the track. Once the project is finished loading, it links all of those sends.

There is some code that, when updating the routing for a project, if the source track is not found, garbage collects the send. It's possible/likely that some plug-in or script (or combination of the two) is causing that garbage collection to happen prematurely, while the project is still loading. The fix in the current +dev build ensures that the send garbage collection does not happen until the project finishes loading.

I would still like to know the answer to the mechanism with which the plug-in (and what plug-in) is causing this issue, though. In general, it would be a plug-in on a track between/including the destination track and the source track. So for the screenshots above, track 3/4/5/6 really...

[akademie]

Justin, thank you very much for deep explanation. It's always good to know the mechanism of loading.

[Justin]

Users who have this problem: do you have preferences/buffering "allow on tracks in touch/latch/write automation mode" checked? If it isn't (it is by default), try checking it and see if that fixes.

If it doesn't -- do you have control surfaces enabled? If you disable all control surfaces, and use 7.24, does the issue persist?

[Tone Ranger]

Originally Posted by Justin

Hmm are you sure about that? In theory if you save it with those sends gone, they should be gone (though saved in the undo history and any backup copies).

You are absolutely right of course. I was sure I'd saved my session when the issue was happening and had it open okay in the dev build, but trying it again the sends aren't there in the saved version. Sorry about that!

Originally Posted by Justin

Users who have this problem: do you have preferences/buffering "allow on tracks in touch/latch/write automation mode" checked? If it isn't (it is by default), try checking it and see if that fixes.

If it doesn't -- do you have control surfaces enabled? If you disable all control surfaces, and use 7.24, does the issue persist?

The "allow on tracks..." setting IS checked in my preferences. Turning off my control surface (Presonus Faderport 16) and restarting Reaper didn't help the issue...is there another way to disable it without deleting the settings?

It looks like in the session I posted earlier that any tracks above track 78 that are routed to tracks much further down in the session lose their sends. The sends above track 78 that are routed to nearby tracks retain their sends. Hope that's helpful!

[Vorticist]

Originally Posted by Justin

Users who have this problem: do you have preferences/buffering "allow on tracks in touch/latch/write automation mode" checked? If it isn't (it is by default), try checking it and see if that fixes.

If it doesn't -- do you have control surfaces enabled? If you disable all control surfaces, and use 7.24, does the issue persist?

In my case, I did have "allow on tracks in touch/latch/write automation mode" checked already.

I had two control surfaces (Companion and DrivenByMoss), but removing them and restarting with 7.24 didn't change the behavior with the test project I have.

As far as the plugins on tracks 3-6 in the screenshots from my test session, I found that loading the project with FX offline in 7.24 and removing all the plugins from track 6 (the first track in the session that didn't load the proper sends), saving, then reloading with FX online caused the rest of the sends to load as expected!

So I narrowed it down, it seems like the culprit, at least in my case was SSL Native Channel Strip 2. Removing the other plugins on track 6 had no effect, but just removing that one plugin, saving, and reopening with FX online fixed the send loading behavior. I should note that I have the same plugin on other tracks in the same project where the sends loaded just fine.

[larryJ]

This resolved my problem with some sends lost in a huge project that has SSL CS2 fx in place. (Only happened when the vst3 was in the project.) Thank you for notifying me of this upcoming release.