Expose properties instead of actions

[Julusian]

Describe the feature I have been thinking about this for a while, as exposing numeric properties in device modules gets really repetitive, especially when wanting to allow actions to do relative changes and comparison operators in feedbacks.

The current actions architecture works nicely for devices which work in actions, but puts a lot of work on the modules when the devices expose properties. This leads to the functionality and flow being inconsistent even within modules. The idea of this is not to replace all actions, just some of them. Actions are appropriate for some things (eg performing a cut on an atem), but properties make sense for others (eg setting preview to input1)

As an example lets look at an audio fader. For this, we want to be able to set it to an absolute value, and to do small changes to bump the level up and down. We also want feedback for that value using a few different comparison operators (<, <=, ==, !=, =>, >) In this example, that isnt much to do. But it is still work that is going to want to be replicated for each module which has an audio fader, and some will even have different types of faders and so will need to duplicate it themselves too.

A better approach to handle these would be for modules to instead report back the properties they have which can be set. Each property could be defined as something like:

{
  id: 'ch1',
  label: 'Fader: Channel 1',
  type: 'number',
  min: '-90',
  max: '10',
  getValue: () => {...},
  setValue: () => {...},

  subscribe: () => {...},
  unsubscribe: () => {...},

  variables: [
    {
      id: 'ch1_db',
      label: 'Channel 1 level (db)',
    },{
      id: 'ch1_percent',
      label: 'Channel 1 level (%)',
    }
  ],
  getVariable: () => {...}
}
{
  id: 'ch1-type',
  label: 'Type: Channel 1',
  type: 'dropdown',
  options: [
    { label: 'Something', id: 0 },
    { label: 'Another', id: 1 }
  ],
  getValue: () => {...},
  setValue: () => {...},

  subscribe: () => {...},
  unsubscribe: () => {...},

  variables: [],
  getVariable: () => {...}
}

And to go with this, whenever the module has a change to a property it should inform core, which can then calculate where this is used

  this.notifyPropertyChange('ch1-type')

Companion core would need to wrap the properties up in actions/feedbacks so that they can be added to buttons like normal.

Future This will serve as a good starting point for when we want to support input devices with faders or dials, this might even start as allowing osc to provide values.
It could be used to create some more dynamic behaviour too, such as actions which sets the level of channel 1 to match channel 2.
A way to 'bind' a property to follow one from another module would be really useful. It could be done manually by defining a trigger to act on a change, and fire off a change, but that will be very slow and tedious to setup and maintain. A way of doing the same thing for simple things in a few clicks would be ideal. Perhaps even with a 'transform' step

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label Enhancement to this issue, with a confidence of 0.96. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[MeestorX]

Can't say I completely understand what you've got in mind, but anything that allows for more flexibility I'm definitely up for.

I wish there was a Zoom meeting for module developers to discuss ideas. Slack messages aren't really a great way to brainstorm!

[josephdadams]

@MeestorX host one!

[MarauderSeeker]

maybe do a Discord Voice call