doodles wrote:
Hey FM! This is why I said I keep meaning to start a separate thread, as don't want to hijack everyone else's...
Am in middle of soundtrack at the mo, so no time to go into detail, but in short. 3 computers with 32 gigs of samples in VE Pro on each, Main DP rig running about 30 or so VE Pro plugs, each running 16 MIDI channels. So that's my go-to template. Need all tracks printed separately to take for final mixes. Obviously don't use all MIDI tracks, but would say that an average orchestral and beats q would have about 60 or so tracks. DP crashes (memory prob - Im on 7.24) when trying to freeze too many tracks at once. So even if you managed to freeze 6 or 7 at a time, it takes ages. 100 mins of score times 60 -80 tracks a q = lots of time. If there was a "freeze all at once" button it would be amazing! I know I could set up template with a gazillion auxes for ve pro, but not realistic with this many tracks in template.
all advice welcome, but will get into proper thread about this once score is finished in a month or 2!
Hi, Doodles.
Thanks for clarifying, but I must confess I really can't see what the problem is...
My template is quite large too, and it never takes me longer than the duration of the cue to print all my MIDI tracks individually.
Can't you just print them in real time? You just need to set up some smart routing tricks, but it's totally doable. Why do you insist on using Freeze? Real time printing gives you the same results, only faster, better, and more reliably.
It seems that there have been mainly 2 issues in this thread:
1.- That Freezing is not faster-than-realtime
2.- That DP crashes when freezing more than a few tracks at the same time.
For 1, that's the way it is. It is a real time process and one can not expect it to go any faster (as opposed to BTD, for the reasons I've outlined up-thread).
For 2, THAT is an issue. DP should be able to freeze 3, 15, or 100 tracks at the same time with no problems at all.
Doodles, this seems to be your one and real problem, correct? Otherwise, if it worked as it should, you'd be happily freezing away all your tracks with no wasted time, yes?
If so, MOTU needs to know about this, because it should not be happening at all.
Also, if you take into account this other disturbing freezing-realted thread, MOTU must really roll up their sleeves and find out what is going on with the Freeze command.
Basically, people are seeing crashes when bouncing multiple tracks at the same time, AND other users are experiencing totally inconsistent timing issues when freezing, according to this thread:
http://www.motunation.com/forum/viewtop ... =1&t=53597
THAT I find very disturbing. I never trusted BTD or freezing, and this seems to only confirm my suspicions that these methods are not always reliable and are prone to timing/phasing issues.
MOTU?????
MIDI Life Crisis wrote:
Also, given that freezing takes at least as long as realtime in any instance I've seen personally, freezing makes little sense. If I am understanding the reason for it at all, it's to basically bounce the audio but w/o FX plugs. Maybe someone could clarify (I think FM already did but can't find it) that I understand that correctly.
Some members seemed a bit confused between bouncing and freezing.
Basically, freezing works AT THE TRACK LEVEL. It'll print the track's automation and plugins, but
it will NOT print anything that was delivered via sends. This means no reverb, no delay, and no automation/plugins in any submix or stem aux tracks.
Bouncing, OTOH, will include all of that, providing that the right tracks are play-enabled. But doing this track by track would not be efficient or desirable at all. This is not BTD's
Raison d'être. BTD was designed to "merge" or print more than one track at a time (i.e., your final mix, or stems).