@martindunne – how exactly are you uploading it?
midi with c6, i have done all other projects the same way, it looks like it is uploading, the midi in light flashes but when it is completed i get nothing. also the midibud.sysex i get no upload lights and had to resort to loading the hex file with isp programmer
midibud.syx won’t work if you MCU was flashed with MIDIpal bootloader, you need to use midibud_pal.syx in this case. However, if you flashed the .hex with ISP programmed, bootloader was erased.
Try to reset the device by powering it up with switches 1, 3 and 5 pressed down.
i loaded the hex and muboot . will give reset a try
you may want to try loading midibud.hex only… loading both bootloader and main firmware manually may be tricky.
I really love the tester mode; below you’ll find 120 BPM results from the MPC 1000 which scores a disappointingly 2.4% and Ableton Live running on OS X using an ESI MIDIMATE II “cable style” interface which scores a reasonably decent 0.4%. Can’t wait to test my other gear!
Ableton Live running on OS X is really impressive at 0.4% !
BTW, double clicking the encoder in MIDI Clock Tester mode will toggle “max” versus “current” standard deviation mode. This is helpful when you want to test MIDI Clock source over time because it will display the worst sdev over the entire observation period.
Hmm… looks a bit disappointing. At least it’s accurate at 120.0 BPM so you can “repair” clock for chained devices using Midi Clock generator mode.
Some more results; the Elektron RYTM and Analog Four both score about 1.4% at 120 BPM in Max Mode. When the clock in measured through the Faderfox PC4 pot controller, it goes up to 2% when you generate a lot of CC messages by tweaking the pots on the PC4.
All of these results are a bit disappointing, to be honest.
@kvitekp I might do a bit more testing to see if fixing the clock with MidiGAL makes any difference. I have a suspicion that it’s not going to improve much since all the slave devices I use already average MIDI Clock instead of slaving to it “directly” like older devices used to do.
While working on MidiClk firmware I hooked it up to my beloved Moog Sub37 (firmware v1.0.7) and was shocked to see its output MIDI Clock jitter at about 2% which jumped up to 5-6% when I used any of the panel controls… imagine the sequence running and you do that ubiquitous filter sweep ruining your clock.
Amos reacted quickly and greatly improved stability – it’s ~0.2% in v1.0.13 … however, it still degrades down to 2-3% when panel controls are used
@t2k – even if the slave devices average incoming BPM, they will still benefit from receiving coherent stable clock.
I’m working on advanced arpeggiator firmware for MidiGAL (which is called MidiArp btw) and while I was playing with Swing setting which can be regulated at 0.1% increments (with 100% being an 8th note) I found that I can clearly feel groove that appears at 50.1% setting (which is minimal forward swing setting in MidiArp). However, I can only feel it if the original clock is super stable… any jitter kills the groove immediately. Which is not surprising since numerically, 50.1% swing is measured by MidiClk as 0.198% standard deviation, so 0.2% is enough to mess it up.
Subinterger swing settings feel soooo nice, it’s the whole new world for me!
When I start generating a lot of aftertouch messages on the RYTM, I can get the jitter over 2.1% as well.
Just for fun, I just tested the USB MIDI output from the RYTM as well using an MIDI USB host box (Kenton MkII). This results in the exact same amount of jitter as when using the DIN MIDI out on the RYTM.
Interestingly, it does jump up to 6% once you start adding aftertouch messages, but I guess that kinda makes sense since USB MIDI does have higher bandwidth.
Still, to me it seems more sensible to prioritize clock messages over pretty much any other type of MIDI message, but maybe I’m missing something.
@kvitekp Would you mind sharing how you communicated your findings to Moog? I’m trying to figure out the best wat to communicate these results to Elektron so that they’re most likely to improve things.
Here’s another result from Ableton Live running on OS X, this time using a Behringer UMC204 as the MIDI interface. Still at a reasonable 0.48%.
Is the MIDI interface the only thing you have connected to the USB port? Would be interesting to see how it performes with an audio interface connected to the same USB port while recording (several channels) audio.
It’s only a two-channel in, four channel out interface. I would be surprised if that would make any difference.