Proposed feedback system

[haakonnessjoen]

This is how I have thought out a feedback system that should be simple for anyone to use, but also somewhat simple for us to implement.

• A feedback can be added to a bank just like an action (CAN be)
• The module controls what each feedback-type controls. One feedback could be that it changes the background of the bank to red when program is active on channel 1 on a vison mixer. Or it could be that this feedback updates the title of the button automatically to the same as preset 1 on a E2.
  • A module will of course export actions and feedbacks. But most importantly, it will export sample buttons, that you can drag into the bank editor. The sample buttons would configure both action and feedback on the "drag&dropped" bank.
• Also support variables, where you can include variables in any bank-title, and it will be dynamically updated if the variable is changed by the module on the fly.

William and I also talked about how "sample buttons" would make a timer instance module very simple. Where we could instantiate several timers, and timers also could get TC from other modules that export that. But that is for a different issue.

I am ready to start coding on this feedback system, if @willosof help with the GUI :) Anyone have anything against this or any better ideas?

[Deanbau]

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.

[willosof]

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

[PerRoine]

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

[dnmeid]

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.

[haakonnessjoen]

Fixed in f6aeb2a