Quote:
|
Originally Posted by dagosto
The reason that you need that in protools is because of how the digi DAE works in the higher level Le systems. You have to monitor from software using 001 and 002's. Most interfaces will have a separated app where you do your monitor mixes. Some examples are MOTU's Cuemix and RME's Fireface Mixer. These programs allow for virtually latency free monioring and because the mixing dsp is happening inside of the interface allows lower cpu overhead.
|
Well that's fine if monitoring is handled in a seperate app for low latency but that really isn't what I was wondering about.
Quote:
|
Originally Posted by dagosto
One advantage I have found in Sonar is that on each track you can either elect to listen through the track with latency or you have a hard bypass which does not monitor the track at all. This allows you to completely delegate monitoring to the interfaces dsp chip further lowering cpu overhead.
|
That's actually cool because you can get complex mixes using all sorts of real time plug-in processing on playback but not have it affect the headphone mix during tracking, if that's what you're into.
So say for example Sonar; while you're listening through the track, if you boost too much does Sonar alert you of clipping after the fader? I think some apps don't, which is a bummer.