Page 1 of 3
Input monitoring and delay compensation
Posted: Fri Oct 05, 2012 8:51 pm
by conleycd
So I thought I was pretty smart in avoiding the use of Aux tracks. I figured... what's the need if you can route to a track and use "input monitoring."
Well, after loading up a sampler in a V-rack and routing it's outputs into "input monitoring" enabled audio tracks (to create quick bounce downs) - I have found out that the input monitoring is not delay compensated by the DAW.
Can you all confirm this with me?
When I send the tracks to Aux inputs they all play perfectly in time.
I was mixing some live audio with room mics and heard an incredible delay between the two sources (greater than 100ms or so - at fairly high buffers when mixing).
Does DP 8 do the same thing?
CC
Re: Input monitoring and delay compensation
Posted: Fri Oct 05, 2012 10:07 pm
by Shooshie
Trust me: AUX tracks = the smart way to go. Don't try to do this with input monitoring. Besides, you will find SO many uses for aux tracks. Why avoid one of the best features in the program?
Shoosh
Re: Input monitoring and delay compensation
Posted: Fri Oct 05, 2012 11:18 pm
by conleycd
Shooshie wrote:Trust me: AUX tracks = the smart way to go. Don't try to do this with input monitoring. Besides, you will find SO many uses for aux tracks. Why avoid one of the best features in the program?
Shoosh
Yes... I have learned. I thought I can just flip on the record and do an easy audio capture of the tracks instead of having to use the "Freeze" function - which I sometimes find flakey as it forgets to keep track of busses that are used already and ends up recording over a previous track freeze.
Was that fixed in DP 8?
CC
Re: Input monitoring and delay compensation
Posted: Fri Oct 05, 2012 11:51 pm
by Shooshie
I haven't tried the Freeze function in DP8. My current projects are all-audio. I hope to get back to MIDI soon, as that's where I have most of my fun!
Shoosh
Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 4:43 am
by Prime Mover
To be honest, I never use Freeze any more. Maybe I would do it more if I was doing more orchestral work, but I've found the programs to be so efficient, and buffer so robustly (??) that I just let it do it's thing on bounce and be done with it. For some of you using 18 instances of PLAY or Kontakt, though, I could imagine Freezing to be a necessity.
Maybe they've honed Pre-Gen mode in DP8, that was always a sticking point since its introduction. I sorta wish that Pre-Gen wasn't automatic, but sorta like an "audio render". In the video world, we have the equivalent of video rendering. In that case, render files are built behind the scenes that we don't have to worry about organizing, yet we can control if and when they are built, and are shown on the timeline which areas are rendered and which are not. I sorta wish Pre-Gen worked this way, instead of ALWAYS trying to generate stuff without you knowing about it. Yet, I find Freezes to be messy and bothersome.
Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 6:35 am
by conleycd
I think if I'm using VIs into auxs - I have to freeze them. Maybe I'm wrong here? I could run them to a sub mix audio track and then do a real time record into that track without freezing aux Vi stuff.
PS - I noticed you have a MacPro 1,1. I do as well but I upgraded the processors to two quad core 2.66 (so now an 8-core). I was actually telling James because he has a similar machine. Cost under $99 and was pretty easy. Thought I'd mention it.
CC
Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 6:48 am
by daniel.sneed
To my surprise, I've seen that direct bounce was just fine in DP7.24, with my own set of VIs (MIDI and aux tracks).
What a time-saver!
AFAICT, it used to be somewhat *erratic* in previous releases.
Hope it will be fine as well in DP8 (still waiting in Europe...).
Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 8:11 am
by blackdot
Wait a sec, you guys just blew my mind! For years I have routed VI's (both loaded in DP and hosted in external programs like Bidule and Vienna Ensemble) to audio tracks. Then when I am ready to print to audio I just record-enable the tracks and press record. Works great, and the only delay I have ever noticed is due to playing VI's live when my buffer is set too high.
Are we talking about the same thing??
Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 8:16 am
by labman
conleycd wrote: I noticed you have a MacPro 1,1. I do as well but I upgraded the processors to two quad core 2.66 (so now an 8-core). I was actually telling James because he has a similar machine. Cost under $99 and was pretty easy. Thought I'd mention it.
CC
What is this drastic upgrade you speak of !!! Have an older 1,1 slave that this might fit. Please tell us what, where , how.

Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 8:57 am
by PJ
blackdot wrote:Wait a sec, you guys just blew my mind! For years I have routed VI's (both loaded in DP and hosted in external programs like Bidule and Vienna Ensemble) to audio tracks. Then when I am ready to print to audio I just record-enable the tracks and press record. Works great, and the only delay I have ever noticed is due to playing VI's live when my buffer is set too high. Are we talking about the same thing??
I think, yes. Delay depend on how much inserted plugins make delay, so it might be small. But DP always rec those tracks in time. So delay compensation is made after rec.
I use extra aux tracks for playback. Otherwise I do everything like you.
Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 9:41 am
by conleycd
labman wrote:conleycd wrote: I noticed you have a MacPro 1,1. I do as well but I upgraded the processors to two quad core 2.66 (so now an 8-core). I was actually telling James because he has a similar machine. Cost under $99 and was pretty easy. Thought I'd mention it.
CC
What is this drastic upgrade you speak of !!! Have an older 1,1 slave that this might fit. Please tell us what, where , how.

Two things.
1) Upgrade. Here's a YouTube link.
http://youtu.be/QU6qQRfhrXA
Buy some Xeon processors x5355s. You should be able to get two for less than $100. Buy that super long t handle 3mm hex key. Philips screw driver. Take out the fans, heat sinks, memory cage. Pretty easy. Clean off the heat sinks with alcohol. Pop in the new processors and you're set. Oh smear some thermal paste on the top of the processor first (not the pins). A little is plenty. You can upgrade the firmware to 2,1 specs too. But because apple are being pricks to boot in 64 bit mode you have to run your Mac as a hackintosh.
2) Aux vs input monitoring. I guess you can split the bus coming out of the VI. One to the track and one to an aux for monitoring. I don't particularly like rendering to audio but sometimes I do like to edit the audio as opposed to data. For example fades between clips.
CC
Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 2:22 pm
by Kubi
Yeah, just duplicate the whole thing in your template - a set of auxes for the work, and a set of stereo audio tracks for the print, fed by the same buss. Great, clean solution (and very old-school, like the left and right side of the board...)
And I *always* print to audio, at the very least by section/group, but individual tracks when I can - audio is the only enduring format in this ever-changing world. In a few years, many of your plug-ins and libraries will be changed, but 24bit WAV files will work as well as they do now.

Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 3:23 pm
by wheever
conleycd wrote:
Two things.
1) Upgrade. Here's a YouTube link.
http://youtu.be/QU6qQRfhrXA
Buy some Xeon processors x5355s. You should be able to get two for less than $100. Buy that super long t handle 3mm hex key. Philips screw driver. Take out the fans, heat sinks, memory cage. Pretty easy. Clean off the heat sinks with alcohol. Pop in the new processors and you're set. Oh smear some thermal paste on the top of the processor first (not the pins). A little is plenty. You can upgrade the firmware to 2,1 specs too. But because apple are being pricks to boot in 64 bit mode you have to run your Mac as a hackintosh.
2) Aux vs input monitoring. I guess you can split the bus coming out of the VI. One to the track and one to an aux for monitoring. I don't particularly like rendering to audio but sometimes I do like to edit the audio as opposed to data. For example fades between clips.
CC
I'm totally doing this, this week. That's the easiest, cheapest doubling of power life will ever hand me! I had no idea it was so easy and cheap to do, else I would have done this years ago. It's F*ing amazing!
I found some of the 5355s on Ebay for $43 each, and the long handle torx will set me back $4. I already have some thermo paste, so after all is said and done, we're talking ~$100. Wow.
Thanks for letting us know about that, conleycd!

Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 4:03 pm
by FMiguelez
blackdot wrote:Wait a sec, you guys just blew my mind! For years I have routed VI's (both loaded in DP and hosted in external programs like Bidule and Vienna Ensemble) to audio tracks. Then when I am ready to print to audio I just record-enable the tracks and press record. Works great, and the only delay I have ever noticed is due to playing VI's live when my buffer is set too high.
Are we talking about the same thing??
Agreed.
Audio tracks with input monitoring enabed works perfectly here.
So good that I changed my template... I don't use aux tracks anymore. This way there are so many less tracks, and all I need to do to print my individual audio tracks is press record. Bam! Done!
No latency or anything bad at all with input monitoring. It rocks!
I wrote about this here:
http://www.motunation.com/forum/viewtop ... 26&t=50004
Re: Input monitoring and delay compensation
Posted: Sat Oct 06, 2012 8:39 pm
by blackdot
FMiguelez wrote:
Agreed.
Audio tracks with input monitoring enabed works perfectly here.
So good that I changed my template... I don't use aux tracks anymore. This way there are so many less tracks, and all I need to do to print my individual audio tracks is press record. Bam! Done!
No latency or anything bad at all with input monitoring. It rocks!
I wrote about this here:
http://www.motunation.com/forum/viewtop ... 26&t=50004
Right--latency has never been an issue for me in this regard, and it is much simpler (for me) to not worry about all those aux tracks. If Shooshie would care to chime in, I would be interested to hear why he thinks using aux tracks is the smarter choice as he mentioned. I imagine it may be better for some workflows, but it would just add complexity in most of my projects.