Can you hear me now?
So while the ideas are still flowing around the physical layout of the controller, it’s becoming pretty clear that a robust center channel approach with lightweight fader banks will be the way to go. So much to determine still.
So I’ve switched over to getting some of the hardware working. I wanted to get a unidirectional (from physical interface to Reason) communication channel established between the prototype board and the Reason software, over USB MIDI (as this will be the actual interface type used for the final product).
Step 1: Get buttons working on a microcontroller
I’m a huge fan of the PJRC Teensy boards, which are super capable, very inexpensive, and were pretty much designed for amazing audio, video, and LED type projects. So it’s a perfect prototyping platform, and may even be a preferred production platform.
So first, the idea is to get the Teensy brought up and responding to button presses. This is essentially the “hello world” of hardware, next to making an LED blink.
For this first run I have either button press turning on the onboard LED. This lets me confirm immediately if I have a solid operating platform between MCU and button.
Here’s the breadboard laid out. Note that though I have the bargraph LEDs and the touchscreen TFT display on the board, they aren’t hooked up yet.
And here’s the code used to just get the buttons working–nothing crazy, pretty straight ahead stuff.
And with this, I can see the LED on the board light up upon either button press, and it turns off again the moment I release the button. Perfecto.
Step 2: Get the MCU to show up as a USB MIDI device
Easy enough due to the built-in USB MIDI capabilities, so we select it in the dropdown menu, and confirm that it enumerates correctly within the OS:
aaaaand, looking good!
(The Teensy defaults to that USB name–will modify it later, first we just want to see everything work!)
Step 3: Send a MIDI message to control a Reason parameter via Reason’s Remote Override functionality
This step lets us confirm that Reason can indeed read our MIDI messages correctly, enough to recognize our little device as a MIDI hardware controller, and to accept remote override messages.
Let’s first load some code onto the MCU to allow for the sending of actual MIDI note-on/note-off messages when we press either of our two buttons:
Now we set the remote override on a recent Reason project I put together for a friend:
And now we press the button and it’s mapped!
Now for the moment of truth:
Up next: Getting messages coming out of Reason and into the controller
I was hoping I could also quickly prototype the receipt of messages to the hardware without getting into the details of the Remote protocol, though it appears if I want to get any bidirectional communication working at all, I’ll need to do it with Remote.
Tis okay though! The Remote codecs are pretty straightforward Lua scripts, and the Remote maps are just text files. Lots of examples in the Remote SDK.
Goal for next time will be to get that bargraph on the breadboard bouncing along with an actual channel’s level.