Technical questions for the MPC2000xl and the MPC2000
By korce Thu Mar 01, 2007 5:39 pm
Is there any noticeable difference between midi clock and mtc? I read online that mtc has a variable error of around 8 ms...

I'm tracking my 2kxl into Digital Performer 5 (connected via USB 1X1 Midi interface) and have tried both midi clock and mtc. It seems that with both there is some small (ie when zoomed in very tightly) variability in where each drum hits (ie the kick drum will be in slightly different places each time if i do a few passes of the same sequence). Is this normal? Or are things normally exactly in sync when you track your beats? Does anyone have personal experience with tracking into DP 5? Whats your preference?
User avatar

By The Machinist Thu Mar 01, 2007 9:46 pm
There's no such thing as "perfectly" in sync that I know of, as most, if not all formats are based around some sort of cyclical pulse or another -- so you will have some variations in timing. However, every kick being in a different location? I've never personally had any problems like that. The normal thing for me has always been leaving an initial grace/null area, with no content, so that the devices can have a bit of time to sync properly -- after that things usually stay tightly in sync.


A Few Differences:

Midi Clock transmits tempo, and is based around BPM. This being, it can be used to actually sync the BPM (tempo) of two or more devices without you actually needing to manually match them, unlike MTC. The master sync reference provides tempo, then all other devices set to reference the master has it's internal tempo disregarded -- as it follows the master's. Midi Clock functions well with MMC, and often does best with tempo changes compared to MTC (though not always).

MTC is a type of Timecode much like EBU, SMPTE, except it's transmitted over midi cable. Unlike Midi Clock, MTC is referenced to hours, minutes, seconds, frames and subframes, like a standard clock. If you use an adequate setup that provides proper time stamp data, this can actually be a pretty precise sync method (though not as precise as APP or other robust forms of Timecode). It is important to make sure that the frames and tempo match on the sending and recieving devices before you start the sync, unless you have reasons to do otherwise. MTC can do well without MMC, and often does a great job staying in sync when winding (foward, rewind, jog) if there aren't many tempo changes.

I personally prefer MTC whenever available over Midi Clock, when it comes to devices with sequencers. When dealing with devices without sequencers, Midi Clock usually tends to be more useful, as it provides usable tempo (BPM) reference, which is good for things like syncing the slave's effects or what have you to the master BPM. But, like said, I prefer MTC for sequencers or ATRs, as they provide real world h,m,s,fr,s.fr references linking the device's real world clocks together regardless of tempo fluctuations.

If you have tempo changes via a tempo track, I'd use Midi Clock in most cases, this is so that the BPM reference can continue to be reported to the slaves correctly. Why not MTC? Well, some devices implement clocks poorly, or not at all, so the the clock will often speed up, but sometimes disregarding the tempo track data.

I look at it like this. When dealing with mostly audio and a little midi, I more than not prefer MTC. When dealing with mostly midi and less need for audio precision, I go Midi Clock.

However, you need to make sure you're using the correct sub-category settings, because if either of your devices are set to cycle record or some sort of loop mode......you need to make sure that your "Follow" settings are correct when dealing with MTC, and make sure that your "Continue, Start, Stop, Reset" settings are correct for each device, when dealing with Midi Clock. Otherwise your slave device may be constantly trying to refresh or catchup to latch to the sync with every cycle/loop start, or stop and/or start of the transport controls.

That could just be me though. Hope that helps, and makes sense. Hopefully someone else will add to this. And of course this is all generally speaking, as it really depends on the abilities of the given hardware in the end.