Quote:
Originally Posted by JFreak
Actually it is not PT HD which forces this workaround, but DSP processing. Doesn't happen on HD software using full native processing, for example HDN systems; can track through plugins, no problem.
It is designed to do so, it has always been like that. Only after you are in the DSP-land, you get processing. And back in the day going TDM/RTAS/TDM was even worse as it consumed double voices which I think this current workaround doesn't do any longer.
|
Ah yes, PT HDN. Sometimes I wonder why I didn't opt for an HD Native system myself. Considering how few DSP plugins are available, I have to use Native processing most of the time anyways. The only time I really use the DSP chips is for this cumbersome workaround. I still don't see why PT couldn't perform this task in the background for me.
Quote:
Originally Posted by dtmprod
Not sure why you'd be getting a CPU hit when placing a DSP before native while recording. I do that frequently & haven't noticed a challenge. Another possible workaround is to set up an aux track that feeds into the audio track. You can set the audio input on the aux channel & use native plugins while recording on the audio track. The possible drawback is that you're permanently recording whatever effect the plugin is set to. But if you're confident about the desired effect, then one less thing to be concerned about at mix time.....
|
I never noticed the CPU hit until I finally reached the CPU ceiling and disabled dozens of DSP Trim plugins at once. It's Autotune, so it has to be on the track live and I'd prefer not to print it because sometimes I do change it after the take.