[Moby Pixel] wanted to build a fun MIDI controller. In the end, he didn’t build it just once, but twice—with the aim of finding out which microcontroller was most fit for this musical purpose. Pitted against each other? The ESP32 and Raspberry Pi Pico.
The MIDI controller itself is quite fetching. It’s built with a 4 x 4 array of arcade buttons to act as triggers for MIDI notes or events. They’re assembled in a nice wooden case with a lovely graphic wrap on it. The buttons themselves are wired to a microcontroller, which is then responsible for sending MIDI data to other devices.
At this point, the project diverges. Originally, [Moby Pixel] set the device up to work with an ESP32 using wireless MIDI over Bluetooth. However, he soon found a problem. Musical performance is all about timing, and the ESP32 setup was struggling with intermittent latency spikes that would ruin the performance. Enter the Raspberry Pi Pico using MIDI over USB. The hardwired solution eliminated the latency problems and made the controller far more satisfying to use.
There may be solutions to the latency issue with the wireless ESP32 setup, be they in code, hardware configuration, or otherwise. But if you want to play with the most accuracy and the minimum fuss, you’ll probably prefer the hardwired setup.
Latency is a vibe killer in music as we’ve explored previously.
Beautiful build :-)
Wow. Riveting. I could not believe it confirmed the obvious smdh. Controller looks cool love the Bones sticker had that beast back in the day lol. In my experience with wireless midi there is too much overhead to deal with and just another possible easy fail point. Then there is how you handle the MIDI data which is where the secret sauce is (hint not midi nor serial) in cutting down latency. We will save that for another time though. In the end I preferred a cabled setup because I got tired of the usual gripes of wireless always losing host, scanning when it should be doing, remembering certain handshake modes, etc. I think teh google is giving us the techie feed too lol. 5th video on HaD that came up under my tinkering google login. I get them in my feed on YT and then three to six days later here it is on HaD lol. Go profiling :)
looks like the OG midifighter… https://www.midifighter.com/
He considered possible interference from Bluetooth devices, but he neglected to consider interference from everything else on 2.4Ghz.
My Bluetooth headphones cause an excessive latency for my mouse; effectively the mouse wanders drink when I go to click a button.
My headphones drop out when I turn on the microwave. Particularly anything when I’m listening to the TV on my AirPods while making dinner.
I live in an apartment and the 2.4Ghz wifi has so much interference in general that large data transfers are an issue on occasion. In those instances anything on Bluetooth tends to glitch too.
Bluetooth is great when you can tolerate slightly inconsistent behaviour on occasion. It’s downright frustrating if you need precision.
You need to fix or replace your microwave, it should not have that much leakage I would think.
And although I don’t use much BT so I’m not a good reference I don’t have such interference issue as you describe, which makes me think something is not right in your area, I would think something is malfunctioning .
Perhaps other commenters can tell us if they have such issues a lot.
my microwave is less than a year old and not a bottom of the barrel price is the most important thing ever model, but especially on the weekends when the kids want to watch some obnoxious kids movie and they fire that thing up for popcorn my BT headphones start to studder.
Its not the headphones either I have had some nice sony’s that did it (until one of the hinges broke) and my 30$ china brand ones do as well its the way the intel wifi BT combo is implemented on my cheap and cheery ASRock motherboard.
Doesn’t do it on my kid’s gigabyte board, doesn’t do it on my wife’s ASUS board but my specific B450 ASRock board stutters like Bobby Boucher receiving some advise whenever the nuke box is engaged (and this isnt my first board with them, but this specific model oh wow)
Wireless MIDI has acceptable latency where timing is noncritical. Imo the most stable and reliable MIDI hardware is the old school comm port stuff. USB and other protocols are as poor at handling MIDI as Bluetooth is poor audio quality and dropped packets. Unusable where timing needs to be perfect, like multitrack recording.
Up to 100 ms latency for bluetooth classic and as low as 6ms for bluetooth low energy. I wonder if they could just use ble instead and be happy as 6ms is like real time almost. When I did my tests I could not tell the difference between hard wired and bt wireless touchscreen. Let’s just say it seemed instant. You can see how fast it is in the serial monitor and serial readings have to be disabled cause they will crash a software serial monitor at that speed. Yep when it comes to close wireless ble is king
Edit* Yep when it comes to low latency wireless, ble is king!*
i’ve looked at the code: at line 65 :
0x80, // timestamp, not implemented
maybe it would be better if that was implemented. there would be less jitter at least. btw it’s quite weird to not know how to use a C array, copy paste 16 times the same block of code, using low level bluetooth stuff, not implementing timestamps, and conclude that bluetooth sucks…
i also prefer wired, but bluetooth is not that bad.
Those $1 315/433 MHz transmitter/receiver pills would do the trick here. Afaik they are pure analog fsk meaning no delay, low bitrate should be a problem for a keyboard.
Talking about music creation, I find I’m bad at making beats, no idea why, when I see it it looks simple but when I try I am not very good at it and it surprises me.
And using pre-made beats in music seems so fake. Even though most commercial popular music is obviously reusing the same beats over and over.
Apparently, the obvious isn’t that obvious to everyone. Communicating by basically shouting into the ether at 2.4GHz is not a process renown for it’s latency consistency (which should be obvious for anyone who’s been in a room with more then 2 people having a conversation), in addition to it happening over a protocol with a fair amount of abstraction overhead and driver/OS complexity, so the fact that the author of this didn’t see this coming is a bit scary. This should be very intuitive.