We live in a golden age for MIDI controllers. [rheslip]’s contribution to the milieu is a twisty take on the format, in that it’s covered in an array of knobs. Thus the name—Twisty 2.
The controller can be built using the Raspberry Pi Pico or Pico 2. It’s set up to read a 4×4 array of clickable encoders, plus two bonus control knobs to make 18 in total, which are read via a 74HC4067 analog mux chip. There’s also an SK6812 RGB LED for each encoder, and an OLED display for showing status information. MIDI output is via USB, or, if you purchased the W variant of the Pi Pico/Pico 2, it can operate wirelessly over Bluetooth MIDI instead. The controller is set up to send MIDI CC messages, program changes, or note on/off messages depending on its configuration. Flipping through different modes is handled with the bottom set of encoders and the OLED display.
Few musicians we’ve ever met have told us they learned how to play the encoders, and yet. The cool thing about building your own MIDI controller is you can tune it to suit whatever method of performance strikes your fancy. If the name of this build alone has you inspired, you could always whip up a MIDI controller out of a Twister mat.
did we just switched to OSC with a best practices document by IFACCA yesterday or are we still at 128?
Indeed, you could just as well say we live in the golden age of QWERTY keyboards. MIDI is still stuck at 7 bits and 128 controls since 1983(!), while OSC sits there with UDP multicast glory waiting for DAWs to catch up. Nice knobs tho.
I can speak for the wired MIDI, and in the wired world MIDI 1.0 is one standard where speed is not terribly important. As long as your target hardware can reliably react within ~7ms total/combined timeframe, it is fine, the delay is hardly noticeable.
(in my humble experience, even 10ms was fine, though around ~12ms it becomes decidedly noticeable, especially in multitimbral, ie, multiple keys pressed at once, messages, because it slows down to maybe >17ms due to the large number of simultaneous/concurrent messages being sent).
MIDI 2.0 mostly addressed other things, blinkie lights, etc. It added speed constrains, too, because hardware in general had progressed, however glacially, but otherwise it is perfectly fine with the MIDI 1.0 speeds. MIDI 1.0 had another issue, error rate wasn’t that grand to start with, and it is rather not very well error-compensated standard, both 1.0 and 2.0, since it meant to run on the rough equivalent of Arduino Nano.
As a side note, I never understood why MIDI wouldn’t allow parallel wires and some kind of simultaneous transmission of the same signal twice or trice, thus, allowed for speeding up and improving the error correction. If I remember right, out of the 5 pins in the DIN connector, only 3 are almost always are used, (though, the original standard calls for all 5) quite a potential being wasted.
As an engineer, I can say that MIDI can be done in parallel–in other words, a MIDI controller/sender can send the same MIDI signals to multiple devices, but they will, of course, all respond to the same information (though they could respond differently). The controller would need to have been designed with multiple MIDI Outs, though. But, those Outs could send the same information, only each will provide a separate buffer for driving the serial line.
ALSO, a MIDI controller could even, in parallel, send MIDI to various MIDI Outs but with different information–simultaneously. That would more likely be a sequencer, right? And in fact, it wouldn’t even be necessary to do it on different channels (or all could be Omni). OR, there could be different “sections” where one MIDI Out would be a section, and it could control instruments or devices on various channels, then a different section on a 2nd MIDI Out using the same channels but controlling different instruments/devices. This would be a way to control a whole “orchestra” of MIDI devices and do it without incurring the delays of trying that with one long serial chain.
It’s really all a matter of how the controller is designed. But, the point is that MIDI can be done with a certain amount of parallelism.
I’m sure you realise this, but what you are describing is equivalent to network collision domains, an issue that was ultimately addressed by hardware bridges, then every port being bridged in switches.
The same approach can be used similarly to what you describe, using a bit of hardware at endpoints to take midi, apply hamming encoding, then forward to an mcu, turning midi into an asynchronous network, complete with crc, while only introducing a few ms delay on output.
Hardware audio is strange especially in lower budget. Some samplers still offer memory measured in MB for sample storage and digital synthesizers have like few voices and no multitimbral.
It’s not wireless if you have to plug in a wire to make it work. ;-)
There is an updated enclosure on the Github link that has provisions for a Lipo charger. Alternate sequencer code running on the wireless version https://www.youtube.com/watch?v=RM_LAcxyHQQ