Proposed feedback system about companion HOT 5 CLOSED

I like this

It would be good as a feature across all timers to increase the countdown's size from 9 seconds to 0 to cover the entire button.

from companion.

Maybe we need to make a triple-size font for that ;)

from companion.

It would also be nice to have an action run purely off a feedback ( or should we call them reaction ) ie. qlab go action fires when we receive switcher input x on program without assigning this to a button. buttonless reaction action

from companion.

Basically I tend to think of objects providing input and output. A Button provides output: key down, key up, long keypress at lower level and triggering actions at higher level. For me it makes sense that the output part is at the bottom and separated from the input part. Input part at top. The Input of a Button is graphics shown on it. No-brainer so far, but how exactly can device feedback lead to a graphics change?
In my opinion it has to be (at least) a two part process.

1. Creating the visual appearance of a button with elements like geometric primitives, icons, text... I tend to think of "layers" like in photoshop. Every element has some properties like color, text ..., which you can just set.
2. Link feedback by devices to the properties of the elements.
   That's the tough part because it actually would require programming by the user.
   The process needs mapping value ranges and combining them. Mapping means the device e.g. gives back time in milliseconds and you want to show in minutes:seconds or the device gives back state information in numerical or even sometimes in bit-state and you want to visualize with rgb-color. Combining means you e.g. want to change color of button only when input is on air AND clip is running or you want to change text if input1 is loaded in out1 OR input1 is loaded in out2.
   That means we would have to provide a full set of operators and conditionals to the user.
   Personally I like that because I can work with that and my credo is always power to the user.
   If I had to design it, I guess I'd go with textual programming and not try to make it simple with a graphical solution while actually making it more difficult. A text input where one can use js-syntax, so that it is easy to validate and execute.
   I very much like the idea of sample buttons, I think that's the only way to make such a complex system usable for the average user, they can use the sample as it is or adjust it a little bit. Module programmers can provide variables in different useful formattings to make it a little easier on the user side. Documentation of available variable names needs to be generated inline and presented to the user.
   I like to propose the button pool once again. I think of a big abstract storage for button configurations. Every module can register it's predefined buttons in a read-only section, if you want to use such a button copy it to the read/write user-button-pool and edit it to your needs. Off course you also could create a button from scratch.

Sorry for the long comment, I hope I wrote it understandable.

from companion.

Fixed in f6aeb2a

from companion.