Troubles with Offline Bouncing on DP 11.32

[AppleTwo]

Hi everyone.
I'm currently on DP 11.32 on Mac Sonoma 14.6 and M3 Max 16 core.

Has been a few days since I'm struggling with offline bouncing to disk.
Every time I try to bounce, DP just crashes.

I'm working on a very large template with multiple v-racks and dozens of chunks.
Apparently this is something specifically related to this template I'm working on as crashing never happens on any other projects.
But when I try to open an older version of the very same template, like one from 2 weeks back for instance, the bouncing crash never occurs.
Only in the very last file I saved a few days back, which is 100% identical to all other files version (except for containing more tracks), I experience 100% of crashes when I try to bounce to disk offline.
Issue doesn't happen when I try online bouncing.
Another case scenario is the following: I open an older version of the template file, then I launch the one which normally crashes without quitting DP, just by double clicking the newer project file... it launches, I try to bounce offline: it works.

When I then quit DP and just launch that very same latest file project, once it's properly loaded up, if I try to offline bounce: it crashes again.

If I try to do the same trick of opening an older version first, then launch the newere one, the session bounces perfectly without crashes.
Note: crashes never happens when I try online bouncing.

Needless to say, as a 20 year DP user, this is driving me nuts.

I'm attaching the crash log and the specific thread which is consistently the reason why I get those crashes.

Really hope you can help me out.
Thanks.


-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process: Digital Performer [15738]
Path: /Applications/Digital Performer.app/Contents/MacOS/Digital Performer
Identifier: com.motu.DigitalPerformer
Version: 11.32 (11.32)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501

Date/Time: 2025-02-24 10:55:01.8518 +0100
OS Version: macOS 14.6 (23G80)
Report Version: 12
Anonymous UUID: 4D9F1E6E-EDFC-7CAD-A499-882BF32DFEA0

Sleep/Wake UUID: 045377F7-11C3-4C39-8F7D-4C5798CE374E

Time Awake Since Boot: 92000 seconds
Time Since Wake: 11906 seconds

System Integrity Protection: enabled

Crashed Thread: 713 MOTU Worker Thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000120
Exception Codes: 0x0000000000000001, 0x0000000000000120

Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [15738]

VM Region Info: 0x120 is not in any region. Bytes before following region: 4304355040
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 1008f4000-1027fc000 [ 31.0M] r-x/r-x SM=COW /Applications/Digital Performer.app/Contents/MacOS/Digital Performer





CRASHED THREAD (always the same):
Thread 713 Crashed:: MOTU Worker Thread
0 MotuAudioSystem 0x103c9c070 MAS83148 + 13380
1 MotuAudioSystem 0x103cdd66c MAS83148 + 281152
2 MotuAudioSystem 0x103cdce8c MAS83148 + 279136
3 MotuAudioSystem 0x103ce23fc MAS83148 + 301008
4 MotuAudioSystem 0x103d42910 MasWriteStandardAutomatableSurroundSetting + 292708
5 MotuAudioSystem 0x103d42828 MasWriteStandardAutomatableSurroundSetting + 292476
6 libsystem_pthread.dylib 0x196cf9f94 _pthread_start + 136
7 libsystem_pthread.dylib 0x196cf4d34 thread_start + 8

[AppleTwo]

Quick update

I just installed the latest version of DP 11.34

Same crash happened but with a different error log:

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process: Digital Performer [20233]
Path: /Applications/Digital Performer.app/Contents/MacOS/Digital Performer
Identifier: com.motu.DigitalPerformer
Version: 11.34 (11.34)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
User ID: 501

Date/Time: 2025-02-24 18:56:19.7764 +0100
OS Version: macOS 14.6 (23G80)
Report Version: 12
Anonymous UUID: 4D9F1E6E-EDFC-7CAD-A499-882BF32DFEA0

Sleep/Wake UUID: 045377F7-11C3-4C39-8F7D-4C5798CE374E

Time Awake Since Boot: 120000 seconds
Time Since Wake: 40784 seconds

System Integrity Protection: enabled

Crashed Thread: 710 MOTU Worker Thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000120
Exception Codes: 0x0000000000000001, 0x0000000000000120

Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [20233]

VM Region Info: 0x120 is not in any region. Bytes before following region: 4369825504
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 104764000-106664000 [ 31.0M] r-x/r-x SM=COW /Applications/Digital Performer.app/Contents/MacOS/Digital Performer






Thread 710 Crashed:: MOTU Worker Thread
0 MotuAudioSystem 0x107f572d8 MasRampQueueUpdateHandler::UpdateRampStates(SampleRange&) + 648
1 MotuAudioSystem 0x107f9a8fc MasIOMgr::DoPrepareNextBuffer() + 1668
2 MotuAudioSystem 0x107f9a11c MasIOMgr::PrepareNextBuffer() + 152
3 MotuAudioSystem 0x107f9f61c MasMixdownOutputList::doAction() + 24
4 MotuAudioSystem 0x1080018e0 MotuWorkerThread::MotuWorkerThreadImpl::Run() + 220
5 MotuAudioSystem 0x1080017f8 MotuWorkerThread::MotuWorkerThreadImpl::ThreadFunc(void*) + 12
6 libsystem_pthread.dylib 0x196cf9f94 _pthread_start + 136
7 libsystem_pthread.dylib 0x196cf4d34 thread_start + 8

[James Steele]

Your best bet is probably to fill out a support ticket so at least someone at MOTU can look at the crash log. They’ll stand the best chance of figuring out what’s going on.

[mikehalloran]

Something is preventing this but the crash report isn't saying what/

Call MOTU Support. They can screen share and look at the Activity Monitor.

I would update to macOS 14.7 first. It fixed a number of bugs.

[AppleTwo]

Thank you guys.

I'm backupping everything and then I'll update to 14.7.4.

I'll share results as I get some.

[AppleTwo]

So everything is now up to date.

Same issue unfortunately: crash on offline bouncing.

I reckon it's something with a specific set of chunks because if I select an older chunk from the list, even within the very sampe template, the crash on offline bouncing never happens.

Also: I loaded other projects up, even from different templates and from different old productions, and the crash on bouncing is never happening.

So, from an empiric analysys, it looks to me there's some newer chunks in my template which conitains something that is bothering DP a lot.

Note: if I load an older chunk from the very same template, I try to bounce, there's no crash.
Once I tried that old chunk bounce successfully, if I switch to a newer chunk which was causing the crash right after launching the session (without closing the project), the latest chunk is not crashing anymore.

I'm puzzled.

[HCMarkus]

Ghost in the machine? Glad it decided to let you move forward. Strange things do occasionally happen with the bits and the bytes. When things get straightened out magically, it might be time to move on

Had you tried Loading the offending chance into a new project?

As you have noted, the emergency way to resolve the problem you encountered is to simply run a real-time pass during which you record to an Audio Track. This approach allows a confidence listen as it is going down. This is how I handle most of my mixes.

PS: Welcome to MOTUNation!

[James Steele]

Had you tried Loading the offending chance into a new project?

chunk, yes?

[HCMarkus]

Had you tried Loading the offending chance into a new project?

chunk, yes?

Yes. Thanks!

[MIDI Life Crisis]

I’d disable plugins. Xenon used to do this until it was updated. My bet is a plugin is misbehaving. More likely a processing rather than a VI plugin

[AppleTwo]

I’d disable plugins. Xenon used to do this until it was updated. My bet is a plugin is misbehaving. More likely a processing rather than a VI plugin

So that was also my original idea.
The point in my case is: I don't use plugins, per say, in the traditional way.
My session is a TV show scoring template, which requires a multiple v-rack configuration which is shared in common with all chunks.
Hence, all plugins, VI, and signal processing happen at v-rack level for all chunks.

The anomaly, in this case is: some chunks are unaffected by the offline boincing crash issue, whether some others are.

So the empiric fix for me was basically opening the session and trying to bounce the chunk starting from the newset to the oldest, until I found the first one in backwards order which didn't present the bouncing crash.

Then I duplicated that specific chunk, and kept scoring to picture by synching that old-new chunk.

As I said: it's an enormous project, one of those which would really make a case study on how DP can really shine in its whole glory in terms of setup complexity and flexibility.

Last year I scored another TV show which required over 160 music single titles, for over 2000 submixes.
No other DAW would have allowed me to handle the workflow the way DP does with chunks, simply because chunks are the only way to arrange multiple version of the very same cue without closing the project and being forced to load up an alternative setup all the time.

Unfortunately, like in this case, if for any reason a chunks is presenting some mysteyous issue, it's nearly undetectable.

The only thing I can see is the consustency in the crash log, which always happens on the very same thread all the time when I follow the following order:
- launch the template
- try to bounce from one of those 'corrupted' chunks

But if I now launch the session and just try to bounce the new-old chunk (which I doubled from the one was not crashing), that somehow works just fine and, if I then jump to another chunk (including any of those who used to trigger the crash party), now those are bouncing correctly.
Like if trying to bounce one of the uncorrupted chunks was somehow stabilising the bouncing process across the board.

So, since it's a paid project and clearly we can not afford to keep going troubleshooting indefinitely, I decided to keep working on the very same template simply using this empiric method of duplicating the chunk which is not presenting issues.

Also worth noticing that if I try to load up any of my templates, including those from the most glorious and stable version ever existed which lasted me for over 9 years straight, aka DP 9, despite the session running mostly in emulation on ARM due to the majority of those plugins being not even remotely compatible with M3 (those session are son of a hackintosh monster under a heavilty overclocked Intel i7) I can see there's no issues at all in bouncing.

So, I hope this gave some insight to those who will experience this type of issues.
Most users are just using DP for a single track, but those who are handling large templates with multiple v-racks and dozens of chinks will probably find this thread helpful.

[HCMarkus]

If you haven't already done so...

Your best bet is probably to fill out a support ticket so at least someone at MOTU can look at the crash log. They’ll stand the best chance of figuring out what’s going on.

[Jim]

I'm late to this, but I posted my own "constant crash on bounce" thread here a month or so ago.

I definitively tracked down my issue to several o DP's native plug-ins. If I remove them, the crashing ceases.

My crashes were caused by: MW Gate, MW EQ, all of the distortion pedals and all amp simulations.

The fix has just to get rid of all native DP plug-ins. I've got several third party options I can use instead.

Since this appears not to be a widespread issue, I've started to wonder if there isn't an incompatibility with effects I use in every mix. The FX I use on all my mixes are PSP Vintage Warmer, FabFilter Pro-Q 3, Valhalla Plate, Kontakt Vari-Comp. I use Kontakt Guitar Rig and Oxford Sonnox Inflator on many mixes, but not all.

I've also tracked crashing on bounce to a VI or two that was fixed by deleting the VI, and reinstantiating it - suggesting the instance got corrupted somehow.

One forum member speculated this may be an issue with Sequoia and ARM.

Since you wrote that you don't use plug-ins, my experience might not be at all helpful.

What you reported is that your projects are massive in scope, and based on my experience with NLEs (that are hosts for DAWs), the larger the project, the more chances of file or project corruption. The method you described of tracking it down is what I call "search and destroy" - gradually removing items (which can also be source media) until the crashing stops. That's what I do, too, and suggest to others who suffer the same challenges.