Linked Button Copy

[GeraldtheHippo]

It would be great to be able to copy a button to another page, or multiple pages and any changes you make to the original button carry through to the copied buttons - including any formatting, instance commands etc. Also if any other command releases the original button it should release any of the clones as well, however this may be more complicated than it's worth.

Usecases:

Controlling a Lighting Desk or Media server, I like to have the same buttons repeat a few times so no matter what page I am on I can access the cues and commands that I need, this is easily acheived on a lighting console and the same workflow would be a great addition for streamdeck http://help2.malighting.com/Page/grandMA2/keyword_fix/en/3.9/fix#toc_header_anchor_1

I run a video team in a church where we have morning and evening services and we have the same media pieces just with a different colour scheme so I have set up an AM and PM page - there are elements that are consistent through out so to be able to make that button only once and then link copy it to another page would mean any changes I have to make only need to be made once

[acehoss]

+1, I have a couple uses for this.

• for live video productions, camera/source buttons and transition buttons are on multiple pages for quick access while working with buttons for other functions like audio or CG
• for quick changes to layouts, I create pages of library functions, then copy the library button to the layout page.

Obviously changes to a button can be manually copied to other pages, but this requires remembering or checking for all pages that use the button. A reference would allow me to update just the one button and not need to update the other pages.

[acehoss]

+1, I have a couple uses for this.

A simple workaround that is functionally identical to a button reference...I'm sure this is what the pros are doing already:

• Create a regular button
• Press action: internal: Button press, set to desired target button
• Release action: internal: Button release, set to same target button
• Feedback: internal: Use another button's color, set to same target button

[istnv]

A simple workaround that is functionally identical to a button reference...I'm sure this is what the pros are doing already:

• Create a regular button
• Press action: internal: Button press, set to desired target button
• Release action: internal: Button release, set to same target button
• Feedback: internal: Use another button's color, set to same target button

Almost correct. These actions and feedback were added mainly for this purpose.

• Create a 'Primary' button that becomes the target of any clones. This one will contain the actions.
• The 'clone' button only needs to press the target button: Add (internal: Button press and release). ** The target button will latch/unlatch if necessary.
• Add Feedback: internal: Use another button's color, set to same target button
• Add $(internal:b_text_x_y) to the button text. This copies text from another button. ** (Replace 'x' with the page and 'y' with the # of the primary/target button).

Once set up, the 'clone' button can be copied and pasted easily. All clones will 'push' the primary button and mirror the 'look'. Then the primary button is the only one that needs updating if the function changes.

[acehoss]

• The 'clone' button only needs to press the target button: Add (internal: Button press and release). ** The target button will latch/unlatch if necessary.
• Add Feedback: internal: Use another button's color, set to same target button
• Add $(internal:b_text_x_y) to the button text. This copies text from another button. ** (Replace 'x' with the page and 'y' with the # of the primary/target button).

Some great optimizations in there. It seems that $(internal:b_text_x_y) will forward only the configured text, and if feedback overrides the primary button's text, these updates will not appear in the referencing button. Is there a different variable that has the current text value?

[istnv]

Some great optimizations in there. It seems that $(internal:b_text_x_y) will forward only the configured text, and if feedback overrides the primary button's text, these updates will not appear in the referencing button. Is there a different variable that has the current text value?

$(internal:b_text_x_y) is dynamic and should mirror any changes, including internal: Change button text and feedback. The feedback style change is a more recent feature and may be updating the text without triggering the clones (which would be a bug).

[Julusian]

@istnv feedbacks have always been able to 'change' the text, but very few do it. The recent feedback style change exposes it in a more friendly way, but not in a way that would have changed how this behaves. I expect that those variables are not implemented in a way to check the current text. I think we do have the appropriate structure (and event?) for this to work properly, someone just needs to hook it up. And also make sure it wont cause companion to lock up in an infinite loop if buttons are programmed badly

[istnv]

@Julusian A module could change text during a feedback call, and when I added those variables, they did work with feedback text as well.
It is the newer feedbacks that are 'exposed' to the GUI that somehow bypass where these clone variables get inserted. I'm looking through the code to see how this gets bypassed but I haven't been that deep for months :)

FYI: There is a check_for_recursion function to prevent those loops. That was a fun debugging session.

[acehoss]

I was using the internal: When button is pushed/latched feedback when I noticed this.

1. Create a latching button. Text: "Off". No actions needed. Feedback: "internal: When button is pushed/latched", this page, this button, update property Text to "Off"
2. Create a button and use $(internal:b_text_x_y) to clone the text of the button. No actions or feedback.
3. Press the latching button. Its text changes to "On", but the clone still says "Off"

[istnv]

@hossboss I usually set a internal: set button text in the up and down actions, which does work. Somehow text changed via a feedback is not triggering the clone variable update. I'm looking into that now.

[Julusian]

@istnv Im not sure how feedback text ever worked the variable.. Im looking at the code, and it checks the bank, but only considers the feedback for invalidating the colours. Perhaps the 'bank_style' feedback should be changed to propogate every property? In my mind it should simply copy accross every value in the style it got from 'feedback_get_style'. Then it would be a true replicate and not require using the variable.

[istnv]

@Julusian Sorry, I have 3 other projects happening today as well. The other feedback options should be copied at that point as well.

[istnv]

Code to include text updated from a Feedback in variable $(internal:b_text_x_y). In PR for (companion-module-bitfocus-companion))

[Suenee]

The idea of symlinking the button is interesting. Maybe it would be more interesting if the copy/move/delete buttons could work as I wrote in #2233.

[coreyfarrell]

I've tried using internal: Button press and release to accomplish this and it usually works. The problem I've had is when the target button uses the action internal: Set surface with s/n to page for Current Surface. In this case it always switches pages on the emulator surface rather than changing pages on the physical surface where the real button press occurred.

[BBrazner]

+1 I would love to see a new button type. Call it a "linked" button. The only configuration parameter would be the primary (regular) button to which it is linked. Think of it as a read-only copy of the primary. Some behaviors would be: 1) A linked button would mirror all properties (e.g., font, background, feedbacks, step state, etc.) of its primary. 2) Pressing a linked button would be tantamount to pressing its primary. 3) Deleting a primary button not allowed if linked buttons exist for it. 4) Copying a primary button that has linked buttons would have to prompt if a new primary vs. new link is to be created. 5) Copying a linked button creates a new linked button. 6) A linked button can be elevated to become a primary (regular) button. 7) A visual indication that the button is a link button. 8) A Find Next tab (in the Copy/Move/Delete/Reset/Wipe row) that jumps to the next linked button.

[leonreucher]

+1 Would be really handy to be able to reference buttons, instead of copying them to several pages and when changing something the button needs to be copied to all other places again.

[dnmeid]

Although this issue is not new and the discussion there is also not new, I just realized that in #2387 I propose a different approach to it but it solves the same problem. The main take is, to separate the logic from the controlling button. All the logic that now sits in a button would then be some independent script. A button can run that script. If you want to have control at multiple positions, multiple buttons can run the same script. So the underlying script is always the same and everything stays in sync. Drawing to the button is independent and you can easily just copy the button for the same look of all buttons. You wouldn't have to take care if there are cloned buttons if you want to delete or move the master button or need to find the master button if you want to edit something.