DP10.11 - Pausing multiple times during offline bounce

[Gabe S.]

So.......I thought we shook this problem in DP10, but it turns out.......it's baaaaaaaaack.

When I do an offline bounce, DP10 is pausing MULTIPLE times during a single bounce. The bounce should take around a minute. Instead, with the pauses, it takes over 10 minutes to bounce a single file. It absolutely destroys productivity........Instead of bouncing out stems in 10-15 minutes for a track, it takes well over an hour. A whole album is undoable like this.

It's so maddening, I've actually ditched the offline bounce and I'm just doing the bounces in realtime. It's faster than waiting for the pauses.......

I haven't reported it to MOTU yet, but I will. If you are experiencing the issue in DP10, please chime in here so we can get some idea if others are seeing it.

This kills productivity so badly, I may have to switch to ProTools for mastering, so I can bounce. Not thrilled about it, but I have ProTools here.

Thanks.
-gabe

[mikehalloran]

Not enough information.

Are you doing any conversion when you bounce such as to mp3?

You have home heavy duty VIs in your setup. Waves Mercury is pretty CPU intensive even in Kontakt 6.

I get this on rare occasions. If during a session, I relaunch the Finder and that fixes me up (Option Command escape, relaunch Finder). If I rebooted earlier that day, it never happens.

BTD uses RAM and disk access. Relaunching the Finder stops certain disk processes while rebooting clears RAM caches.

[bayswater]

Regardless of the VIs, CPU load, etc, there's the recurring experience that an off line bounce in DP can take longer than a real time bounce. This makes no sense. Because of this, I often record the DP project into DSP-Q, and I think others have been using hi-jack for the same purpose.

Has anyone posted a tech link?

[mhschmieder]

Definitely not enough info. I use the background mode because it's checked and I can't remember how it was done before this feature was added and don't fully understand the interaction of all of the new features in that window (a few experiments got different results from what I expected), so I decided to keep it simple. My bounces are almost instantaneous.

I'm going to guess you never record interim tracks or stems? I can see maybe having a gazillion plug-ins active during a bounce, and even some VI's and sample libraries, might cause different performance challenges based on different settings, but I don't work that way and am not about to switch.

Solely as context for my own excellent performance with this feature, and not meant to judge how others work, I always record every track, just as for stuff that is miked. And more often than not, now that we have VCA Group faders, I also buss those raw tracks with their primary processing and send effects (reverb, delay, etc.) to a project audio track that then becomes the basis for the next level of stem mixing or the final mix (increasingly the latter, as VCA Fader Groups mean I am now doing WAY less capturing of sub-group mixes).

I work this way due to being burnt too many times by crashes, incompatibilities, vendors and products that go away altogether, etc. So I rarely have much processing going on during a bounce of a final stem mix, and certainly no VI's or sample libraries at that point. Usually no send effects at that point either; just sometimes some bus-level compression, limiting, or EQ.

Having said that, I do heavily orchestrated work with lots of world instruments as well, so it is not uncommon for me to have a couple of dozen of final stems in my bounce! Still, I have by that point done most of the processing, and even stereo field positioning (using Vienna Suite's PowerPan Pro).

The funny thing is that bouncing MIDI from some of these gargantuan projects, is where I am more likely to see some lag during the bounce.

[Gabe S.]

I didn't go into heavy detail about my setup or the session because this is not a new problem. It's existed since DP9, so I was wondering if anyone else was seeing it in DP 10. But I will go into detail. And while typing this up tonight, I think I have at least some idea why it's happening.....at least some time.

I have built what I consider to be the highest spec Mac music workstation rig that I could conceive of. It is a 28-core Mac Pro with 96GB of RAM. The "external" project/sample drives are actually three non-raided 4TB NVME drives on a PCI card inside the computer---12TB on a single PCI card running at around 3000MB/sec. The computer is a BEAST. It scores over 20000 on the Geekbench 5 multi-core test. And the drives are the fastest thing I know of available to the general public. The audio interface is a MetricHalo ULN-8 upgraded to 3d/ethernet spec. MIDI from my controller keyboard is handled by a MOTU MIDITimePiece AV.

The software on the 28-core was a completely fresh install of all software. NO migrations or Time Machine restores or anything else. Every piece of software has been installed one-by-one from scratch. Only one version of DP has been installed: DP10.11.

The projects in question are not full MIDI production sessions with massive templates. They are mixing/mastering sessions with a bunch of stereo stems, and a very modest number of plugins---Waves, Sonnox and MOTU plugins with an occasional Altiverb or Valhalla verb. There's usually 10-15 plugins in the whole session. No MIDI. When I tell you the computer is bored by these sessions, that is a massive understatement. The 28 cores are largely sitting around yawning.

The routings in the sessions are not overly complex. The music stems go into one aux. The Percussion/FX stems go to another aux. Then those two auxes feed what I call a "Processing" aux where the chain of DSP plugins are. Then that is bussed to a master bus.

When I bounce, the session is 24bit/28k WAV files and I don't change the format. I don't import the bounce into the session.

I pulled up one of the sessions just now to make a video so you can see the problem for yourself. This video contains three pauses in a single bounce. The first pause is at :10 once I click the OK button to start the offline bounce. The screen recording does not show the spinning beachball. It just shows the cursor. So, the bounce wasn't even able to get going cleanly......It hangs for a minute. Then, it hangs a second time at 1:13 into the video. It hangs again for a minute. It pauses third time at 2:29. Again for one minute. And then finally finishes.

https://youtu.be/yZ8CTsMrVbM

Now, some sessions bounce totally fine without any issue. Others, you get through a couple stems and then it starts pausing......And then others like this one are screwed completely from the moment you click OK. You just give up and record the stems in realtime. It's faster.

Awhile ago, I did discover that having the Waves Dorrough plugin window open during an offline bounce caused DP to hang for 20 seconds at the end of a bounce. If you closed that window, that problem went away. I checked this session tonight and it did have a Dorrough plugin, but the window was not open. I deleted the Dorrough plugin and the bouncing was much better. But on one of the bounced, the bounce hung right at the end for a minute. It always seems to be almost exactly a one minute pause when it happens.

I've reported the Dorrough thing and the pausing thing to MOTU in the past, but I'll do it again.......if they're taking phone calls during these crazy virus times.......

(EDIT: this did not occur in DP8. On my previous Mac, I used to keep DP8 around so that when DP9 would pause during bounce, I would switch to DP8 and never get another pause. But I don't want to install DP8 on this new computer.)

[MIDI Life Crisis]

How many tracks are you bouncing? BTD even when bouncing to movies and different formats is always faster than realtime and pretty darn fast on my 2013 trashcan./fez. I rarely have more than a few dozen tracks and more often only a dozen. “Simplicity is the ultimate sophistication .” ~ Da Vinci

[Gabe S.]

How many tracks are you bouncing? BTD even when bouncing to movies and different formats is always faster than realtime and pretty darn fast on my 2013 trashcan./fez. I rarely have more than a few dozen tracks and more often only a dozen. “Simplicity is the ultimate sophistication .” ~ Da Vinci

Of course, BTD SHOULD always be faster---if DP doesn't pause in the middle of the bounce. Did you watch the video? It actually stops bouncing the stem---the progress bar literally freezes for a minute. And then the whole bounce takes almost 4 minutes instead of 30 seconds. The track is only 3 minutes long. It would be faster to record the stem in realtime......Having to wait upwards of 7 minutes sometimes for a bounce that should only take 30 seconds makes bouncing out a whole album a multi-day process instead of just taking a couple hours for the whole album. The last album I bounced out stems for had 160 final stereo mastered stems. If you have to wait 5 minutes per stem because DP keeps pausing during the bounce, that's over 13 hours of just bounce time, not including the time it takes to choose which tracks are being bounced and naming, etc. If the computer didn't pause, and only took 30 seconds per bounce, the bounce time for the whole album would be 1 hour and 20 minutes........we're talking a whole work day of time lost because DP keeps pausing in the middle of a bounce. (The realtime recording time if you had 160 stems that are 3 minutes each is 8 hours......that's why bouncing is so nice.) And that's just one album. I just produced stems for 5 albums.......

When I get a piece of music from a composer that needs a final mix and master, they deliver stems. I get anywhere from 6-50 stereo stems per piece of music. In these modern times, library music clients request finished stems quite often. But of course, I'm not going to give anyone 40 unmastered stems. That's not very practical. So, I create mastered stems for all our music. I have to condense 40 stems into what usually turns out to be 8-12 mastered stems. The important point here is that whatever is being bounced has to go through the mastering chain. I want a client to be able to line up all the stems, and then what they hear sounds 99% like the stereo master they heard. If you just give them a bunch of unmastered stems......that ain't going to sound like what they originally heard from the stereo master. And I doubt any regular client could master the stems to sound like what my master sounded like. And I can't just setup an entire track of stem bouncing and just walk away. I need to sit there and choose each bounce group.

So, in a given BTD, I may be bouncing only 1 stereo file through the mastering chain----for instance a choir stem. Or I could be selecting 8 stereo tracks of percussion and bouncing that through the mastering to generate a single stereo percussion stem.

If DP is working properly, my 28-core can do a bounce where I've selected 8 stereo files of a 3 minute track through the mastering chain and accomplish that in less than 30 seconds. If the track needs 9 stereo finished stems, that's less than 10 minutes of work to bounce out the entire composition into finished mastered stems. However, when the computer pauses and it takes 7 minutes just to get through one stem because it pauses 3 times like it did in that YouTube video, then it turns into a multi-day nightmare......whether I record the stems in realtime or I wait around for all the pausing.

[daniel.sneed]

Sorry for such little help but my experience with offline bounce has been mixed results, too.

Troubleshooting offline bounce has lead me to add an extra steps in my workflow.
That is to say, a mixing step :
Heavy multi track mixing tasks first, with very few mastering plugins. Only few Motu mastering plugins, such as MW Limiter. Creating what I call 24 bit *raw_mix* files, which are added to soundbite window.
Then a mastering step :
New Mastering sequence, with the *raw_mix* files, each in individual stereo tracks, with many heavy on CPU mastering plugins. Usually outputting 16 bit files.

Never seen a bounce hiccup since. Fingers crossed, though.

[Gabe S.]

Sorry for such little help but my experience with offline bounce has been mixed results, too.

Troubleshooting offline bounce has lead me to add an extra steps in my workflow.
That is to say, a mixing step :
Heavy multi track mixing tasks first, with very few mastering plugins. Only few Motu mastering plugins, such as MW Limiter. Creating what I call 24 bit *raw_mix* files, which are added to soundbite window.
Then a mastering step :
New Mastering sequence, with the *raw_mix* files, each in individual stereo tracks, with many heavy on CPU mastering plugins. Usually outputting 16 bit files.

Never seen a bounce hiccup since. Fingers crossed, though.

Thank you for your feedback.

I'm curious, if you don't have any pausing issues during bounce, what are the problems that you are experiencing with offline bouncing that is causing you to do extra steps?

[mhschmieder]

I meant to respond last night and forgot, due to a crash (outside DP) that lost my train of thought.

I'm wondering if any iZotope plug-ins could be causing this, as I am indeed observing this behaviour when using those plugs inside iZotope's RX app. I don't use their plug-ins inside DP anymore, but I am experiencing the exact same behaviour you have described, inside the RX app, when using Ozone and others. Recent updates seem very resource-heavy.

Possibly there are a few other isolated plug-ins a well, that might be specifically contributing, even if only one is active (as is the case in RX). And sometimes a particular plug-in may only perform poorly (as in freezing up here and there) with a specific hardware and OS update combination.

Anyway, I hope it gets sorted out. What you are experiencing does not seem right, especially given the overall context of your project setup.

[Gabe S.]

I meant to respond last night and forgot, due to a crash (outside DP) that lost my train of thought.

I'm wondering if any iZotope plug-ins could be causing this, as I am indeed observing this behaviour when using those plugs inside iZotope's RX app. I don't use their plug-ins inside DP anymore, but I am experiencing the exact same behaviour you have described, inside the RX app, when using Ozone and others. Recent updates seem very resource-heavy.

Possibly there are a few other isolated plug-ins a well, that might be specifically contributing, even if only one is active (as is the case in RX). And sometimes a particular plug-in may only perform poorly (as in freezing up here and there) with a specific hardware and OS update combination.

Anyway, I hope it gets sorted out. What you are experiencing does not seem right, especially given the overall context of your project setup.

I have Izotope RX and Insight plugins, but none are active in the sessions.

For me, Waves plugins have shown some oddities, like Dorrough when the plugin window is open.

I have to master a bunch of tracks soon. I'm going to do it in Pro Tools with all the same DSP plugins. Let's see how that goes. I know how to run ProTools very well because I mixed with it in the tv world for many years. I also own Cubase and Logic, although I don't know anything about either of those platforms. But I think I'm going to start experimenting with them this summer once I get past my deadlines.

[daniel.sneed]

[...]I'm curious, if you don't have any pausing issues during bounce, what are the problems that you are experiencing with offline bouncing that is causing you to do extra steps?

A pita. Problems were unpredictable: missing fades, missing crossfades, missing MIDI notes, missing first seconds of audio, and the like...
Very hard to spot on sometimes, for that was only a few seconds of bounce within a whole song mix. Tedious listening in fear of missing a little mistake, you know what a nightmare this can be.

Very hard to troubleshoot. Many attempts have lead to say the culprit was Izotope Ozone.
But AFAICT, high CPU load was involved any time there was a bounce mistake.

BTW, I am very satisfied, and I believe very trained and efficient, with Ozone, so the extra mastering step is ok to me.

As a second benefit, having a non mastered mix file has proved to be fine in my experience.
Changing mind about final global EQ and dynamic may show up from time to time.

[philbrown]

I have seen a LOT of the pause issue when bouncing to mp3 in 9.52, to the point I considered it unusable and did all my mp3 bounces in DSP-Quattro for the last few years. I just reinstalled 10.11 last week to give it another try so I'm not sure about this issue yet in 10.11. The couple of mp3 bounces I've done recently seemed OK but I really wasn't monitoring them closely. For the record, WAV bounces have been fine, in my case mp3 bounces were the only issue.

[Gabe S.]

[...]I'm curious, if you don't have any pausing issues during bounce, what are the problems that you are experiencing with offline bouncing that is causing you to do extra steps?

A pita. Problems were unpredictable: missing fades, missing crossfades, missing MIDI notes, missing first seconds of audio, and the like...
Very hard to spot on sometimes, for that was only a few seconds of bounce within a whole song mix. Tedious listening in fear of missing a little mistake, you know what a nightmare this can be.

Very hard to troubleshoot. Many attempts have lead to say the culprit was Izotope Ozone.
But AFAICT, high CPU load was involved any time there was a bounce mistake.

BTW, I am very satisfied, and I believe very trained and efficient, with Ozone, so the extra mastering step is ok to me.

As a second benefit, having a non mastered mix file has proved to be fine in my experience.
Changing mind about final global EQ and dynamic may show up from time to time.

Oh. Yikes. I'm not getting any of that.....at least that I know of.....just pauses. Now your'e really making me nervous.....haha

[Gabe S.]

So, a quick update of my latest experiences.

I took the same set of stems and loaded them into DP, Pro Tools and Cubase. I created the same session structure and the same plugins in each DAW.

First I can tell you I will not be using Cubase. For me, the workflow is bizarre and the bouncing was quite a bit slower than DP or ProTools. ProTools and DP bounce at similar speeds. Pro Tools actually tells you how much faster than realtime it's going. With this particular session setup, it's bouncing at 8.1x realtime.

I've committed to Pro Tools for this latest round of mixing/mastering and bouncing and I have to say, I've done over 30 cues and it's gone without a single issue. No pauses. No crashes. Totally stable. Bouncing out at 8x realtime. I'm sorry to say, but THIS is how it's SUPPOSED to go.

DP is struggling with something......probably a plugin. But I haven't spent the time to pinpoint it beyond DP not liking when the Waves Dorrough plugin window is open. And it's interesting that the pauses seem to consistently be almost EXACTLY 1 minute each time it pauses. C'mon......something is up.

Pro Tools has no issues with any plugins. And DP8 didn't either. It's worth mentioning again that I used to keep DP8 around just for bouncing because it had no issues. If I was bouncing in DP9 and I had pauses, I would quit DP9, load the session in DP8 and keep bouncing and all the pauses would magically disappear. But I refuse to load to DP8 on this brand new Mac Pro. I don't want to risk anymore potential conflicts with two versions of DP on the computer.

I'm not finished with this current round of mixing/mastering/bouncing yet. I'll report back when I'm done.