@matrix12x Clock usually gets worse when you start sending out other messages. I’ve never seen it that bad thoug; most devices seem to prioritize the clock messages over the other ones.
I once implemented a midi clock output on my sequencer and I prioritized the clock messages over the other messages by inserting them at the right locations in the midi stream. That had the weird side effect, that arpeggios on the connected midi devices broke entirely. The problem was that all notes of a chord must be sent before the corresponding clock message, otherwise an arpeggiator will start playing only the notes it currently has received. When you want your arpeggio to go down and you send three notes c - e - g then your clock message might be inserted between the e and the g. Now the apreggiator will play e - c - g - e - c - g - e - c … which is not the g - e - c - g - e - c … you actually wanted.
So - long story short - it is actually better not to prioritize clock messages when you also send tight note messages.
Here are some tests I did recently on my new late 2016 Macbook Pro (3,3 GHz i7) running macOS 10.12.4 using an ESI MIDIMATE II interface:
BitWig Studio 2.0: <0.981%
Maschine 2.6.2: <1.059%
Ableton Live 9.7.2: <1.122%
All programs were running a new, empty project at 120BPM. Testing was done in max mode reading out the value after keeping te sequencer running for a full minute.
Bitwig kept steady at 120.0 BPM, Both Maschine 2 and Live dropped to 119.9 BPM a few times.
I’m a bit surprised that performance is worse than on my older MacBook Pro and worse than on the first generation 12" Macbook in this case. I’ll investigate.
New 22.214.171.124 BSP Firmware released today.
Much much improved internal MIDI clock precision and stability.
Good job Arturia.
< 0.1% up to 160 BPM
< 1% up to 300 BPM
Well done, Arturia !
Since we are now using Discourse, we could use the built-in WIKI feature, which would let anybody edit the main post (I think trust level 1 is enough for that). This way we could collect all the data in one post and everybody who contributed could update data as new one comes in.
What do you think? I can create such a WIKI topic if you want.
Hell ! It’s about time…
The MIDIbro doesn’t have the 24CL512 by default, but has space on the board for one.
Comparing the schematics, the MIDIgal has an extra capacitor across pins four and eight of the eeprom chip, I guess to stabilise the power supply. It shouldn’t be too hard to add that even when there isn’t a space on the board, but is it necessary? Is the lack of capacitor in the Bro an oversight or is the Gal overly cautious?
The other obvious difference is the extra button. Easy enough to connect electrically but it might be a challenge to find space in the casing!
Depending on the length of the jumper wires you will use to hook up the EPROM chip and their location, the decoupling capacitor may a must add. I’d add it anyway because it’s a good practice to have one for every digital IC to ensure stable operation.
Given the space limitations and necessity to drill the fragile plastic case, i’d recommend building a MidiGAL and leaving MidiBRO to run MIDIpal firmware…
There is actually a specific space on the board for the Eeprom, it just didn’t come with the kit as the Pal firmware doesn’t use it. So no jumper wires for that, but it shouldn’t be too hard to add the cap anyway.
You’re right about the difficulties regarding the switch however… But I think I’ll still try! I can plug the button onto the programming header at least temporarily.
(naturally a second device would be better, and if I was making another I would order a board from you. Maybe some day, I have my eye on some of your other little MIDI processors)
Quick update on MIDI timing testing.
Just took my old Kurzweil XM-1 ExpressionMate processor out of storage to put it on sale (in case someone is interested). Kinda disappointing for an old yet powerful beast:
1.38% @ 075 BPM
1.90% @ 120 BPM (120.1)
2.90 % @ 150 BPM (150.1)
4.00% @ 200 BPM (200.3)
0.78% @ 500 BPM (499.8)
It goes up to 600 BPM but the MidiGAL can’t cope with that
New version of MidiClock firmware is available – it’s a complete rewrite of the original MIDI Clock Tester implemented in MidiClk firmware. This resulted in improved precision, accuracy and better repeatability of tests. There is also a new feature added: ability to measure BPM by analyzing a stream of 1/4, 1/8, 1/16 and 1/32 notes. This adds a new and interesting dimension in testing your music hardware and software.
It turns out that some MIDI devices and software sequencers have note stream more stable than the MIDI Clock stream. See, for example, Arturia Keystep stats:
MidiClock 1.01 firmware download:
BTW, there is also a new MidiSync firmware – this one does what MidiClk’s Clock Generator mode did, but better and with some additional functionality. Available here:
@ foksadure BTW, MidiClock goes all the way up to 999 BPM – tested with Albleton 9 running on a Mac with mio10 MIDI interface:
Ableton Live 9.7.7 on a Mac with iConnectivity mio10
BPM Clock 8th
20 0.291% 0.050%
60 1.119% 0.061%
120 2.370% 0.098%
150 3.015% 0.135%
200 4.603% 0.166%
250 5.562% 0.172%
500 11.879% 0.369%
999 27.780% 0.708%
quick question. Can I run MidiGal firmware on a midiPal? If not is it fairly easy to mod for this to happen?
Thank in advance
Yeah, you could run MidiGAL firmware on a MIDIpal, however, since the latter has no switch and its LCD has only one line, you wont be able to do much as all MidiGAL firmwares require 8x2 LCD and a switch action.
Hacking on a switch and replacing the LCD is totally possible.
Ah nice thanks for clarifying. I might wait till it arrives and see if I end up modding it after some use.
I bought a Midibud from you back in the day and I’m very happy with it.
The thing is that I bought a Volca Sample recently and I was hoping to be able to trigger samples individually using Midibud because as you may know the volca sample uses a weird midi implementation where each sample slot (10) has it’s own midi channel.
I tried to use midibud’s dispatcher but it is not working for this because of not being able to map a particular note to a particular midi channel.
Is there any other option via filtering or so that I could use the midibud to drive my volca?
And a last question, custom midi rules could do the job, but there are only 4; is there any way to have more rules? I would need to have at least 10, obviously. Is this because a hardware limitation?
Could the firmware be amended to remove some features and have only custom midi rules?
Thanks in advance for your help!
Have you seen this?
I don’t think there is any firmware for MidiBUD or MidiGAL that would convert a note to an event on a particular MIDI channel.
Mutable Instrument’s MIDIpal firmware is in maintenance mode, so I doubt anybody will be up to looking into updating it to support more rules. MIDIpal firmware was designed to use MIDIpal hardware to its maximum, so I doubt one could easily increase amount of supported user programs.
Thanks both for your response!
What I’m trying to do is to remove features and re-compile it leaving only the custom filters trying to expand the limit of 4 filters as I assume this limit is because of the rest of firmware features, I was checking the source code and I think I’m going to try to modify it.
Will post the outcome of my attempt!!!