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!!!
If you can code, the [MIDI] world is in your hands
Modifying MIDIpal is not trivial, you might be better off grabbing the MidiGAL testing firmware – it’s pretty easy to modify it to do what you need.
Hi ! Could the MidiPal run MidiSeq (and any other MidiGal firmware) if a switch is added ? I’m planning to add a panel mounted switch on mine, would the lack of eeprom be an issue ?
No. All MidiGAL firemwares require two line LCD, whereas MIDIpal has a one line LCD.
Thanks Peter ! Just theory crafting here but couldn’t a 2 row lcd be installed in place of the 1 row ?
You will also need to add a switch. Methinks it’s easier to build a MidiGAL rather than hack a MIDIpal.
Interesting readings about MIDI delays:
Scheduling Delays: most computer based sequencers operate on an internal time interval, usually around 2.5ms. If the tempo is accurate to several decimal places this technique is undoubtedly used
If I understand this correctly, that would explain why MidiGAL reports suddenly accurate timing on @25, 50, 100 and 125BPM on the electribe2.
Yes, this is consistent with the MIDI data being sent on a 1kHz timer (or a multiple of it).
>>> bpms = np.arange(25,200); fractional, _ = np.modf(1000/(24/(60.0/bpms))); bpms[fractional == 0]
array([ 25, 50, 100, 125])