You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature
Hey folks. I'd love to see support for getting state information from Companion's REST API.
Companion's REST API currently supports interacting with buttons by sending GET requests to an endpoint (EG: curl localhost:8080/press/bank/1/1) which is useful for being able to trigger effects in Companion without a Streamdeck. On interacting with the API, Companion emits a simple ok message along with a HTTP 200 header. The routes available are all designed to manipulate Companion's information, which would then be surfaced to the Streamdeck and/or the Emulator. The Companion API does not support surfacing state information via the REST API when making changes or to update state on a system outside of Companion.
Companion could be super useful as middleware to interact between all of the devices it supports and other applications. This feature request is to add routes to support pulling button state (including forwarding feedback provided by the hardware it's interacting) via a new route (maybe say /get/bank/1/1), and returning button state via a JSON document when using the /press route.
Usecases
My current use case has me using a MIDI Fighter 3D to control a Behringer XR18 mixer. Companion runs on a server disconnected from my main machine, so I wrote a little piece of middleware that listens to the MIDI device events and sends requests to the Companion server. The MIDI Fighter 3D, like many other programmable MIDI controllers, has LEDs that can be programmed to change color based on events, such as a button's Feedback state. Getting state information from the buttons at startup, and then reporting the state change in the REST response would allow me to, say, change button colors based on mute state.
In a more general sense, this would allow other applications to use Companion directly as a method for interacting with hardware. Applications like OBS, vMix, etc, could be extended to interact with a mixer directly over web protocols. This could even serve as an integration endpoint for other control surfaces like what I'm doing to enable more control surfaces than just the Streamdeck without direct support added to Companion.
Thanks!
The text was updated successfully, but these errors were encountered:
Describe the feature
Hey folks. I'd love to see support for getting state information from Companion's REST API.
Companion's REST API currently supports interacting with buttons by sending GET requests to an endpoint (EG:
curl localhost:8080/press/bank/1/1
) which is useful for being able to trigger effects in Companion without a Streamdeck. On interacting with the API, Companion emits a simpleok
message along with a HTTP 200 header. The routes available are all designed to manipulate Companion's information, which would then be surfaced to the Streamdeck and/or the Emulator. The Companion API does not support surfacing state information via the REST API when making changes or to update state on a system outside of Companion.Companion could be super useful as middleware to interact between all of the devices it supports and other applications. This feature request is to add routes to support pulling button state (including forwarding feedback provided by the hardware it's interacting) via a new route (maybe say
/get/bank/1/1
), and returning button state via a JSON document when using the/press
route.Usecases
My current use case has me using a MIDI Fighter 3D to control a Behringer XR18 mixer. Companion runs on a server disconnected from my main machine, so I wrote a little piece of middleware that listens to the MIDI device events and sends requests to the Companion server. The MIDI Fighter 3D, like many other programmable MIDI controllers, has LEDs that can be programmed to change color based on events, such as a button's Feedback state. Getting state information from the buttons at startup, and then reporting the state change in the REST response would allow me to, say, change button colors based on mute state.
In a more general sense, this would allow other applications to use Companion directly as a method for interacting with hardware. Applications like OBS, vMix, etc, could be extended to interact with a mixer directly over web protocols. This could even serve as an integration endpoint for other control surfaces like what I'm doing to enable more control surfaces than just the Streamdeck without direct support added to Companion.
Thanks!
The text was updated successfully, but these errors were encountered: