I just stumbled over Streamdeck, which looks like a incredible useful device for increasing the workflow efficiency. Basically it’s a USB device with 15 pressable buttons (so you get a tactile feedback) that have LCD displays beyond them:
It’s main target group is gamers, but it can be super useful for us audio folk too:
DAWs or audio editors
transport buttons that start blinking on playback
hotkeys that are greyed out if unavailable
Plugins
toggling boolean plugin-parameters
key-switches for switching articulations / presets
There are already some APIs available, but they are for node.js and C# (.NET), so I figured having a JUCE module that wraps the functionality in the JUCE style would be awesome. I’d imagine something like this:
class StreamDeckListener
{
// Notifies your class when it gets the focus
virtual void streamDeckFocusGained() = 0;
// Gets called when the user presses a button and your class has the focus
virtual void streamDeckButtonClicked(int index) = 0;
// Draws the icon for the given button
virtual void drawButtonIcons(int buttonIndex, Graphics& g) = 0;
// Locks the Streamdeck to this class and prevents other Listeners to grab the focus
void lock();
};
I am willing to write this module and publish it under a MIT license, so if anybody is interested in this, please second my request for a simple C API to the company so they know that’s something people are interested in.
Thanks for the find. I can’t believe they market this to streamers :o. Isn’t it just a lcd keyboard like the much hyped optimus maximus? It would be amazing for apps like sibelius or blender to replace the numeric keypad.
Yes, LOL I didn’t even know what streamers are. Last time I heard this word was for the markers that appear on the film for conductors to synchronise the orchestra to the screen way before the digital area, so I guess that’s how you realise you get old
I noticed there is already a general purpose USB interface library from the company called hidapi and with this and reverse engineering the node.js library to get the magic numbers that talk to the device we’re almost there.
I think I’ll use a separate process and use the InterProcessConnection stuff to talk / listen to the device. This allows multiple plugins / applications to communicate with each other and lock / unlock their focus.
This is looking like an attractive option again, with the new Stream Deck Plus that now includes knobs. @chrisboy2000 did you ever get anywhere with your JUCE module idea?
I looked into this a bit more. It seems that Elgato provides a single C++ example in their SDK (the “CPU” plugin), and that they don’t distribute a C++ library separately from that example code.
Thankfully someone made a reusable library out of it, here, which would probably be a sane starting place for a JUCE wrapper:
All that said, the SDK does not yet support the dials which are the new marquee feature of the Stream Deck Plus, so those aren’t reachable yet.
+1 for Stream Deck support! Got one on my desk and wouldn’t want to miss it. Using it for Visual Studio and Cubase Actions mostly. I consider it a general purpose productivity tool.
If anyone would do some groundwork in combination with JUCE, I’d totally welcome it.
From my user experience, it works a little better on PC than on Mac, probably due to the ways the host software interfaces with the OS - Windows was always very liberal when it comes to OS hooks (scaringly so, tbh, last time I checked a lockscreen-compatible keylogger was like 20 lines of code).
I could also imagine the stream deck as a debugging helper, in particular if there is a easy to use juce module. Mock up StreamDeckListener interface looks good.
Now seeing that the original post is from 2018. Well… Would still be cool!
I programmed a stream deck plugin with juce a few months ago and I have to say, working with the StreamDeck SDK was a pain in the ass. Working with JUCE is like flying on a cloud with the classes like String that do all the work for you and having the asserts all over the place to prevent you from making stupid mistakes – vs the StreamDeck SDK which sent me back to reading sensor datas with a micro controller.
Having a well thought out JUCE module would be awesome and might be something that would boost the StreamDeck plugin market. Last I checked the plugins were more or less nice to haves than really useful stuff. I think that’s definitely partially because of the SDK which isn’t that good documented after all.
Thanks for sharing your experience with making a Stream Deck plugin. Were you using that fork of the StreamDeck CPP code that I linked to above? Or just the stock SDK code that Elgato provides?
Wow that new Streamdeck Plus looks nice and I can see many applications for audio related stuff with the encoders.
However I think in order to make it useful the SDK has to support the knobs and the touch display so as long as this isn’t implemented on the SDK side we’re pretty much at the state of my original post from 2018.
There’s an official subreddit for the Stream Deck SDK, and an Elgato staff member posted an update there about the upcoming SDK updates with knob support – in short, not ready yet…
In the meantime, I wanted to get a handle on how I’d approach the problem in a general sense. In a different thread, someone at Elgato posted that “We don’t provide APIs to directly communicate to the device, neither documentation of the USB protocol, as they are subject to change at any time.”
So that would seem to preclude the original idea in this thread, of making a JUCE wrapper for a direct connection to a Stream Deck device. Instead, you’d have to create a plugin that works with their Stream Deck app.
It would be totally fine to write a JUCe module wrapping the stream deck SDK. As I said before, the SCK isn’t much soffisticated and for a production app, you’d need to wrap the shit out of it anyway. JUCE would just help create a level playing field.
The GitHub SDK is basically any demo plugin with the stripped away demo. Every demo plugin contains the base SDK in a separate folder. Doesn’t really matter where you start
Ah, OK. My initial read on the SDK was that there was only one demo plugin provided that was written in C++ (the “CPU” one), and that the rest were in Javascript and other languages. But like I said, I haven’t really dived in yet.