Copy-paste LS and SF between models in Companion + keyboard shorcuts also in LS and SF tabs

[Neutral67fr]

Hi there,

I'm not well trained to Github environment and I'm not really sure how to make a feature request...
I would like to suggest somme improvements in Companion:
It would be nice to have the opportunity to copy-paste some logical switches and special functions from one model to another one.
That would be a great time saving feature :-)

Additionally, it would also be great to have the same keyboard shortcuts in the LS and SF tabs for reorganizing the lines, just as we have in the Inputs and Mixer (e.g., ctrl+up for moving line up).

What do you think about it?

[elecpower]

It would be nice to have the opportunity to copy-paste some logical switches and special functions from one model to another one.

This is an existing feature. Just open multiple models then copy and paste between them.

Additionally, it would also be great to have the same keyboard shortcuts in the LS and SF tabs for reorganizing the lines, just as we have in the Inputs and Mixer (e.g., ctrl+up for moving line up).

Unlike Inputs and Mixes there is no 'active' line in LS and SF tab, due to the ui design, on which a keyboard shortcut could operate. The suggestion #2220 could be expanded to add keyboard shortcuts.

[Neutral67fr]

OK you're right, the copy-paste function already exists (I admit I missed it ^^) but actually I find it pretty useless as is: For now it only works by single line, and we lose the already existing LS# reference when the copied LS uses another LS, what behavior I can easily understand for a single line copy.
Actually my first thought was to rather copy-paste a bloc (several lines) of LS that are working together (it's often the case).

Example: I have L06 that relies on L05, and L07 that relies on L06. I would like to be able to copy the 3 lines [L05;L06;L07] and paste them in another model to become [L08;L09;L10] keeping the relations (L09 relies on L08 and L10 relies on L09). This assumes that the LS# have to be considered as relative and not absolute, which I guess it's already somehow the case because when we move an LS, the special function based on that LS automatically updates.

[elecpower]

Copy and paste uses absolute references as relativity is lost in the copy to the clipboard with the source line reference is not recorded. The destination may or may not be the same model so patching references on paste may not always be valid.
Moving is a single step process and relativities can be maintained within the tab and across tabs eg moving a LS will update all SFs that reference the LS.
If multi-line operations are implemented then adding source metadata to enable patching up the pasted references should be possible. What about references that are outside the copied lines? In your example say L06 references L12. Should they be relative or absolute?

[Neutral67fr]

Yes I understand the dilemma... ^^
The best solution (in my brain... lol) would to add sufficient metadata to each line to consider both relative and absolute references depending on the context and the user choice when willing to move or copy-paste multiple LS.
Moving one line within the same LS tab is no problem as the references are automatically propagated to any other line that references the moved line. So I assume doing the same when moving multiple lines is not a big deal (but I might be wrong ^^)...

When copying several lines from one model to another, the references inside copied lines to other lines copied at the same time could be considered as relative to keep associativity existing between those lines. And the references inside lines referencing other lines that are not copied or moved would obviously be deleted (blanked out) to avoid errors in the destination. These lost references should obviously be redefines in the new context (like the current behavior in case of copy-paste of a single line).

Yes I realize it's more easy to just imagine than coding all the stuff ^^

I hope I'm clear enough in my explanations, but I made a simple simulation in Companion to show the expected results according my thoughts...

[Neutral67fr]

First case example:

Second case example: