@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 126.96.36.199 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)