Macro/Learn function

[MeestorX]

Describe the feature Add actions via Learning just like how MIDI "learn" functions and macro recorders work.

Is this platform dependent (windows, mac, ..)? No.

If documentation is required to implement, do you know where to find it? I see it working like this:

1. User creates a MACRO action for a button.
2. In operation, when the user presses and holds this button (say for 3 seconds), it goes into "record" or "learn" mode. Use feedback so it changes color, or hopefully flashes to show it's recording.
3. Perform some operations using the native controls of your device. Messages are being sent to Companion, and it decodes these messages into actions. These actions are added to that button's actions.
4. Press the button again, and it goes out of record mode.
5. Whenever user does a (short) press of this button, the actions play back, just as per normal. The only thing that is being added is the ability for companion to add actions "on the fly".

Usecases It would be the easiest way to use companion for devices that send messages when their controls are operated. (Mixing consoles, for example, all work this way) Much easier to create button definitions very quickly. Having the module add "normal" actions would be preferable to the module storing the actions internally in an array or something as the user would not be able to see them or edit them after recording.

[josephdadams]

Instead of listening for incoming feedback data and trying to process it (especially when not all devices report the action that was done, some just say “ok”, or nothing at all), what if you enabled macro recording on a button, but then used Companion itself to run actions against those devices? And then when you hit stop recording, all the actions performed are stored in that macro button as individual buttons. This is what it’s like when I record macros (“custom controls”) on my Ross Carbonite. Then you can go back in and tweak the order, add pauses, etc.

[MeestorX]

Thank you for your comment, Joseph, but I don't think we're talking about the same thing. Using companion to run the actions defeats the purpose of having the actions automatically created. Obviously the functionality I'm suggesting would only be useful with devices that transmit their status when they are operated manually (as most audio mixing consoles do). Devices that don't work this way would not implement this sort of functionality.

[josephdadams]

Makes sense. I follow what you are asking for.

[MeestorX]

It seems to me that one easy way to do this would be use presets. If a preset could be created "on the fly" rather than just at initialization time, one could add actions to it. Even if the presets array were available you could do something like self.getPresets() and then add additional actions to a specific preset in the array.

[Julusian]

I am prototyping this for the 3.0 branch The proposed module side of this is https://github.com/bitfocus/companion-module-base/pull/11

I am then thinking that in companion, on each button for each group of actions (down, up etc) there should be a record button (Or maybe one record button with the action group selectable afterwards?). clicking that should open a modal configured for recording to that location. While a recording session is active, all open ui's should be aware, with a way to view what is being recorded. I think it reasonable to limit it to one record session running at a time for a companion installation.

In this modal: Probably some options to say whether to append/replace, perhaps a delay value to give the actions? I think in this it should be possible to select which instance (or instances?) to record from. In this modal as actions are 'recorded' they will be shown (and manually editable?). Finally there will be a 'save' button and a 'discard' button. Only upon clicking save will the actions be added to the button. Perhaps there should be 'pause' and 'resume' buttons, to allow for pausing the recording?

To begin with, I don't aim to make this triggerable through internal actions, but I expect that will be done later

[MeestorX]

Very cool, but don't forget that a key part of this is the ability to create macro keys "on the fly" without any need for the GUI except for editing or cleanup. An internal action should be added for learn and stop (called Rec and Stop in my modules) so that you could add a page of macro buttons that can be added to while using the device without having to access the GUI.

[Julusian]

I haven't forgotten, but choosing to neglect that to begin with ;) I'm trying to avoid making changes that are too big and sprawling and so end up sitting around for ages before they are finished and merged

[Julusian]

This is in the 3.0 betas

[MeestorX]

Just testing again, looks like we'll need a couple more internal actions: Finish and Clear

[Julusian]

Isn't that handled by Action Recorder: Save to button and Action Recorder: Discard actions?

[MeestorX]

Save to Button doesn't seem to work. I tried saving to the same button adding it as an additional step. Let me see what happens if I save to a different button.

[MeestorX]

Still not working, but I might be doing it wrong. Using "Finish" doesn't allow me to put the actions on a blank button either. I can only replace or append to a button that already has actions on it.

What's an "action set"?

[MeestorX]

UI for the Action Set is appearing UNDER the Select Destination Dialog. Still not sure what this Action Set means, but if it relates to the type of action (press, release, etc. then shouldn't "Down" be "Press" and "Up" be "Release", etc...

[Julusian]

Still not working, but I might be doing it wrong. Using "Finish" doesn't allow me to put the actions on a blank button either. I can only replace or append to a button that already has actions on it.

yes, you have to define the button first and ensure the target step and action group exists. otherwise it will be too easy to get into weird states.
such as:

• if you say to use step 9999, that means we will need to create every step up until that one.
• if you say to use group rotate_left, should we enable rotary actions?
• if you say to use a blank button, how should the rest of it be defined?

Doing anything more on this I think veers into #2233 territory, which I am not convinced is a good idea. In some ways I am wondering if this has already gone too far in that direction.

What's an "action set"?

Ive reworded that to action group. And changed down/up to press/release for consistency.

[MeestorX]

Copy you. It should be able to write to a blank button, that's really the most likely scenario that it would be used for. Just leave everything else as default. Can you explain further if you think that might be a problem?