Midi Clock Stability JJOS2XL

Can anybody else with an MPC1000 check the stability of the Midiclock being generated.

Using an Ipad app called Midibus which monitors the stability of a clock signal I tested the Midiclock from the MPC.

To my horror I found Midibus telling me that -

The variance at 120. was +/- 1.7 %!! No!

The BPM reading would appear to recieve a slow clock (118ish) for 3 beats followed by a fast clock(125ish) on the final beat of each measure!

This jumpy clock behaviour is confirmed by the way Lemur reacts when slaved to it. Every so often, at the end of a bar mostly, Lemur will kind of skip and trigger notes quickly like a syncing hiccup.

The clock is being sent from the MPC to the Ipad2 vis an iConnectmidi4+.

Midibus also generates midiclock which is very stable - no variance at all. Using this I was able to slave the MPC with no probs whatsover.

Could the JJOS clock be so bad? Anyone else care to test it?

MTC works great I know for most things but I did expect more....

it really improves when synced to another more stable clock... i still love my jjos

What improves when synced to a stable clock?

MPC's own clock generation ability?

Lemurs sync?

Something else?

Not sure what you mean by that. Do you mean that having a stable master is needed to achieve good sync with the MPC? If so, that is saying the MPC is unable to be a stable midiclock master on its own which is fairly poor for a Midi workstation which claims to have this ability.

I realise that its not the only peice of HW that suffers in this area, more like one of many, but jeez - can an ipad app really be magnitudes better at generating stable clock?

PS What are you using as a master clock?

I love JJOS too! I doubt I could go back to the original OS now - JJOS is just so functional, but is the clock known to be better with certain other OS?

a simple google search would have shown you the many answers to this moonmonkey, even in this very forum. If you go here and read the innerclock write up on midi clock testing and there ratings for different gear including the MPC you will see that it is not the MPC.
http://www.innerclocksystems.com/New%20 ... itmus.html
Probably something to do with your interface or software, it is not likely the MPC as you can see that, even in song mode which is the worst, it is not as big a lag or change in BPM like you seem to have ie a few milliseconds depending on sync. you dont need MTC for midi clock either.
How did you test the clock. have you tried any other midi device at all like a synth or drum machine or a soft synth on another computer?

Load up the Akai OS, and see how it compares to JJOS.

im talking about any elektron gear for example but yeah what those guys said

I've certainly experience significant midi note jitter with my 2500, which can be eliminated either by downgrading to the stock Akai OS or by using a 3rd party MIDI sync master. Perhaps this MIDI clock problem of yours is related? Never noticed any serious MIDI syncs probs myself, only note data jitter..

If you test all the OS , please do it with OS3 too.
I think no one did it till now. As there are less functions the timing may be better than os2xl.

Tsutek, Have you ever tried to slave the lemur5 drumsequencer to the MPC. You have a 2500 not a 1000 right?

anyone measured how stable the mpc is getting clock from the tap tempo in? i use that sometimes and it works for my purposes, but i've never measured, tbh, i'd guess it's not that stable...although i don't know if it's different than the sequencer running on it's own.

maybe something for an update? it might be easier to make it stable if it's assumed it's getting stable clock in the 1st place vs tap tempo, although i don't know where the instability is coming in.

i use emagic unitor8s to do the click to time code thing too and again i've never measured it (ignorance is bliss ) but it's certainly cheaper than the innerclock options.

Using tap tempo is somthing i have wondered about too - is it easier/harder/same for the slave to "interpret"?

Midiclock is sent at 24ppq resolution so i assume that tap tempo being made up of messages sent less often typically would be a different process entirely, not sure. Maybe a harder calculation but less often vs simpler math more rapidly?

The stability of the clock is one factor but the ability to recieve clock is another. Not all devices read the clock in the same way - see bidule which allows you to change the response to incoming clock quite alot.

Bliprock - thanks! I reccomend the link you posted to anyone who has not yet discovered it! It is good info and their device has been on my wishlist for years.

I have not seen them test the 1000 though? Its similar to 2500 yes, but can we expect the same results? The results of the 2500 indicate that OS is critical as is choice of pattern vs song mode as is external vs internal sync. The later JJOS being a lemon in some instances! None of the tests are regarding the devices ability to send midiclock though - its internally triggered audio being sent to a DAW that they have tested, not midi. This is also under internal clock and when slaved - they did not look at its slaving capacity as the master!

Anyway - i am and have been very satisfied with the 1000 using MTC to slave Cubase. Accurate enough and lowering buffer size of the audio card improves things even more. The audio card of course can influence things - my old fast track pro USB card cannot compete with the RME PCI multiface here but it was still useable.

I only noticed the slop when I tried to sync the Lemur app up. Oh well, one step closer to the sync gen/acme4/rh301!!

Moonmonkey wrote:I have not seen them test the 1000 though? Its similar to 2500 yes, but can we expect the same results? The results of the 2500 indicate that OS is critical as is choice of pattern vs song mode as is external vs internal sync. The later JJOS being a lemon in some instances! None of the tests are regarding the devices ability to send midiclock though - its internally triggered audio being sent to a DAW that they have tested, not midi. This is also under internal clock and when slaved - they did not look at its slaving capacity as the master!

Lemons are for "Akai: MPC-2500/OS Version JJ 3.25". I guess it's "MPC2500 OS-XL Ver3.25 13-DEC-2012".

Indeed hard to reach a conclusion from these tests.

Moonmonkey wrote:Tsutek, Have you ever tried to slave the lemur5 drumsequencer to the MPC. You have a 2500 not a 1000 right?

Sorry, no. I'm still using wifi midi with my lemur and that causes latency in all cases, so my test wouldn't really reveal anything important. Waiting for the lighting compatible version of iConnectMIDI to get released

Well it seems as though the MPC clock was not to blame here after all!

Instead it appears it was the iConnectmidi4+ which was creating the issue. I'm not 100% sure yet though and waiting to hear back from their support team but...

One morning I woke to find the iCM4's midi ports missing from within the cubase project. Device manager showed the yellow exclamation by the device. Tried everything upto and including a windows reinstall, no joys. Mystified I turned to the oracle.

A user post informed me that even if you are not using the audio ports of the iCM4, they must still be enabled for the host PC/Mac to recognize it. This worked but also seems to have corrected the sync with Lemur too!?

I'll test and see if the midibus clock monitor shows any change as well. Hmmm...

IIRC some software like bidule for example requires an audio device to be present in the project in order to maintain proper sync with an external device, even if it is not being used directly. Possibly this is what's going on here too....I hope so cause Lemur is gonna be awsome if so!

im tired of people bashing jjos before they shake down the rest of their system. do you want sloppy sync? try a korg poly 800. didnt stop it from being a hero in 80s music and techno/house/reggae etc etc as a synth and midi sequencer...