Yes, the leonardo identifies itself to the machine as a keyboard.
So i’m sending the keyboard commands as a normal keyboard would to the client.
The streamdeck sends commands through OSC on the network.
The client pc get a network from the usb network adapter and that’s connected to the pi through a network cable.
The whole thing is transportable and movable between machines. Also it only needs a single usb connection (can be through kvm if full usb is supported).
I’m new to CCG and is currently exploring my first hardware build running win10/decklink duo 2/ATEM tv hd… A few days ago I had a setup like this running. I had a Contour Shuttle V2 triggering Companion which then would send OSC commands to CasparCG client. - Unfortunatly it never became stable. - something periodicly interrupted and stalled the comms. I would have somewhere between 10 - 15 good commands. Then the response-time would be several seconds (3 - 10 seconds) before execution happened on the client. VERY frustrating sence everything was communicating. - I had to skip the buttons for the show and click my way through it on the client interface. - Would love to share experiences.
My goal is to, in a simple way, fire off ATEM macroes, switch and modify layers on CCG with one button press. It worked fine by triggering groups of commands using the UID remote triggering within the CCG-client. But just not in a stable usable way. - I’m still investigating.
The ATEM / CasparCG combo is a power house in unison. Hope to get it stable.
Any input would be greatly appreciated.
I have a Cherry 142 key keyboard, connected via USB to Raspberry PI, running ‘node-red’, from which I can send OSC commands or ATEM commands via the network. The keyboard is very low-cost compared to the large X-Keys keyboard. Each key is not lit like on the X-Keys product, but, did I mention that it’s very low cost compared to the X-Keys?
The cost is typically less than $120.
Cherry keyboard is this one: https://www.neweggbusiness.com/Product/Product.aspx?Item=9SIV1DSD5E1004
I also have it monitoring output data from the ATEM video switch, so that it can get the names of the macros, and in the node-red side, have the ability to use the macro names instead of macro slot ID’s to identify them.
Another possibility is to expose a set of OSC commands, and use software like open stage control, and create a web browser based button UI, which means you can now have a push button interface that’s usable from any tablet, and the UI can be responsive in terms of labels and color changes etc, and, can be accessed via network too.
Potentially, you can create something that lets people do pre-programmed things, and only do those things. eg: you can create a panel that gives not only ATEM and CasparCG control, but other things too, such as PTZ camera memorized location recalling etc, so that other people can use it without having access to the actual equipment.
Could ‘companion’ take the place of ‘node-red’? Perhaps.
The main problem with using the USB keyboard is that on a PC, the keyboard is meant to provide input to the active application, like any other USB keyboard. I did not want to have to sit in one program all day, and be unable to do other things, so I use a raspberry PI to have the node-red and keyboard, and let that just do keyboard and node-red, so does not tie up an entire computer. Raspberry PI can run headless, with nothing but network and keyboard connected.
I had to get a bit ‘creative’ to pull key presses from the USB keyboard into node-red as a source of messages (python to read via usb library and emit key press data via stdout).
Perhaps companion would have other ways to do that too. But, the utility of being able to write custom javascript code within node-red and do things like collect names and IDs of macros from the ATEM switch is also quite useful, and may let you do other things that Companion might not. I suppose it’s also possible to do this sort of thing in companion if you work at it enough.
Interssting idea, by the way the X-Keys are not lit, at least mine is not. What I like on the StreamDeck keyboards (and Companion) is, that the keycap can change based on the context. If you want to build stuff on your own, there are also a few libraries around, that allow to program the Streamdeck and even play video on the key caps, if you want. What I specially like with Companion is, that it supports most of the equipment you can think of. So it’s easy to do some ad hoc setups without programming a lot. But that seems to be the same with Node red.
Yes, the stream-deck is very nice in terms of what you get, especially the ability to animate/update the content of the buttons in real time. But, I prefer to not having to navigate into/out of menus for live switching control. I don’t mind having the ATEM switch status/control app visible, I just don’t want it to also tie up the keyboard/mouse too. And, yes, multiple XL’s would be nice, but, I’m also trying to keep costs down. The Cherry keyboard is way less than the price of the large X-KEYS keyboards from what I can see, and half the cost of a single stream-deck-XL. And, beyond that, the web-based ability is there too, using open stage control and/or other osc-capable platforms. All of this stuff is highly dependent on what you consider a priority. I’m mentioning what I am doing so others looking for similar will know it’s possible.
It seems that for the X-KEYS 128, there are individually addressable blue and red LED’s, which certainly would add another layer of indication as to what’s happening, potentially, to users.
I’ve used XK-16 with node-hid on Raspberry PI for standalone controllers for Atems. One cool thing you can do with the blue and red LEDs if you have a button that has two states (like KEY1 ON/OFF) is to print on transparent overlays with blue text on a black background and blue text on a red background to change their “text”.