DP11 Barely Usable for Surround Projects [Again]

[dix]

I'm having major stability issues with even the simplest 5.1 projects in DP11 (all versions) on my M1 Max MBP. DP starts up no problem, but 5.1 projects will usually crash on Open. Eventually they launch after several tries, but will crash if I assign Auxs to 5.1 busses, or reassign outputs to 5.1 busses, or even instantiate plugins on 5.1 tracks. The same projects are stable [EDIT: Now that I've narrowed this down I've discovered this also happens on the cMP not just on M1 as I thought] in DP10 on the M1 MBP (I'm not even sure DP10 is supported on Monterey on an M1).

I've tried everything I can think of to stabilize the projects, including Loading the projects, rebuilding the bundle, eliminating plugins. Even projects with no Rosetta plugins crash, but again these are really simple projects with just a few tracks and plugins. Stereo projects without surround busses and outputs are rock solid, but if I try to convert surround projects to stereo by eliminating the 5.1 busses and outputs (so I can at least work on them) they remain unstable - as if they'd been corrupted somehow.

Fortunately good old DP10 seems to be working fine (and simpler than using the cMP for just certain projects), but I have some much larger surround projects on the horizon that I'd, of course, prefer to do in DP11.

Any ideas? Is anyone working in surround in DP11 without any issues?

[mikehalloran]

DP 10 works; 11 doesn't. Hopefully, MOTU will be able to identify the problem or confirm a bug and fix it.

[dix]

Yeah. TechLink submitted with Crash Logs and crashy project file. Unfortunately projects seem to start out okay, so I can’t really give them instructions to recreate the issue.

[dix]

Eureka! After hours of troubleshooting I discovered that this seems to be a volume automation bug with 5.1 tracks.

DP11 crashes 100% of the time if any track containing volume automation, that is assigned to a 5.1 output or buss, is sent via an aux send to another 5.1 bus or output. At least now I have a workaround, which is to automate volume with a VCA, but that's far from ideal.

If someone with an M1 Mac could please try this operation and confirm I'd appreciate it.

Thanks!

[dix]

MOTU support replied with a short message saying they could reproduce this bug on a Windows machine. No mention of M1 or Intel, but at least it's progress.

I'd still appreciate it if someone could please take a minute to confirm. Alls you need to do is create a 5.1 Output and a 5.1 Buss on any project (just make sure you Save before you do it, if you try it on a current open project).

1: In any project that has a 5.1 output and buss, assign any track to a 5.1 output or buss
2: Write volume automation on that track
3: Assign a send of that track to a 5.1 buss or output

#3 crashes DP11 every time on my system.

If this is happening for everyone I'd have characterize it as a major bug with DP11. Obviously volume automation is crucial to any project.

[James Steele]

MOTU support replied with a short message saying they could reproduce this bug on a Windows machine. No mention of M1 or Intel, but at least it's progress.

I'd still appreciate it if someone could please take a minute to confirm. Alls you need to do is create a 5.1 Output and a 5.1 Buss on any project (just make sure you Save before you do it, if you try it on a current open project).

1: In any project that has a 5.1 output and buss, assign any track to a 5.1 output or buss
2: Write volume automation on that track
3: Assign a send of that track to a 5.1 buss or output

#3 crashes DP11 every time on my system.

If this is happening for everyone I'd have characterize it as a major bug with DP11. Obviously volume automation is crucial to any project.

I would try it, but I currently don't have an interface and don't think I can set that up until I have one. Having to ditch my old PCIe stuff for the Mac Studio.

[dix]

Thanks James. Yeah, it'd be complicated to check out for anyone without multichannel I/O. Hopefully another MNer can give it a go.

[pencilina]

I can't check this particular bug right now as of a year ago two of the surround panners are definitely, confirmed by motu, broken (and have been for the last 5 or so years) so even if you could get it working you might have a hard time mixing in 5.1.....

[dix]

I can't check this particular bug right now as of a year ago two of the surround panners are definitely, confirmed by motu, broken (and have been for the last 5 or so years) so even if you could get it working you might have a hard time mixing in 5.1.....

Hmm. I mixed many surround projects with DP9 and 10, so I'm not sure if I experienced the panner issue you're having. However, I now see that in DP11 surround panning automation does cause DP to beachball indefinitely if you try to use a Send to send to a 5.1 Aux - so essentially the same bug. Is this surround panner bug you're experiencing, pencilina?

[dix]

I’m getting a little frustrated with this situation. Apart from one sentence from MOTU support I’ve gotten nothing. They haven’t followed up or responded to subsequent questions. Frankly, MN hasn’t been too helpful either. There used to be a handful of people here that used DP in surround, but now, apparently, I’m the only one. Not to sound dramatic, but I’m seriously considering other DAWs. I’ve made my living with this app for over 20 years, but my practice increasingly revolves around immersive mixing (kind of trend these days in case no one noticed). If MOTU isn’t going to support the current level of surround implementation I’ll have to move on. Who knows, maybe the big DP Atmos surround update is right around the corner, but the current tools haven’t been updated for over a decade, and are currently broken….I think! Since I get anyone to confirm here, or on FB I can’t be certain.

Feel free to move this thread to Rant forum, James. That’s essentially where I’m at. It’s not getting much attention here anyway.

[James Steele]

I have it on pretty good authority that this bug you’re talking about with automation is going to be fixed in an update that’s not too far off.

[Michael Canavan]

What James said, I'm frustrated as well, a few nasty bugs emerged in DP 11.11, (MPE does not record is a big one), and although I wish they fixed them yesterday, a beta tester said that without breaking his NDA that he was pretty sure a fix is coming within the next couple weeks.

You'll probably get Atmos support before I get proper stop buttons on clips in the Clips window, or DP supports REX on Apple Silicon.

[dix]

Maybe I’m just late to the party. I couldn’t find any other reports about this automation bug on MN, but if it’s a known issue with a fix in the pipeline that is great news! But If that is true someone should probably tell MOTU tech support, who only told me the issue was being forwarded to the developers as a Windows problem (?) ….normally support is direct and forthright about known issues. Instead they just stopped responding to the TechLink. Not cool.

[HCMarkus]

Immediate Crash Confirmed Dix


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

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

Date/Time: 2022-08-22 13:20:35.6330 -0700
OS Version: macOS 12.4 (21F79)
Report Version: 12
Anonymous UUID: CE638A10-8E36-F1A3-7C6E-EE982DF8B0D3


Time Awake Since Boot: 12000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010
Exception Codes: 0x0000000000000001, 0x0000000000000010
Exception Note: EXC_CORPSE_NOTIFY

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

VM Region Info: 0x10 is not in any region. Bytes before following region: 105553518919664
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
MALLOC_NANO (reserved) 600018000000-600020000000 [128.0M] rw-/rwx SM=NUL ...(unallocated)

[dix]

Yay! ...Which is to say, yay I'm glad have this bug confirmed finally! I'm still not entirely sure James and Michael's intel on an upcoming bug-fix is for this particular bug, but at least I'm now sure it is reproducible on a Mac.

I get this exact same crash report every time. It's that gd EXC_BAD_ACCESS (SIGSEGV) that's the problem obviously. SIGSEGVs are the worst. ...but really, the fact that we're seeing the exact same crash report does tell me something.

Thanks so much HC. I really appreciate you taking the time to help me out. I did find a workaround that might be helpful: If you disable the surround track with automation before you assign the send DP doesn't crash, and doesn't crash on reenable.

Thanks again!