It’s kind of funny, because so many people complaining about the bad MIDI timing of Ableton Live.
It is. I was not expecting these results. I might instal the official Akai OS on the MPC to give it a try.
In slightly unrelated news; the Micro Q has an option to send MIDI Clock that simply does not work.
@t2k – I just made a comment on Moog Sub Phatty forum where some real musician complained that Sub37 clock deviates from his mechanical metronome. In a few hours I got an email from Amos (the firmware guru at Moog) with a beta firmware attached which greatly improved clock jitter.
@kvitekp Thanks, that’s a very rapid response; takes me one step closer to getting a Sub37 myself one day.
Here are the result from Akai’s original firmware, as well as various versions of JJOS:
JJOS1 V4.99L: 4.1%
JJOS2XL V3.47: 3.2%
JJOS3 V1.29: 3.1%
Original Akai OS V2.13: 3%
And finally the OP-1 going through the Kenton MIDI USB Host MkII scoring an equally disappointing 3.3%. Please note that this result might be worse because of the MIDI USB Host.
@kvitekp Sorry, I don’t own a MIDIpal. My first reaction after seeing the MPC results was that I must have made an assembly mistake putting together the MidiGAL. Are you thinking the same thing based on these results?
This is on an iPad Mini 2 running iOS 8.1.3 with the Behringer UMC204.
@t2k – do you have MidiALF, MidiREX or MidiBUD? While I cannot imagine assembly mistake that would cause this kind of results, it would still be good to establish a baseline.
Just saw this thread. Excellent stuff!
Above, @kvitekp remarks that “even if the slave devices average incoming BPM, they will still benefit from receiving coherent stable clock”.
I’ve found that this is currently not always the case, or at least not in my situation when the A4 is slaved to the RYTM. Using MidiClk in Clock Generator mode in between the RYTM and the A4 results in playback that’s noticeable out-of-sync and sometimes jittery, especially when playback is stopped and continued. As far as I’ve been able to figure out, there seem to be two reasons for this:
1.When MidiClk is in Clock Generator mode, it stops sending out MIDI Clock messages after it receives a MIDI Stop message. This is in contrast to the behavior of the RYTM which always sends out clock messages, regardless of its sequencer play state. This means that there’s no way for the A4 to reliably sync to the correct tempo by averaging clock messages before playback has been started.
2. When you hit the “Play” button on the RYTM, it immediately sends out a Midi Start or Continue message followed by a clock message, essentially “resetting” the stream of clock messages it is sending out. The averaging done by MidiClk “fixes” this which can result in the A4 starting a little behind the RYTM.
Please note that I’m not saying MidiClk is doing anything wrong here, it’s just that in this specific case, it’s making things worse instead of better.
For more reading on syncing with MIDI Clock, please see here
@kvitekp: I would like to test the MidiClk firmware with my MidiBud. Is there a .hex or .syx file to download?
Chances are your MidiBUD has MIDIpal compatible bootloader, so you’ll have to use midiclk_pal.syx file.
@t2k – I was testing MidiClk with clock sources that don’t send MIDI Clock messages while stopped, so it restarts outgoing clock sequence when it receives Start… probably I should change logic so that MidiClk Generator will always send output clock if it receives one. I believe my Korg Z1 always sends output clock when it’s enabled and sends Start/Stop when ARP is activated, so i’ll be able to create setup similar to yours.
@kvitekp I think there are two changes that might make sense:
1. Always send MIDI Clock messages regardless of the playback state of the master device.
Even though this is not required according to the MIDI specifications, it is also valid behavior and has the benefit of allowing slave devices to set tempo before playback is started and of allowing slave devices to continue to sync after playback is stopped which can help with tempo-based effects such as delay. I can’t think of a device or situation where always sending clock would be a problem, but maybe I’m overlooking something.
2. Disregard the time interval between two subsequent MIDI Clock messages when a MIDI Start or MIDI Continue message is sent in between those messages. This makes sure that there’s no negative impact on the tempo detection for master devices that “resets” clock when the play button is pressed.
Please note that you probably only want to do this when playback has previously been stopped since according to the MIDI specifications, a slave should ignore MIDI Start or MIDI Continue messages during playback.