Streamdeck + Encoder Rotation Stop

[Lukeb873]

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

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

Is there an existing issue for this?

• I have searched the existing issues

Describe the feature

It would be great if on the Streamdeck + there was a stop rotation action. Like the release action on a normal button. I'm not sure if this is possible given a button is a 2/3 step. Either a press, hold, or a release. But the encoder is just one rotation in a left or right direction.

Usecases

The idea comes from PTZ cameras being controlled on Encoders. Most PTZ cameras are set up so once you trigger a move, you need a stop move action after. Otherwise the camera keeps moving. On an encoder, there's not a way to easily stop that pan/tilt/zoom action because there's no stop. I could add a delay of a few milliseconds after the inital move command, but I found this worked inconsistently. Specifically when wanting to move incrementally or slowly. You'd end up cancelling the 2nd roation by the delay or get it stuck moving.

[spoelstraethan]

Do you have the encoder button "Rotary actions" enabled?

I haven't had any issues using the rotary encoder buttons on the Streamdeck Plus and/or the Razer/Loupedeck for volume control where for it changes the volume by x% per "click", and both of these devices have "detents" where you can feel the rotation happening.

[Lukeb873]

I sure do. In certain modules you can not do per click adjustments... A lot of PTZ cameras when you start a "turn right" command will keep turning until they get a "stop turn right" command. So on a button you just press and hold for turn right and then set a release action of stop turn right. On an encoder there's not a way to do this.

[dnmeid]

It is possible to fire an action when there has been a rotation left or right and then there is no more rotation for a certain amount of time. You can do this on your own by killing and restarting starting a delayed action somwhere else. If the rotation stops the delayed action will not be killed and fires after the wait time.
Technically it would be possible for us to provide that functionality right in the GUI in a "stop rotation" section, but I don't see this happening. The whole way of how we handle rotations is another example of: just make this feature available quick and dirty and we can change it later. Unfortunately it survived quite long.
There is a discussion on how we can handle rotary and many other non button press inputs in the future here #2387.
With that proposal you'd have the choice if to react on individual clicks or on the rotation speed. So a speed value changing to 0 would also indicate a rotation stop.

[Lukeb873]

I could do that, but that would mean that the camera would zoom for (x) amount of left over delayed time and not stop when I had stopped rotating. A stop rotation section would be an easy fix. However, I think (if there's an internal variable for rotation on a specific button), I could make an internal custom variable that checks to see if it's turning and if it's not turning, it consistently fires a stop zoom command.

I would suggest looking a birddog PTZ or Panasonic PTZ modules for something like this. I know for certain that these PTZ camera will keep doing Pan, Tilt, or Zoom until they get a stop command. On a button that's easy because it's your release action. We're wanting to use encoders because it's a little more natural, but there is no easy to way to do a stop action.

[jswalden]

PTZOptics cameras also have VISCA commands to start rotating/etc. and then stop rotating. However, they also have relative and absolute move commands -- plus inquiries that could be used to retrieve the current absolute position -- so in principle one could ignore the "begin moving left"/"stop moving" commands and just do it all in absolute terms as a workaround, depending on the other VISCA commands available.

I have encountered this problem to the extent of trying to think about how to solve it, then pretty much stopping because it's not terribly obvious and I don't actually need this personally.

There have to be other general-purpose software/hardware combos that expose rotaries, right? Surely there's prior art that has thought through the different ways of exposing rotaries, be it by event (left N clicks, right N clicks) or by absolute position (30 degrees clockwise from some absolute position, etc.).

[Lukeb873]

I have encountered this problem to the extent of trying to think about how to solve it, then pretty much stopping because it's not terribly obvious and I don't actually need this personally.

Yeah, like I said I could maybe do all that custom variable stuff, but I would need a variable from internal companion about wether an encoder is moving or not, and I don't think that's a thing yet. I haven't looked to be honest.

There have to be other general-purpose software/hardware combos that expose rotaries, right? Surely there's prior art that has thought through the different ways of exposing rotaries, be it by event (left N clicks, right N clicks) or by absolute position (30 degrees clockwise from some absolute position, etc.).

I'm not sure how relative speed on encoders work with companion. When messing with ISO, we noticed 1 click was the same as about 5 or so rapid turn clicks, so there's some amount of velocity in it, but it's felt a little fincky, because we sometimes wanted to crank it fast, but it would only boost ISO 1 stop.

[Julusian]

I'm not sure how relative speed on encoders work with companion.

We currently ignore the velocity value given by some encoders.
While this is bad, quite simply modules don't handle it well. We have no way of telling modules the velocity, and running the action multiple times is (in almost all modules) dangerous and will result in race conditions or will be buffered causing a delayed feel (especially to when you stop rotating)

Surely there's prior art that has thought through the different ways of exposing rotaries

The options I see are:

1. expose velocity to modules and hope module devs use it in actions (likely to require constant pushing, most will be unaware of the need for this)
2. expose velocity as a local variable $(this:velocity) and let modules use expressions in action options (will require chasing module devs to support. this will be more work for them to create and support new actions which use expressions)
3. revive Expose properties instead of actions #1187 and push module devs to convert actions across to this. (probably wants to be done in combination with 2, but with this done first).
4. we hack this together by guessing which option field is the 'delta' and modify it automatically based on the velocity before executing the action. This won't work for actions which don't have a 'delta'/'velocity' property, and wont always work for all that do as we will be matching a hardcoded list of option fields.

In any case, to do this well we need to figure out how we want modules to handle this, and then push them to do so. Which is so small task, this will be done pretty quickly by some modules and will take years to make it to others.

#1187 stalled because I wan't 100% certain of the architecture I was creating, and I didn't get any feedback. It eventually became stale enough and I had lost motivation so it got shelved.
But I really want it to be this way. In my modules I am not looking forward to the idea of having to support 3 ways a user can provide a value. Its a lot of very repetitive work, which #1187 would allow me to handle by deferring that repetitive work to companion to handle

[Lukeb873]

We currently ignore the velocity value given by some encoders.
While this is bad, quite simply modules don't handle it well. We have no way of telling modules the velocity, and running the action multiple times is (in almost all modules) dangerous and will result in race conditions or will be buffered causing a delayed feel (especially to when you stop rotating)

Gotcha, this makes sense. I guess while this still ignores the velocity, I have an ETC Eos config made for companion where there are custom variables made to change the encoder rotation sensitivity. Maybe this could be helpful to look at and see if we could make something like this in companion without the need for so many custom variables. There's a button that changes the sensitivity from fine, course, or ultra smooth (i'm blanking on the names at the moment). I'll attach this when I can export it on Saturday. I did something similar for a blackmagic hyper deck studio. There was a button that changed a custom variables variable from "slow" to "fast." Then changed actions or steps on the encoder with pre defined actions for either frame by frame for slow or a jog option.

expose velocity as a local variable $(this:velocity) and let modules use expressions in action options (will require chasing module devs to support. this will be more work for them to create and support new actions which use expressions)
revive #1187 and push module devs to convert actions across to this. (probably wants to be done in combination with 2, but with this done first).

I think I vote this... I read through the link to 1187, and I'm not gonna lie... I got pretty lost. I think it would make more sense once I had a GUI in front of me though.

repetitive work to companion to handle

When you say this, are you saying the program? I assume you are, but would this mean there are more types of actions. Like I said, I got lost reading 1187.

Also, do you work for Bitfocus or are just a freaking awesome open source enthusiast?