[sdiy] MIDI velocity

[rsdio at audiobanshee.com]

These are all fun an interesting questions.

Every different implementation has its costs. For this comparison, I'd say they're probably equivalent. When I said "counter-productive," I should have clarified that it's only "counter" if you expect to have a firmware advantage. The wiring is counter-productive in terms of hardware costs, but the firmware is probably a wash.

For a 1 MHz 8-bit processor (1 MIPS), or even a 48 MHz PIC (12 MIPS), the matrix switching time is so fast that it's finished before the processor can execute the next instruction. I've never had to insert wait states with a switch matrix, thanks to using appropriate sequencing of the operations in the interrupt routine. For example, you can read the previous matrix row bits at the start of the interrupt, and then change the column outputs at the end. That way, you have the entire wait time (1 ms) between scan interrupts for the lines to settle. Even long wires do not add significant time when scanning at 1 kHz. With 16 columns, your signals would only be 16 kHz, and that's a very low frequency for a processor.

You do need to make sure that you don't have large capacitances on your matrix lines. Small capacitors might actually help smooth out any switch bounce, which is a good thing, but I've seen many examples of commercial prototypes or early production revisions where the filter caps were too large by mistake, and this caused problems. That's way more likely to be the source of any problem than the length of the wires. Sometimes, especially if you're using FET switches, the Gates can act like capacitors. The diodes can also act like capacitors. Both are relatively small capacitances, but they're worth considering in your design.

With a GPIO approach, you either need a way to address GPIO ports using an array index, or you need to unroll the loop and use hard-coded GPIO port register addresses. Both of those approaches require more processor cycles than simply reading the same port address every time. Depending upon your processor and the order of the GPIO registers, it might not even be possible to use a standard loop. I know for a fact that the PIC would not allow easy indexing of GPIO ports, because it's instruction set doesn't allow much in the way of indirect addressing. What indirect addressing is available uses way more instruction cycles. So, you need to unroll the loops if you have a different GPIO port for each set of keys. This ends up costing more in terms of Flash memory, even if it doesn't cost more in terms of execution cycles. The switch matrix design allows for simpler code, and although that's not a goal, it does help make the code both faster and smaller and easier to understand and maintain.

All in all, no practical difference other than the number of pins on the connector. Note that I forgot to include ground in my pin counts, so that would be 123 pins dedicated versus 25 or fewer pins in a matrix (although you might be able to skip ground in some matrix circuits, since the row and column nets could provide a complete circuit). For each type of processor, though - e.g. ARM versus PIC - you might find one or the other has a slight difference in instruction cycle counts. But I predict that it would be less than an order of magnitude difference in any case. Nothing to worry about.

And when I talked about the number of "wires," I really meant the number of pins on the connectors. Even if it's not manual wiring, it still costs more for larger connectors and wider ribbon cables or other multi-conductor cables.

By the way, if you design 4 MCU boards with serial I/O between them, then you're adding latency for the serial re-transmission of key events between each MCU and your master MIDI output. If you're worried about 1 or 2 cycles for matrix settling times, then you really ought to think about the 10 to 30 cycles (or more) of latency caused by queuing messages from one MCU to another over a serial port. I'm not saying that anyone would hear this latency, but I certainly wouldn't design a 5-MCU MIDI controller to avoid 1 or 2 cycles of delay that might be needed in a single-MCU design with matrix wiring. Besides, a 5-MCU design means you have to write more than one firmware, and that always takes more development time than writing a single piece of firmware for a single-MCU design.

There seems to be a tendency these days - both at the DIY level and the professional level - to design with multiple processors instead of a single processor. I think the biggest reason is that processors these days are almost as cheap as discrete logic was in the vintage synth days. However, I think that everyone from the hobbyist to the manufacturers in the industry underestimate the costs of developing and maintaining firmware. The more processors you have, the more the firmware costs. Everything I've read in the industry says that firmware is, by far, the single most expensive part of the development cost. So, now you may understand my bias towards matrix wiring and single-processor solutions, where feasible.

Brian Willoughby
Sound Consulting


On Apr 6, 2016, at 1:08 PM, sleepy_dog at gmx.de wrote:
> As for "what's the difference" (1 GPIO per switch vs. matrix):
> Matrix switching does cost some extra time, no? I don't know how much to make sure it all settled enough to do clean measurements... but with somewhat lengthy traces or even wires of an existing keybed PCB (and diodes also adding penalty?), perhaps significant, I haven't done the math or sufficient experience to tell off the cuff.
> Maybe you could comment.
> So, with GPIO approach, you would have a few cycles each for reading anc testing ports. With matrix, you have extra cycles for switching the matrix, then perhaps 1..2 cycles waiting, to make sure the probably slower than your MCU switching of the external mux ICs is done, before reading the ports...
> Maybe it doesn't really make a practical difference :-)
> 
> Wiring 122 dedicated wires:
> Sure, I wouldn't have done that, use actual wires & connectors for that approach. If it was possible / easy enough, I'd have replaced or attached to the PCB in the keybed, maybe with 4 small 48pin MCU boards in 4 places along the keybed, tapping onto the PCB with managable connctors.
> No manual wiring, and no actual wires. My end connector would have been serial I/O, that'd be a small enough connector :-)
> 
> I might get back here if, some day, I have time (TM) to build my own Allmighty MIDI Monstrosity with the Fatar bed and all the Alps faders I have lying around :-D
> 
> Steve
> 
> Am 06.04.2016 um 20:30 schrieb rsdio at audiobanshee.com:
>> As for the idea of hooking each key to its own GPIO, that approach is counter-productive if you think about the actual firmware. Even with a 32-bit processor, the largest GPIO port that you can read would only be able to deal with 16 keys (velocity needs two switches). Then the firmware would loop through each port and would still need 4 iterations to handle all keys. How is that any different from having 4 columns in a keyboard matrix? Then, if you consider an 8-bit processor instead of a 32-bit ARM, your GPIO ports get smaller and the loop iterations increase to 16. Basically, from a firmware point of view, it's no more efficient to loop through separate GPIO ports than it is to write the column bits and read the same GPIO port on each iteration. I realize that someone already pointed out that standard key beds are already wired for matrix access, but I wanted to illustrate how both approaches require a loop that processes only a subset of keys at a time.
>> 
>> There's also the consideration of wiring between PCBs. Discrete GPIO would require 122 dedicated wires for a 61 keys with velocity, whereas the matrix can be done with 24 wires (16x8) or even 23 (12x11). DIY may not matter, but commercial designs probably want a 24-pin ribbon between boards rather than a 122-pin ribbon!