Freezing Audio tracks seems a very slow process...

For seeking technical help with Digital Performer and/or plug-ins on MacOS.

Moderator: James Steele

Forum rules
This forum is for seeking solutions to technical problems involving Digital Performer and/or plug-ins on MacOS, as well as feature requests, criticisms, comparison to other DAWs.
frankf
Posts: 1132
Joined: Tue Oct 19, 2004 10:01 pm
Primary DAW OS: MacOS
Location: NYC
Contact:

Re: Freezing Audio tracks seems a very slow process...

Post by frankf »

With Freeze you create as many Instruments tracks in one real time pass as you have individually bussed out of the VI into DP. I use aux tracks to bus VI outputs for all my Instrument tracks which reside in a v-rack. Taking a Kontakt instance as an example, with the following patches on separate MIDI tracks:
Piano Kontakt Out 1-2
Bass KT out 3-4
BD KT out 5
Share KT out 6
Snare 2 out 6
These are bussed into DP via aux tracks after making bundle assignments. The aux tracks are assigned to the same output bus
So I select the MIDI and aux tracks for all 12, set the selection to the length of the sequence, play enable all and Freeze. 4 audio tracks (or more) in a single real time pass.

Note that snares 1 & 2 are combined on a single audio track in this example. That's because they are both assigned to the same Kontakt output in the VI and both are play enabled. If I want separate audio tracks for each snare, I can do a couple of things. I can assign snare 2 to its own Kontakt Out, create an aux track for it and Freeze it with all the others. I can, with overdub on, leave the KT Outs and DP busses alone, and do another pass with only snare 2 and the original snare aux play enabled. (This creates another Soundbite on top of the snare 1 Soundbite. To separate, create a Similar audio track, name it snare 2 and just drag snare 2 Soundbite to it). I do this second pass with other VIs where multiple instruments are assigned the same out if their VI. Or, if I only have 1 or 2 of these, I bounce them individually to disk.

All the assignments are in a template, and key commands and group assignments help tremendously with the workflow.


Frank Ferrucci
Frank Ferrucci
http://www.ferruccimusic.com
Mac Pro 6,1 64gb RAM DP9.52 OSX 10.12.6 MIO 2882d & ULN2d Firewire Audio Interfaces, MOTU MTP-AV USB
zandurian
Posts: 599
Joined: Sun Feb 20, 2005 10:01 pm
Primary DAW OS: MacOS
Location: san antonio TX

Re: Freezing Audio tracks seems a very slow process...

Post by zandurian »

MIDI Life Crisis wrote:On a multi-core machine each instance of a VI gets a difference core so as MagicD says: spread the wealth! One instrument per instance is good!
That's good to know!
----------------------------------
Mac Pro (early 2009 - originally 4,1 - flashed to 5,1) 2 x 3.42 GHz 6-Core Xeon X5690, 64 gigs PC3-10600 RAM, OS 10.13.3, DP9.52, UAD2 duo, UAD2 solo,
Superior drummer 2, Mach 5-3, Ivory, PCIe 424, BL modded 24i/o, MIDI express XT, unisyn, Melodyne 2, Izotope RX2, Addictive Drums, Pianoteq
User avatar
MIDI Life Crisis
Posts: 26254
Joined: Wed May 18, 2005 10:01 pm
Primary DAW OS: MacOS
Contact:

Re: Freezing Audio tracks seems a very slow process...

Post by MIDI Life Crisis »

Not only that, but there appears to be no difference in terms of the CPU between a v-rack and an instrument track in a chunk, except the v-rack helps in changing to different chunks without reloading the VI each time. So if that is the case, then multiple v-racks holding a single large instrument each is going to be more efficient than one v-rack holding a VI with a few instruments.

Who knew?
2013 Mac Pro 32GB RAM

OSX 10.14.6; DP 10; Track 16; Finale 26, iPad Pro, et al

MIDI LIFE CRISIS
dpg4macman
Posts: 283
Joined: Mon Aug 20, 2007 12:59 pm
Primary DAW OS: MacOS
Location: Central PA USA
Contact:

Re: Freezing Audio tracks seems a very slow process...

Post by dpg4macman »

This would all be much easier if MOTU would incorporate bounce stems like S1. Select all your tracks in the sequence editor and select bounce stems instead of bounce to disc. All your tracks bounce as separate audio files. (wouldn't that be so nice _ and easy)

There are some pretty good ideas here. Routing the VI's to aux sends,etc... I've never frozen a track - always bounce. My VI's I transfer in real time via out through an analog mixer back into DP. I normally never apply any outboard processing and this has been the way I've always transferred my MIDI to audio tracks. Slow and painful but works.

mvh
zandurian
Posts: 599
Joined: Sun Feb 20, 2005 10:01 pm
Primary DAW OS: MacOS
Location: san antonio TX

Re: Freezing Audio tracks seems a very slow process...

Post by zandurian »

Ya' know I gotta' say it! In this day and age and considering the state of programming and cpu speeds and cheap storage space etc. we shouldn't have these hoops to jump through. We should be able to select every track at once and freeze everything to separate tracks in one quick choose and execute manner.

No reason in the world for all this except they don't take time to write the code.

I'm hoping that since DP and Mach 5 are from the same source that there is some feature like this built in to v3 of Mach five. You know a "freeze all V tracks to separate audio tracks" with a couple of pre-freeze options about mono or stereo or 5.1.
----------------------------------
Mac Pro (early 2009 - originally 4,1 - flashed to 5,1) 2 x 3.42 GHz 6-Core Xeon X5690, 64 gigs PC3-10600 RAM, OS 10.13.3, DP9.52, UAD2 duo, UAD2 solo,
Superior drummer 2, Mach 5-3, Ivory, PCIe 424, BL modded 24i/o, MIDI express XT, unisyn, Melodyne 2, Izotope RX2, Addictive Drums, Pianoteq
User avatar
MIDI Life Crisis
Posts: 26254
Joined: Wed May 18, 2005 10:01 pm
Primary DAW OS: MacOS
Contact:

Re: Freezing Audio tracks seems a very slow process...

Post by MIDI Life Crisis »

zandurian wrote: No reason in the world for all this except they don't take time to write the code.
So you've written code for a major DAW like DP and there is NO REASON? MOTU wants us to work harder?

I understand your frustration and I share it, but I suspect it goes a little bit deeper than simply not wanting to take the time to write the code.
2013 Mac Pro 32GB RAM

OSX 10.14.6; DP 10; Track 16; Finale 26, iPad Pro, et al

MIDI LIFE CRISIS
User avatar
FMiguelez
Posts: 8266
Joined: Sun Oct 24, 2004 10:01 pm
Primary DAW OS: MacOS
Location: Body: Narco-México Soul/Heart: NYC

Re: Freezing Audio tracks seems a very slow process...

Post by FMiguelez »

zandurian wrote:Ya' know I gotta' say it! In this day and age and considering the state of programming and cpu speeds and cheap storage space etc. we shouldn't have these hoops to jump through. We should be able to select every track at once and freeze everything to separate tracks in one quick choose and execute manner.
And how would you handle reverb and delays, for instance?
Which of all those separate tracks is going to get those Fx returns?

Suppose you have 50 audio tracks, and are using 3 reverbs and 2 delays (via sends) in most of them... Then what?
Should these bounced tracks be dry?

And lets suppose DP could somehow manage to print each track with its corresponding wet Fx (somehow)... But the mix would inevitably sound different, because any EQ or compression in any stem or submaster buss would not have the complete interaction of all the tracks, so the basis for EQ and compression that you originally set would be lost, would it not?

That's precisely why frozen tracks ignore send assignments in the resulting files.
zandurian wrote:No reason in the world for all this except they don't take time to write the code.
Do you really think that is the reason behind all this, or are you just venting some frustration????
Mac Mini Server i7 2.66 GHs/16 GB RAM / OSX 10.14 / DP 9.52
Tascam DM-24, MOTU Track 16, all Spectrasonics' stuff,
Vienna Instruments SUPER PACKAGE, Waves Mercury, slaved iMac and Mac Minis running VEP 7, etc.

---------------------------

"In physics the truth is rarely perfectly clear, and that is certainly universally the case in human affairs. Hence, what is not surrounded by uncertainty cannot be the truth." ― Richard Feynman
User avatar
FMiguelez
Posts: 8266
Joined: Sun Oct 24, 2004 10:01 pm
Primary DAW OS: MacOS
Location: Body: Narco-México Soul/Heart: NYC

Re: Freezing Audio tracks seems a very slow process...

Post by FMiguelez »

dpg4macman wrote:This would all be much easier if MOTU would incorporate bounce stems like S1. Select all your tracks in the sequence editor and select bounce stems instead of bounce to disc. All your tracks bounce as separate audio files. (wouldn't that be so nice _ and easy)
That would work only as long as you have an independent and dedicated set of Fx returns for each stem being fed by, and only by, the tracks in this same corresponding stem.

Otherwise, I'd have to ask you the same question I asked Zandurian in the post just above.
Mac Mini Server i7 2.66 GHs/16 GB RAM / OSX 10.14 / DP 9.52
Tascam DM-24, MOTU Track 16, all Spectrasonics' stuff,
Vienna Instruments SUPER PACKAGE, Waves Mercury, slaved iMac and Mac Minis running VEP 7, etc.

---------------------------

"In physics the truth is rarely perfectly clear, and that is certainly universally the case in human affairs. Hence, what is not surrounded by uncertainty cannot be the truth." ― Richard Feynman
zandurian
Posts: 599
Joined: Sun Feb 20, 2005 10:01 pm
Primary DAW OS: MacOS
Location: san antonio TX

Re: Freezing Audio tracks seems a very slow process...

Post by zandurian »

FMiguelez wrote:
zandurian wrote:Ya' know I gotta' say it! In this day and age and considering the state of programming and cpu speeds and cheap storage space etc. we shouldn't have these hoops to jump through. We should be able to select every track at once and freeze everything to separate tracks in one quick choose and execute manner.
And how would you handle reverb and delays, for instance?
Which of all those separate tracks is going to get those Fx returns?

Suppose you have 50 audio tracks, and are using 3 reverbs and 2 delays (via sends) in most of them... Then what?
Should these bounced tracks be dry?
Track specific audio plugs would print to the bounce and buss sends would be replicated into the new track. VIs would print effects used within the VI for that instrument. The above would handle 90 + percent of what I would need. That at least would be a great starting point and of course the option to do it one at a time for specialty stuff would still remain - just exclude those from the mass bounce.

So again - choose all tracks and execute "bounce all to separate tracks" and take a lunch break, come back and wake up computer to view the train wreck. Simple.
FMiguelez wrote:
zandurian wrote:No reason in the world for all this except they don't take time to write the code.
Do you really think that is the reason behind all this, or are you just venting some frustration????
I not only believe - I KNOW :idea:
----------------------------------
Mac Pro (early 2009 - originally 4,1 - flashed to 5,1) 2 x 3.42 GHz 6-Core Xeon X5690, 64 gigs PC3-10600 RAM, OS 10.13.3, DP9.52, UAD2 duo, UAD2 solo,
Superior drummer 2, Mach 5-3, Ivory, PCIe 424, BL modded 24i/o, MIDI express XT, unisyn, Melodyne 2, Izotope RX2, Addictive Drums, Pianoteq
User avatar
FMiguelez
Posts: 8266
Joined: Sun Oct 24, 2004 10:01 pm
Primary DAW OS: MacOS
Location: Body: Narco-México Soul/Heart: NYC

Re: Freezing Audio tracks seems a very slow process...

Post by FMiguelez »

zandurian wrote:Track specific audio plugs would print to the bounce and buss sends would be replicated into the new track. VIs would print effects used within the VI for that instrument. The above would handle 90 + percent of what I would need. That at least would be a great starting point and of course the option to do it one at a time for specialty stuff would still remain - just exclude those from the mass bounce.
Have you really thought this through?

You haven't explained how DP can receive and separate and send back to each instrument's bounce any send Fx one usually uses.
If you send some instruments to a reverb buss 1, and some others to reverb buss 2, how will DP be able to separate the instrument input from these busses and send it back to each?

You say it would work for 90% of the stuff you do, but that doesn't mean it would be much helpful for others, especially because most people I know mix the way I stated above.
For me, that would mean "excluding most, if not all, tracks from the mass bounce", as you put it.

How can DP deal with that?

Also, you haven't addressed this:
FMiguelez wrote:And lets suppose DP could somehow manage to print each track with its corresponding wet Fx (somehow)... But the mix would inevitably sound different, because any EQ or compression in any stem or submaster buss would not have the complete interaction of all the tracks, so the basis for EQ and compression that you originally set would be lost, would it not?

That's precisely why frozen tracks ignore send assignments in the resulting files.
I see the exact same problem there. It's not as easy as you put it.

Anyway. Your suggested method would ONLY work at the track level, as long as you use no submix tracks or send Fx via sends.

IOW, what you really are asking for is faster-than-realtime freezing, and not bouncing, correct? Otherwise, please propose a solution for the above problems.
FMiguelez wrote: Do you really think that is the reason behind all this, or are you just venting some frustration????
zandurian wrote:I not only believe - I KNOW :idea:
So I take it you have some MOTU insider information, or perhaps you are a MOTU programmer's friend who confessed this to you?
Mac Mini Server i7 2.66 GHs/16 GB RAM / OSX 10.14 / DP 9.52
Tascam DM-24, MOTU Track 16, all Spectrasonics' stuff,
Vienna Instruments SUPER PACKAGE, Waves Mercury, slaved iMac and Mac Minis running VEP 7, etc.

---------------------------

"In physics the truth is rarely perfectly clear, and that is certainly universally the case in human affairs. Hence, what is not surrounded by uncertainty cannot be the truth." ― Richard Feynman
frankf
Posts: 1132
Joined: Tue Oct 19, 2004 10:01 pm
Primary DAW OS: MacOS
Location: NYC
Contact:

Re: Freezing Audio tracks seems a very slow process...

Post by frankf »

zandurian wrote: Track specific audio plugs would print to the bounce and buss sends would be replicated into the new track. VIs would print effects used within the VI for that instrument. The above would handle 90 + percent of what I would need. That at least would be a great starting point and of course the option to do it one at a time for specialty stuff would still remain - just exclude those from the mass bounce.

I agree with FM that this needs a lot of thought, because it seems to demand a re write of DPs underlying audio routing structure. Freeze, by concept, includes a MIDI track so by using "Track specific audio plugs", I assume you mean an associated aux track with audio plugs. What if multiple VI instruments are assigned to that aux. how does that get handled? "VIs would print effects used within the VI.." What about using DP effects in a multi-channel VI like Kontakt, Omisphere, Stylus RMX, Mach 5? They must be bussed to auxes? See my earlier post for an example of the problems that arise. Maybe MOTU COULD program a multi pass freeze. But all the issues that FM mentioned would have to be considered for any of this to happen, but I see problems, at least for my workflow, with the way you suggest DP be changed to achieve what you want. This is whether you "bounce to separate tracks" or not. I'm not familiar with neither how PT does this nor PT's underlying audio architecture.



Frank Ferrucci
Frank Ferrucci
http://www.ferruccimusic.com
Mac Pro 6,1 64gb RAM DP9.52 OSX 10.12.6 MIO 2882d & ULN2d Firewire Audio Interfaces, MOTU MTP-AV USB
zandurian
Posts: 599
Joined: Sun Feb 20, 2005 10:01 pm
Primary DAW OS: MacOS
Location: san antonio TX

Re: Freezing Audio tracks seems a very slow process...

Post by zandurian »

frankf wrote:
zandurian wrote: Track specific audio plugs would print to the bounce and buss sends would be replicated into the new track. VIs would print effects used within the VI for that instrument. The above would handle 90 + percent of what I would need. That at least would be a great starting point and of course the option to do it one at a time for specialty stuff would still remain - just exclude those from the mass bounce.

I agree with FM that this needs a lot of thought, because it seems to demand a re write of DPs underlying audio routing structure. Freeze, by concept, includes a MIDI track so by using "Track specific audio plugs", I assume you mean an associated aux track with audio plugs. What if multiple VI instruments are assigned to that aux. how does that get handled? "VIs would print effects used within the VI.." What about using DP effects in a multi-channel VI like Kontakt, Omisphere, Stylus RMX, Mach 5? They must be bussed to auxes? See my earlier post for an example of the problems that arise. Maybe MOTU COULD program a multi pass freeze. But all the issues that FM mentioned would have to be considered for any of this to happen, but I see problems, at least for my workflow, with the way you suggest DP be changed to achieve what you want. This is whether you "bounce to separate tracks" or not. I'm not familiar with neither how PT does this nor PT's underlying audio architecture.



Frank Ferrucci
When I say "track specific plugs" I'm referring to audio tracks as well. I like to render (for example) Melodyne processed audio to hard audio files and since freezing/bouncing can be applied to audio and MIDI/VI tracks simultaneously I'm talking about a basic feature that would allow simple multi-track freezes/bounces of all tracks at once AND they should be done as fast as processor speeds allow. Specialties could be handled however you are handling them now.

But to be forced to treat all multi-track rendering as if was a special case with special needs just doesn't make any sense to me.

So to recap: Choose all tracks one wishes to freeze/bounce. Have the default mode render stereo tracks (or tracks made stereo by effects) as stereo tracks and mono tracks as mono tracks and include existing busses and aux/output routings in the new tracks.

Special needs tracks do as now (except let freezing take advantage of new speedy processors instead of real time).
----------------------------------
Mac Pro (early 2009 - originally 4,1 - flashed to 5,1) 2 x 3.42 GHz 6-Core Xeon X5690, 64 gigs PC3-10600 RAM, OS 10.13.3, DP9.52, UAD2 duo, UAD2 solo,
Superior drummer 2, Mach 5-3, Ivory, PCIe 424, BL modded 24i/o, MIDI express XT, unisyn, Melodyne 2, Izotope RX2, Addictive Drums, Pianoteq
User avatar
FMiguelez
Posts: 8266
Joined: Sun Oct 24, 2004 10:01 pm
Primary DAW OS: MacOS
Location: Body: Narco-México Soul/Heart: NYC

Re: Freezing Audio tracks seems a very slow process...

Post by FMiguelez »

zandurian wrote: But to be forced to treat all multi-track rendering as if was a special case with special needs just doesn't make any sense to me.
But it is a special case. Your special case...

Good luck convincing MOTU about changing the inner routing structure and bounce code to accommodate for your wish, especially since it wouldn't save you more than 2-3 minutes of time per mix for a regular song...

I also don't understand why someone would want to freeze every track with ONLY the insert plugins printed, but not any of the send Fx or any of the stem/submix busses Fx, plugins and/or automation (if used)...

I think the problem is that you are calling Bouncing what really is Freezing. All you basically want is to have fast-rendering of frozen tracks (not bouncing... otherwise you run into the issues I've been mentioning upthread).
Mac Mini Server i7 2.66 GHs/16 GB RAM / OSX 10.14 / DP 9.52
Tascam DM-24, MOTU Track 16, all Spectrasonics' stuff,
Vienna Instruments SUPER PACKAGE, Waves Mercury, slaved iMac and Mac Minis running VEP 7, etc.

---------------------------

"In physics the truth is rarely perfectly clear, and that is certainly universally the case in human affairs. Hence, what is not surrounded by uncertainty cannot be the truth." ― Richard Feynman
zandurian
Posts: 599
Joined: Sun Feb 20, 2005 10:01 pm
Primary DAW OS: MacOS
Location: san antonio TX

Re: Freezing Audio tracks seems a very slow process...

Post by zandurian »

FMiguelez wrote:
zandurian wrote: But to be forced to treat all multi-track rendering as if was a special case with special needs just doesn't make any sense to me.
But it is a special case. Your special case...

Good luck convincing MOTU about changing the inner routing structure and bounce code to accommodate for your wish, especially since it wouldn't save you more than 2-3 minutes of time per mix for a regular song...

I also don't understand why someone would want to freeze every track with ONLY the insert plugins printed, but not any of the send Fx or any of the stem/submix busses Fx, plugins and/or automation (if used)...

I think the problem is that you are calling Bouncing what really is Freezing. All you basically want is to have fast-rendering of frozen tracks (not bouncing... otherwise you run into the issues I've been mentioning upthread).
Okay - let me say it like this: However you want to freeze/bounce it should be able to be set up as an automated process. For efficiency sake.
----------------------------------
Mac Pro (early 2009 - originally 4,1 - flashed to 5,1) 2 x 3.42 GHz 6-Core Xeon X5690, 64 gigs PC3-10600 RAM, OS 10.13.3, DP9.52, UAD2 duo, UAD2 solo,
Superior drummer 2, Mach 5-3, Ivory, PCIe 424, BL modded 24i/o, MIDI express XT, unisyn, Melodyne 2, Izotope RX2, Addictive Drums, Pianoteq
User avatar
FMiguelez
Posts: 8266
Joined: Sun Oct 24, 2004 10:01 pm
Primary DAW OS: MacOS
Location: Body: Narco-México Soul/Heart: NYC

Re: Freezing Audio tracks seems a very slow process...

Post by FMiguelez »

zandurian wrote:
FMiguelez wrote:
zandurian wrote: But to be forced to treat all multi-track rendering as if was a special case with special needs just doesn't make any sense to me.
But it is a special case. Your special case...

Good luck convincing MOTU about changing the inner routing structure and bounce code to accommodate for your wish, especially since it wouldn't save you more than 2-3 minutes of time per mix for a regular song...

I also don't understand why someone would want to freeze every track with ONLY the insert plugins printed, but not any of the send Fx or any of the stem/submix busses Fx, plugins and/or automation (if used)...

I think the problem is that you are calling Bouncing what really is Freezing. All you basically want is to have fast-rendering of frozen tracks (not bouncing... otherwise you run into the issues I've been mentioning upthread).
Okay - let me say it like this: However you want to freeze/bounce it should be able to be set up as an automated process. For efficiency sake.
I hope you don't take this as me being obtuse, Zandurian, but the process is already automated...

All you have to do is get a time range selection with all the wanted tracks included, and invoke the Freeze Tracks command (takes no longer than 4-5 seconds). Go have a coffee, and when you come back everything is ready waiting for you... Is that not automated enough?

What exactly is inefficient about its current state? :?
Mac Mini Server i7 2.66 GHs/16 GB RAM / OSX 10.14 / DP 9.52
Tascam DM-24, MOTU Track 16, all Spectrasonics' stuff,
Vienna Instruments SUPER PACKAGE, Waves Mercury, slaved iMac and Mac Minis running VEP 7, etc.

---------------------------

"In physics the truth is rarely perfectly clear, and that is certainly universally the case in human affairs. Hence, what is not surrounded by uncertainty cannot be the truth." ― Richard Feynman
Post Reply