Advice on 3x Teensy 4.1 setup for full pipe-organ-style console MIDI conversion (Hauptwerk/GrandOrgue)

[pedrosolfer]

Hi all,

I'm converting a vintage home organ console (Conn Serenade 632, 2 manuals of 61 keys each, plus a pedalboard of roughly 25-27 pedals and an expression pedal) into a MIDI controller to play through Hauptwerk or GrandOrgue. The original tone generator wiring will stay untouched - I'm planning a non-invasive approach with new reed switch + neodymium magnet sensors mounted under each key/pedal, independent of the original contacts.

My plan is 3x Teensy 4.1 boards (native USB-MIDI), one each for Manual I, Manual II, and Pedal + expression, using a diode matrix to cut down on wiring.

A few questions before I start building:

1. Is there existing open-source Teensy firmware for this exact use case (matrix-scanned key sensing to USB-MIDI note on/off) that I could adapt, rather than writing the scanning/debounce logic from scratch?

2. For pipe-organ-style playing (no velocity sensing needed, just on/off), what debounce timing would you recommend for reed switches specifically, as opposed to mechanical keyboard switches?

3. Any gotchas running 3 separate Teensy 4.1s as independent USB-MIDI devices feeding the same computer (e.g., do they enumerate cleanly as 3 devices, any USB-MIDI channel/naming conflicts in Hauptwerk/GrandOrgue)?

4. Any experience with crosstalk between adjacent reed sensors when two manuals are stacked close together, and how you solved it (magnet size/polarity, shielding, etc.)?

Any pointers, example code, or past threads I should read would be much appreciated.

Thanks!

 

[jkinkennon]

Please have a look at https://www.kinkennon.com where I include code and gerber files for a number of boards for organ MIDI conversions. There is a matrix scan board that handles four keyboards, either 8x8 or 11x6 using a single Teensy 4.1. The matrix is actually a 22x16 matrix divided into four quadrants. It's all free so take a look. These designs are thoroughly tested on multiple organ conversions.

I have done lots of designs for driving lighted stops, solenoid based moving stops, Allen expression displays, and various adapter boards so feel free to inquire about unusual needs. I offer only limited support but will help as time and energy permit.

 

[MarkT]

For the reed switches if you have a 'scope you can investigate exactly how they behave and figure out a good debounce period... Without a 'scope you could write some Teensy code to measure the bounces even...

Thinking about the scanning, you could use upto 8 MCP23S17's to listen to upto 128 switches and use interrupts to detect changes rather than full scanning. That's one SPI bus (4 wires) plus the interrupt signals to handle. The MCP23S17 is available in DIP too...

 

[h4yn0nnym0u5e]

It’d actually cost more I/O to use the MCP23S17 interrupts than to poll the SPI bus! Plus, it only takes a single 32-bit transfer to read one set of 16 inputs; at 10MHz, the set of 8 will be done in 25.6μs (plus any overhead). You may as well poll it… Use two SPI busses, and get 256 inputs. That’s enough to sense the stop switches, too, if needed.