mpc master cubase slave

can someone explain how to set up mpc as the master and cubase as the slave

"can someone explain how to set up mpc as the master and cubase as the slave"

The MPC 1000 only transmits MIDI Clock, which Cubase (at least SX, which is what I run) will not sync to. Older MPCs send MIDI Time Code (MTC) which Cubase CAN sync to.

To get around this, set the MPC to sync to MIDI Clock and have Cubase transmit a clock signal, and there's your sync.

You can still sequence Cubase VSTs, etc using the MPC's tracks (see my explanations for how to do this [run a search, I don't have time to find it...], as well as the link to my MPC Project for Cubase here: http://thynctank.com/MPC_Project.cpr

Essentially this project is a set of 16 MIDI tracks in Cubase, each filtering all but the given channel your MPC should transmit on for any VST tied to that particular channel. You'll need to customize your MIDI/Audio setup for your particular setup, but other than that you're good to go, just add some VST instruments. (hit the F11 key to bring up the VST Instruments window)

Good luck,
-tank.

Hi - Tanks method is cool but you will need to keep an eye on latency. Sending out a midi clock from Cubase will introduce a few milli seconds of latency, then having your MPC transmitting midi data back into Cubase will add a bit more. You can see this if you actually record the MPC transmitted notes back into Cubase and then examine the track - none of you notes will be on the beat so you will often need to quantise the Cubase track.

Also remember that the higher up the midi channel you go, the worst it will get so keep all your drums on the low midi channels. Strings and stuff with slow attacks can go higher (who ever decided that the midi standard should have drums on channel 10?!!!)

punkdISCO wrote:Also remember that the higher up the midi channel you go, the worst it will get so keep all your drums on the low midi channels. Strings and stuff with slow attacks can go higher (who ever decided that the midi standard should have drums on channel 10?!!!)

Um, like what? Nothing in the MIDI spec imposes any priority order on channels. Some devices might send or process the channel data in order if there are many events at the same time, that is not the MIDI spec's fault. But if that makes any audible difference you're probably overloading the MIDI link anyway, and at that point all bets are off!

I had never heard anything about this, but then again, I'm new to the game still. (only been foolin and toolin with MIDI for 3 or 4 years now)

Figured I shouldn't speak up on it since I didn't know what I was talkin about. But it didn't really make sense to me that anyone would have prioritized certain channels!

Anyway, thanks Stereoroid for clearing that up.

-tank.

Hi Tank "But it didn't really make sense to me that anyone would have prioritized certain channels!"

Correct, no channels are prioritised but you can only physically read/write one at a time so you have to decide how to do this. It is generally assumed that all hardware and software start at 1, and then work their way up to channel 16. Guess it does make sense to do it like that but its not guaranteed

Hi Stereoroid "Um, like what?" I dont understand that question

"Nothing in the MIDI spec imposes any priority order on channels"

I was not aware of that but it does not surprise me. However, implementation have to set a processing order..

"Some devices might send or process the channel data in order if there are many events at the same time, that is not the MIDI spec's fault"

Errm, not too sure about the word 'might' - they physically have to.. You can only send/transmit one message at a time via midi; its serial. Also, it is impossible to receive 'many events at the same time'; its serial

Tank's suggestion to God Body (good name!) was to setup Cubase to allow a VST(s) to be played by 16 midi channels from the MPC. Even forgetting about the VST audio latency which will be 5ms on a good machine (so 5ms out from your MPC audio) you then have to look at the midi latency. Every SERIAL midi message (notes etc) takes about 1ms and you can only send one at a time. Test: from a rock solid sequencer, send the same MIDI note to a midi multi-timberal synth over 16 channels and record the audio. If channel 1 is a HH and 16 is a Clap, there will be about a 14ms gap between the HH and the Clap. This will be VERY audible on things like drums but not so with strings etc as per my original email. btw, if you are layering two kicks via midi, flanging will start to be audible when they are 2-3ms apart. MIDI is one of the reasons behind the MPCs success as all the internal sounds play exactly on time - "they are tight". Back to the above example on your MPC playing 16 internal samples all at the same time, the HH and Clap will play together and not 14ms apart..

So the long standing midi question will always remain: why are GM drum kits assigned to channel 10?!!

I have the below saved in some of my music notes. Can't remember where it comes from but I only ever note 'credible' information regarding music technology:
-----------------------------------------------
The clock used to march data out of a MIDI interface runs at a frequency of 31.25kHz, using a serial protocol first introduced in 1983. Ten cycles of this clock are needed to define each MIDI byte, and with three MIDI bytes needed for a typical Note On command, the total time it takes to transmit one typical MIDI message is thus nearly 1mS. Since MIDI is a serial protocol, successive messages must wait until their predecessors have been transmitted, meaning that MIDI has a very much lower timing resolution than sampled audio.

Although a single MIDI interface supports up to 16 MIDI channels, they all have to travel down the same serial cable, and so a single note played back at the same time on each of 16 MIDI tracks will emerge as a stream of events spread across 16mS. In slower ambient music this spread may not be audible, but it certainly can be in high-tempo music that uses lots of drums.

Ok, so basically, syncing an MPC 1k to Cubase or any other DAW will never be completely on time due to it's midi clock standard rather than SMPTE or Time Code, correct?

In other words, unless AKAI releases an update which includes SMPTE or Time Code, we are basically screwed in that respect?

Right, I am trying to make sense of this but not having much luck Im enjoying my 1k now ive got my head round most of it (top top machine) also just added Adobe Audition to the mix and a desk. RIGHT where does midi come in, I know the general idea with midi but I didnt know I could trigger stuff in audition with the MPC (or can I ) sorry for being vague but no manual, at work (as usual !)
Could anyone point me in right direction here at moment just using Audition for wave editing & recording but if I can master/slave etc could open up a whole new world

Cheers folks ya help always much appreciated

Hi

"Ok, so basically, syncing an MPC 1k to Cubase or any other DAW will never be completely on time due to it's midi clock standard rather than SMPTE or Time Code, correct? In other words, unless AKAI releases an update which includes SMPTE or Time Code, we are basically screwed in that respect?"

No, we are not talking about midi clock here, just midi itself (sending midi notes). In a very simple setup of a sequencer playing a 16 part multi timberal synth (a Access Virus for example) with no clocking information being sent. If the sequencer sends 16 notes on step One, to 16 different midi channels to the Virus, the Virus will play part 1 about 14ms before part 16. Things start to get worst if you are sending other midi info: Say you want to sync the LFOs or arpeggiator and do then decide to also send midi clock to the Virus, your 14ms will be increased depending on how many 'clock' messages are sent during the 16 note transmittion. If you also have some CCs being send, things are going to get pretty awful.

In fact, sync'ing using just a clock is likely to give you the best results as: Cubase is sample accurate and your MPC will be spot on. If you extend the above test to include 16 VSTs and 16 MPC notes (Cubase sequencing the VSTs and MPC sequencing its internal sounds so NO midi notes being send anywhere external), all playing on step one: the 16 VSTs will all play exactly together, the 16 MPC notes will play exactly together and there will be maybe 2ms delay between the Cubase and the clocked MPC. So you have 24 notes all playing exactly together (well, 16 Cubase together and 16 MPC together with a small amount of ms midi clock delay between them [no idea what this actual figure will be but gunna be small]).

Hope this makes sense..

punkdISCO wrote:"Some devices might send or process the channel data in order if there are many events at the same time, that is not the MIDI spec's fault"

Errm, not too sure about the word 'might' - they physically have to.. You can only send/transmit one message at a time via midi; its serial. Also, it is impossible to receive 'many events at the same time'; its serial

OK, pardon me for using woolly language there. By "same time" I mean the same timestamp in the sequencer, you don't need to tell us how the MIDI interface is a 31.25kb/s current-driven serial link - we know too well!
There has to be an order of transmission, true, but is it 1->16? Why not 16->1? It probably is 1->16, but that's up to the device, it's not in the MIDI spec and isn't guaranteed, like you say.

punkdISCO wrote:Test: from a rock solid sequencer, send the same MIDI note to a midi multi-timberal synth over 16 channels and record the audio. If channel 1 is a HH and 16 is a Clap, there will be about a 14ms gap between the HH and the Clap. This will be VERY audible on things like drums but not so with strings etc as per my original email. btw, if you are layering two kicks via midi, flanging will start to be audible when they are 2-3ms apart.

Yup: sending 16 notes at exactly the same timestamp is an example of overloading of the link. It takes a specific test like that to make the difference audible, and it isn't about the channels - it can happen when all the data is on the same MIDI channel too, splitting it across channels doesn't make it worse (or better), the bottleneck is the serial nature of the link. That's all I meant: with real performance data you don't want to be in that situation if the results are audible, and data on Channel 10 will be 10th on the list only if Channels 1-9 have data with the exact same timestamp and it goes out in 1->16 order.

Right now I don't see why gear makers can't adopt MIDI-over-USB as a standard: cabling would even be easier, since they could use A-B cables, no chance of hooking up IN-IN or OUT-OUT by mistake. Same data, faster links, lower latency.

"Right now I don't see why gear makers can't adopt MIDI-over-USB as a standard: cabling would even be easier, since they could use A-B cables, no chance of hooking up IN-IN or OUT-OUT by mistake. Same data, faster links, lower latency."

Im up for that dude!!

I just wanna know how to get my Cubase SX to communicate with my MPC in way where my timing stays solid.....possible or not possible? If so, how?

"I just wanna know how to get my Cubase SX to communicate with my MPC in way where my timing stays solid.....possible or not possible? If so, how?"

What do you want to do?

1) sequence both separately and then sync them together (using clock).
2) Get one to sequence the other by sending midi notes (no clock sync)

btw, I think stereoroid mention this earlier but, dont let all this doom and gloom concern you too much. Our posts have been discussing the theoretical sloppy results you can get with midi, however, the actual result will rarely cause concern. My Cubase setup is rock solid and I have lots of outboard synths and hardware sequencers. Sure, if I started to monitor my times I might find that my tb303 plays 3ms out of sync with my MPC or Cubase tracks but does it really matter?

I want to point out that it is simply not true that MIDI channels are
sent in order from sequencers, tracks are generally processed in the order they appear from top to bottom, regardless of their assigned MIDI channel.

I have a few samplers from a former American competitor and they have the option of delaying the sample, moving a sequencer track backwards the same amount helps avoiding midi contention, improving tightness. This
is a nice trick that can be forced upon most samplers, if needed.

Also as midi is 31.25kbit, theoretically, a single notes arrival (or timing clock) could be timed to within 1/31250 s which is close to "sample-accurate"

"I have a few samplers from a former American competitor and they have the option of delaying the sample, moving a sequencer track backwards the same amount helps avoiding midi contention, improving tightness. This is a nice trick that can be forced upon most samplers, if needed. "

Surely you will need change this offset for every note? Say we are on part 16 (in your sequencer or midi channel - it does not matter which but assuming it is the last one in the list) on one beat it might be the only note playing so it will play 1ms after the sequencer sends the note. On the next beat, the previous 15 channels/tracks are also sending notes so now your part 16 will play 14ms after the note is sent.. So, how do you cater for this or is it a dynamic offset?

Sounds cool mind..