Bounce to disk: Dropouts

[daniel.sneed]

I am NOT an audio software writer, but I'm stumped that bounce to disk may become less robust than realtime playback or recording.
BTD can take as much time as it needs to perform any task, while playback has to complete everything in a finite time window.
But that's just me?

[Phil O]

...that back and forth bus re-assigning thing, unnecessary deleting extra audio tracks and exporting routine are no good at all in my workflow...

Sounds like you're doing things the hard way. When I start a something new, I have a bus called mix in all of my templates. All output to be mixed is assigned to this bus. An Aux track (named Monitors, also part of the template) has mix as its input, and my main-out to monitors as its output. This Aux serves as my monitors' volume control. I also have an empty stereo track that will be used for the bounce (input set to mix, track name is song's title). When the time comes to bounce, there's no re-assigning involved. I just record arm the stereo track and hit record. Done. No exporting, re-assigning, deleting files or anything else. The newly created Stereo file is named appropriately and is in the project's audio folder. Just done!

Phil

[bayswater]

Thanx, Phil, but that back and forth bus re-assigning thing, unnecessary deleting extra audio tracks and exporting routine are no good at all in my workflow.
Specially when on a dead line with many different releases of a multiple tracks project (i.e. dance show).
Please, Motu, bring us back reliable BTD.

Reliable BTD, yes, but in the meantime, there really isn't any back and forth if you set up your template. I think FM has the most complete description, but basically, it involves having the routing set up so whatever you will have to bounce at the end becomes an Audio track, hidden in a Folder if you like, and grouped. Monitoring is via these very Audio tracks with the "blue button" on, or via an Aux prior to the Audio track. When things are ready to bounce, click record on one of these tracks, and do a pass, and it's done.

[daniel.sneed]

Ok, Bay, thanks for your advice.
I'll give some time to get it running and see how it fits.

[Maxxy]

Hi there

It's interesting you suspect Ozone... I hadn't got to that thought... although it certainly adds so much delay on the Master that it always needs to come off if you need to go back to MIDI inputting

I can't speak to huge numbers of MIDI tracks as you have but...

What has worked for me is to clean up all the audio tracks .... by merging each track into continuous files.... it seems to me that all the edits one may make on the audio tracks just make it more likely that the bounce may stutter at some point. Any track might have many edits... edge, position shift, SB fades, pitch correction, comping etc... but I suspect clip volume changes particularly

So before bouncing I'll copy all the audio tracks to a new take each ( so that I can return to edits later if necessary ) and then merge the whole lot. .. Apart from looking neater and, I believe, making bouncing easier for DP... it also helps bring a certain stamp of finality to the project ( :

Only downside for me is that the client(s) has no idea how much work you did to have him sing in time and on pitch ( :

HTH

Maxxy

[Maxxy]

Oh and as I believe has been stated earlier.... try to make sure there is no CPU, port or bus activity in the background that might cause internal interruption during the bounce.... e.g. file copying, file formatting, network traffic etc...

Just have the computer be basically idle while it is bouncing... and you sit there patiently or go get some fresh air

Close all windows except for the TO and Mixing Window... there was a time when the SE window was a suspect for tripping things up.... obviously close all Plug-Ins

Check for for duplicate (confused) bussing as can happen.... clear out any duplicates in Bundles

Sorry this doesn't address your multi-VI and large track count bounce problem directly ... but I have found these strategies to enable me to generally have confidence in BTD... at least for work in progress stuff ... (which was not the case there for a couple of years)...

Of course anything going out needs to be checked...

there are a few members here who remain dismissive of the whole concept of BTD...probably through too many letdowns.... I think that's a shame... we need it to work reliably... and for me it pretty well does

It saves time and prevents the client from umming and aghing at the end of the day and forcing endless restarts

CD burning though is another story.... I got so badly put off that I haven't been game enough to try it for a few years ) : ... fortunately there's not much call for them now

Thanks for listening

[daniel.sneed]

Thanx Phil O, Bayswater and Maxxy for all your suggestions.
DP9 and next month new computer may solve the case. If they do not, I'll have good options to go.

[EMRR]

I have nothing much useful to add, maybe some perspective.

I've never had BTD fail, but I don't use it much other than the occasional quick rough mix.

The clients never seem to mind hearing themselves again, especially when they are aware the mix has to run realtime to pass through all the analog hardware they are usually excited about.

On the G5 I finally retired last year BTD was pretty much real time anyway, AND you didn't get to hear it. When you don't get to hear it, you always have to do QC in real time again, not that you shouldn't do that anyway.