Printed from:
Les Brockmann Music Engineering . Writing ON MUSIC & ENGINEERINGOn Music & Engineering

Friday, March 16, 2007

Beat Monitoring Latency with MOTU Cuemix -- part 2

Guess what, there's an easier way!

As I was posting the previous article, "Beat Monitoring Latency with MOTU Cuemix — part 1", I verified my information and research with Jim Cooper of MOTU. He told me:

"Most major DAW packages (DP, Cubase, Logic, etc.) have a way to control CueMix monitoring (enable/disable, level, pan, etc.) from within their mixing window. This is covered in our manuals for the 828mkII, Traveler, UltraLite, etc., and is significant because it means the user doesn't have to switch to CueMix Console to manage the input monitoring."

I said, "Huh?" He explained further, and even kindly sent me the manual from a MOTU UltraLite so I could see for myself. It says, in part (p. 57-58):

Some audio applications allow you to control CueMix DSP monitoring from within the application (without the need to use CueMix Console). In most cases, this support consists of patching an UltraLite [or any compatible MOTU interface] input directly to an output when you record-arm a track. Exactly how this is handled depends on the application.

I tried it and it works

I recently engineered a large project with producer Nelson Kole, in which we spent a week doing a lot of live tracking into DP, including drums and other rhythm section, guitar overdubs, horns, violin, and two days of singers, both solo and group. His music system includes Digital Performer 5.11 running on a G5, with a MOTU PCI 424 card and a couple of interfaces, a 2408 Mk.II and a 1296. Each of the 18 pieces of music had tracks previously prepared in DP, including audio parts and MIDI instrument parts including several software synthesizers. Of course it was necessary to keep monitoring latency to a minimum, but the computer processor wouldn't be happy with the buffer set short enough, 64 samples.

So, I just left it at 1024 samples. On a previous project with this setup, I had used the MOTU CueMix Console to manage monitoring with low latency, and it worked fine but frankly I found it to be cumbersome to have to constantly switch to this separate control applet, especially with so many musicians and a tight work schedule.

So this time I did not use CueMix Console at all! I tried it the way Jim suggested it and it worked (almost) flawlessly.

The easy way

Okay, you've read far enough, so here's the deal. It's almost too easy!

Once again, from the manual:

To turn on CueMix DSP in Digital Performer and AudioDesk:
1. From the Setup menu, choose Configure Audio System>Input Monitoring Mode.

2. Choose the Direct hardware play through option, as shown below (See figure 1).

3. From the Studio menu, choose Audio Monitor, and enable Audio Patch Thru (
[in older DP versions] the button with the headphone icon on it). [In DP 5 choose "Auto" on Studio menu > Audio Patch Thru > sub-menu.]

Figure 1

Once enabled, CueMix DSP monitoring is tied with Digital Performer or AudioDesk's Audio Patch Thru feature: when you record-enable a track, the track's input is routed directly to its output (via CueMix DSP in the UltraLite [or other compatible MOTU] hardware).

For example, if you record-enable a track called "Guitar" in your DP or AudioDesk project, and its audio input assignment is Analog in 2, and its audio output assignment is channels 7-8, CueMix DSP no-latency hardware monitoring will automatically be set up from analog in 2 to outputs 7-8.

So there you go. If you're the manual-reading type, you can get more details in the booklet for the UltraLite and similar compatible MOTU audio interfaces. This is also covered in some detail in the big manual for Digital Performer version 5, starting with page 214.

Was it there all along?

So what's my excuse for not having previously learned this with meticulous R.T.F.M. (reading the you-know-what manual)? I recall that this "Direct hardware playthrough" option has been available in DP for quite a long time, going all the way back to Version 3 in OS 9, before the PCI 424 cards with on-board monitoring DSP were even available. So the same command used to do something a little bit different, or at least I thought so. Always something new to learn, and they are always improving things!

One more thing, earlier I mentioned that monitoring in DP in this fashion worked almost perfectly. In my experience, with this particular set up, the monitoring of source sounds when a track was record-armed was almost always there, but occasionally a track did not monitor. In order to solve that, I had to "quit" DP and then re-launch it. Then it would go back to working perfectly. This probably happened a couple of times a day in our tracking. I discussed this with MOTU but they were unable to duplicate this problem. Your mileage may vary.

One more thing I should mention, in my previous "part 1" blog article I said: "To use it, first change the setting in your audio/MIDI software so that it does NOT monitor the input signal from any record-enabled track at all." But this is not the case when monitoring this way and controlling it within DP; see the above instructions.

You will find that each track, when record-enabled, will monitor the "source" audio all the time, that is, when recording, stopped, or playing back. So, you'll have to tell the talent to be quiet during playbacks, or better yet, mute the mic or take the track out of record.

MOTU says that this method of controlling CueMix DSP monitoring from within the application will also work with other applications, but with regard to specific instructions, the manual says, "Consult the manual for your software." Sorry.

By the way, don't forget that this low-latency CueMix DSP monitoring is only available with the compatible MOTU brand audio interfaces. For a complete list, as well as other details about latency and its causes and management, please refer to my previous blog article, "Beat Monitoring Latency with MOTU Cuemix — part 1".

The importance of processor management

This whole business of dealing with monitor latency, and changing the settings in the hardware buffer, is part of the task of managing the performance of the computer's processor. With any of the "native" software and hardware combinations, computer and audio interfaces, you always have to be aware of the tradeoffs involved, and keep an eye on making sure the computer has sufficient power to do the work you're asking it to do. In DP the "Audio Performance" window (shift-Y) is a good way to keep track of that.

Nelson and I had another experience that reminded us of the importance of this. In a song file that had a lot of tracks and effects, we stopped during the mixing process to play in an extra drum sample part, using the Model 12 drum software synth. (The Cuemix feature doesn't work for soft synths.) In order to play the part with low latency, Nelson changed the hardware buffer from 1024 to 128.

Then I went back to mixing, using the automated Yamaha DM2000 console. In order for the automation to run, in DP we set "Transmit Sync" so that the mixing board receives MIDI time code.

To our distress, we found that suddenly the mixer wasn't getting continuous time code, but the code was starting and stopping. Not good — just what we didn't need, technical gremlins!

After quitting and restarting DP, restarting the computer, trying other files, and a few other troubleshooting steps, we finally hit on the solution: the buffer setting had never been returned back to 1024, and so the processor simply didn't have sufficient power to generate continuous time code. With the number set back to the higher value, problem solved. It just goes to show you the central importance of managing your computer's processor, and how it can affect almost every aspect of the software's performance.

Stay tuned

I expect to be announcing a great new resource that I'm involved with, for comprehensive web-based training on Digital Performer and many other professional computer applications and other music topics. Check back soon!

Thanks to Jim Cooper of MOTU for his help in researching this article. This is not intended as an advertisement for any product. All products mentioned are trademarks of their various manufacturers; manual excerpts ©2007 MOTU. ©2007 by Les Brockmann.

Previous Posts