Rotary Actions for Emulator

[federicogartner]

Is this a feature relevant to companion itself, and not a specific module?

• I believe this to be a feature for companion, and is not specific to a module

Is there an existing issue for this?

• I have searched for similiar existing issues

Describe the feature

The Rotary action are available on Companion, however the only way to interact with it by actually rotating anything is with a device like the Stream Deck Plus living behind the emulator and web buttons for example.
It would be nice to be able to replace a button with a dial and perform rotary action with mouse to touch gestures on handheld devices. With help of GitHubs Copilot I just build a web server as a proof of concept: see attached file. Just like on the Stream Deck Plus, the rotary encoder or dial can continue to work as a button.

RotaryWebDesktopMobile.mov

Usecases

I actually own a Stream Deck Plus an I love it, but it remains on my studio. Rotary Action I use in a lot of application mostrily for audio, midi and no also controls Light at home. I would love to to open my emulator (as web app) on my phone a instead of pressing a button, being able to press and hold a dial and fine tune for example the light or color I want to have behind my Christmas three, or volumen on X device.

[thedist]

Just posting this here too as this feature request was also posted on Facebook:

The main issue with a feature request like this is not the actual coding implementation, as making dials that rotate is trivial and an AI generated PoC doesn't particularly help here (especially one that's just randomly it's own site showing what a rotating button is, rather than a PoC built on the emulator/web buttons). Some of the main issues are down to UX, for example you've shown buttons that you can click and hold and pull up/down, but what about pressing? How do you differentiate click and holding to grab the button from clicking to press it? You could be firing Press actions, or various duration group actions, by mistake. These are much more complicated issues to get right compared to the actual technical implementation.

There's also a lot of testing that would be needed around what sort of sensitivity would be ideal (eg, if moving the mouse 1px up or down triggers rotate actions then that could have a lot of errors due to a users control over the mouse, but too low a sensitivity could cause it to feel like sudden steps in changes).

[federicogartner]

• The SD+ also has a press function, and an on-screen dial can also have discrete steps and even sense acceleration for increasing steps value. I encourage having the dials also support press and release.
• I wouldn’t expect it to be easy or fast, hence the request.

[Julusian]

For me the challenge here is all UX, including how to set this up.
Should it always be just the bottom row? Or any row? Or maybe columns? Or choose each position individually? Opt in for an emulator, then anything which has rotary actions enabled would show it?

Then inside the emulator there is the question of how should it look. In that video you have the button bitmap drawn very rounded rotating as it gets twisted. I think that spinning will be confusing/annoying so probably wont do that. Should it be rounded still, or look the same as the rest? How else could it be differentiated?

And as Dist asks, how do we differentiate a press and hold from a rotate event? In both cases there will be a press and hold, and some amount of movement (for a press it is unlikely that the touch will remain perfectly still)

---

I'm not against doing this, but someone needs to do some UX thought/tests/research to figure out what would be a good place to start (or just do something).

Personally, I don't use rotary actions or emulators enough to look into this, and I think that our whole workflow of rotary actions is not optimal. But it works well enough for my usage, and I don't have good ideas on how to improve it so its pretty low on my list of things to look into

[federicogartner]

Hi, thanks for answering

How it should look

• It would be convenient if any button could be converted into a button/dial.
• Since the idea comes from replicating the SD+ encoders, the dial could be a simple circle, perhaps with subtle markings indicating the threshold angle required for a rotational action to be.

How do we differentiate a press-and-hold from a rotate event?

• What about splitting the control into a center and a ring? The center would behave like a button, while the outer ring would handle the rotation.

Another option could be to not support a pure “press-only” action, but instead use a press-and-release: if the minimum rotation threshold is not met, a press action is triggered on release. Would that be an option?

I can imagine having behaviours like in the example below with TouchOSC's encoder/dial, momentary/toggle, absolute/relative response, latch/unlatch.

Greetings and thanks for listening

Bildschirmaufnahme.2025-12-15.um.15.51.37.mov

[thedist]

If you make the buttons round, and with an outer circle, now you're omitting key parts of a buttons resolution as the button may be showing things like volume meters, or display text, which you'd now be hiding by cutting off the corners to make it round.

If you keep the buttons square, and have a ring around the outside, that starts to become unwieldly very fast as it'd no longer be a compact grid of buttons.

If you separate the rotation actions from the press actions by creating 2 separate objects then you're now going away from how Companion treats them within the main UI as a single thing, and also away from physical devices that have a rotary knob that supports push actions, and again it starts to become unwieldly if you have a lot of buttons.

Also in your video you've shown rotary controls that seem to have some sort of state as to their current position, or can grow/shrink, which is entirely separate functionality than what Companion provides as Companion just has actions that will fire when rotated left, and actions that fire when rotated right, so any sort of inclusion of what direction the rotary is facing, it returning to centre, or some sort of growing/shrinking progress state is far beyond the scope of just UI enchancements.