@kvitekp Oops, sorry. Just noticed that you already implemented 1. while I was typing my comment… I’ll give v0.93 a try tonight.
@kvitekp Sorry, I had an extremely busy week this week; I’ve only found time to test v0.93 just now.
Tempo is now detected on the slave device before playback is started, but the A4 (slave) can still end up starting out of sync, especially when playback is toggled rapidly. I think this is because what I describe under 2 in the messages above.
Here are the results with the Korg electribe2:
Oh well. I hope to test more gear in the future.
Thanks again to kvitekp for the MidiGAL. ;^)
Here is another project that runs on MidiGAL hardware: MidiArp, an advanced MIDI arpeggiator module that has all standard and a few unique features, such as very musical latch mode, super stable internal clock, nice swing and two modulation sources with velocity, after touch and CC destinations.
With these additions what started as a pretty ordinary arp implementation turned out to be a very useful instrument, equally suitable both for studio work and live performances.
Please check it out here.
I know I’m late to the party, but can the new Midi Bud firmware be updated via SYSEX, or do I need to use an AVR ISP?
I mostly use mine in dispatch mode or as MIDI CC and aftertouch filter.
Would it also be possible to have an added “layer” parameter in dispatch mode that would send the first note to both channel 1 and 9 , the second to 2 and 10, and so on? That way I can layer up 16 single osc synths into 8 two osc synth voices.
That is pretty much just a special use case for the Electribe 2 whose pad midi channels can not be changed on the device.
Yeah, the MidiBUD firmware v0.93 here has .hex and .syx variants. Note that if your device has MIDIpal compatibly loader, you’ll need to use midibud_pal.syx to update it.
“layer” parameter you’re suggesting does not seem to fit in what MidiBUD is doing, and MIDIpal covers that area perfectly.
You are right. I forgot that MidiBUD and midiPal firmwares are totally separate entities. I am currently running midiPal 1.3 on my MidiBUD. I will be sure to check out the latest midiBUD firmware as it sounds very useful.
The clear answer is to have two MidiBUDs.
I recommend to get MidiGAL with MIDIpal firmware v1.4 and use your existing MidiBUD to run MidiBUD firmware.
I asked in the midisizer.com comments, but I figured I would ask here as well. I can’t seem upload new firmware via sysex. My device has the initial MidiCLK firmware. I hold down the encoder and turn it on to put it into firmware upload mode. Then I send the sysex and see the MIDI IN light turn off, but it doesn’t blink for each received packet like I am expecting. Once the sysex send is finished, the midigal doesn’t reboot into the new firmware. I have tried this with these interfaces:
I know that at least a few of those interfaces have a history of not working well with sysex. I also have an Arduino sitting here that I could use ArduinoISP with to program the MCU directly, but I haven’t done this before and I would rather use sysex if at all possible. FWIW I have tried this with both the midiarp, midiarp_pal, and original midipal firmwares. Same story with all of them.
@hashbang Please try with Elektron’s C6 adding a delay of at least 250ms between each packet sent.
@t2k thanks for the reply. I should have mentioned in my first post, this was all done using the C6 tool with the recommended 250ms delay. I’ve also tried with higher delays (500ms, 1s). I’ve tried with Midi-OX as well, no difference.
M-Audio Uno works perfectly here… however, this is a 10 year old one, the rumor has it that the newer models have problems with bulky sysex data.
Are you sure that MidiGAL enters firmware update mode? it should blink both LEDs interchangeably.
New MidiClk firmware v0.96 is released. It adds Hold Mode (similar to MIDIpal’s Sync Latch app) and has greatly improved master clock tracking, which fixes problems with MIDI Clock sources that don’t send clock events when stopped earlier firmware versions had.
I meant to update sooner, but I was able to flash new firmware onto my MidiGAL(s). I ended up just using an arduino as an ISP programmer, and it worked with no problems. Thanks for the help!
Did some MIDI Clock testing on my Amiga 1200 today. OctaMED Pro 5.00c scores about 0.3% but runs at 119.9 BPM when it’s set it to 120 BPM. Music-X 1.1 scores a whoppingly bad 9% and runs at 120.8 BPM when set to 120 BPM. Bars & Pipes Professional scores 2.5% and runs at 118.9 BPM when set to 120 BPM.
Please note that I didn’t bother finding the most recent versions of these applications. I might try to get hold of them and run these tests again some day. Also, if anyone feels like sending me an Atari ST for testing…
To summarize, on the Amiga, OctaMED does pretty well while Music-X and Bars & Pipes are really, really bad at outputting stable MIDI clock. What’s interesting is that OctaMED has about the same level of clock jitter as Ableton Live on OS X.
Updated MidiClk firmware to 0.97 . It adds Sync24 output with two extra pulses: step and step count, both selected in the UI.
I got the same results as @foksadure above running the clock tester on the new Electribe. Here are my results so far testing at 120BPM in “max mode”:
Ableton Live, OS X, ESI MIDIMATE II: 0.4%
Ableton Live, OS X, Behringer UMC204: 0.5%
Elektron Analog RYTM: 1.4%
Elektron Analog Four: 1.4%
Korg Electribe2: 1.8%
MPC 1000, Original Akai OS V2.13: 3%
MPC 1000, JJOS3 V1.29: 3.1%
MPC 1000, JJOS2XL V3.47: 3.2%
Teenage Engineering OP-1, Kenton MIDI USB Host MkII: 3.3%
MPC 1000, JJOS1 V4.99L: 4.1%