[Pete] admits that his MIDI-based slide advance alert system is definitely a niche solution to a niche problem, but it is a wonderful example of using available tools to serve a specific need. The issue was this: [Pete] is involved in numerous presentations streamed over video, and needed a simple and effective way for the Presenter to notify the Producer (the one responsible for the video streaming and camera switching) to discreetly advance slides on cue.
To most of us, this is a simple problem to solve. Provide the presenter with a USB macro keyboard to trigger the keyboard shortcuts for slide advancement, and the job’s done. But that didn’t quite cut it for [Pete]. In their situation, the Producer is managing more than just the slides as they switch between cameras, watch the chat window, and manage the video streaming itself. Triggering slide advancement via keyboard shortcuts only works if the presentation software is in focus when the buttons are pressed, which isn’t guaranteed.
[Pete’s] solution was to make a small two-button device (one button for next slide, one for previous slide) that uses MIDI to communicate with a small custom application on the producer’s machine, and doesn’t care about application focus. Pressing the slide advance button plays a distinct tone into the producer’s headphones, plus the custom application displays “Forward”, “Back”, or “Waiting” in a window, depending on the state of the Presenter’s buttons. The design is available on Instructables for anyone wanting a closer look.
[Pete] reports that it works and it’s far more discreet than saying “next slide, please” twenty or more times per presentation. You may notice from the photo that LEGO bricks play a prominent part in the device, and if you’d like to see more of that sort of thing, make sure to check out these other brick-mountable PCB designs.
“small custom application on the producer’s machine”
Why doesn’t it just post keyboard shortcuts into the presentation’s software keyboard queue? Just because he likes messing with producer?
Hi Robert, maybe I don’t understand what you mean by “the presentation’s software keyboard queue”… The issue is that the presentation software has to be the frontmost application or key commands will not be captured by it. Since we’re running multiple applications any one could be frontmost when the button is pressed and then that won’t work. (Or did I miss something?)
You could use the detours library to hook into the presentation software directly if it’s windows software. There’s similar libraries that should allow you to just send keyboard commands to the window. I used autohotkey years ago to send commands to a program running, I think it’s still in development, but, if not, there should be some comparable automation software that can send commands to a window, regardless of if the window is in the foreground.
I’ve got a ton of uses for a little macro keyboard but I never know which keystrokes are safe to send. Midi seems like a reasonable intermediate point between a hid keyboard device and a totally custom USB (even usb hid) protocol. Though to be fair, abusing USB hid for generic packet-based communications with a device isn’t hard, especially if you choose to completely ignore the concept of hid device descriptors.
Now, if somebody can help me figure out how to extract and expose application-specific “mute” status from a variety of video call apps, so I can make a hardware mute button for calls that knows the mute state (and can interact with things like host-applied muting), I’ll be really stoked 😁