Elgato Plugin needs individual surface selection control

[davidjoshuaford]

Is this a feature relevant to comapnion itself, and not a module?

• [X] I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the feature

While the new setting: "Use Elgato Plugin for StreamDeck access" has simplified the process of using native Elgato software vs the Companion software, it has also limited surface control. This is because when it is enabled, ALL surfaces are locked out in favor of the Plugin.

Previously if Companion was started up first and locked in the surfaces, then Elgato could be booted up secondly, and we could use the Mobile version via the Plugin. This method would create surfaces that update independent of each other. (I address that in my video here: https://youtu.be/6MMEMYi6LuU?t=240)

Now when the Plugin is enabled, since it is a single "surface", changing the pages on one Stream Deck will also sync a second Stream Deck.

Is there a way that the Plugin could be assigned to a particular surface? Or at least not block Stream Deck hardware running natively to Companion when the Plugin is enabled?

Usecases

For instance, I have two 32-button Stream Decks. I'd like to run them natively to Companion, but also want to be able to get the Plugin to operate as a third surface, so that I can run the Stream Deck Mobile app at the same time (or even a different Stream Deck hardware panel as a hybrid Elgato/Companion profile).

[Julusian]

This is not the case on windows. On windows, prior to this checkbox neither got locked out so they both attempted to use the devices simultaneously.

Maybe something could be done for macos, but it feels like its going to be rather brittle, and is definitely kinda weird behaviour

Im curious, is there a reason you want to use streamdeck mobile rather than one of the web button pages?

[davidjoshuaford]

On a Mac, When the checkbox is enabled and I Scan USB, the warning message comes up with: "Ignoring Stream Decks devices as the plugin has been enabled", and the Stream Deck hardware does not show up.

The reason I like using the Stream Deck Mobile app rather than the emulator or web buttons is: the Emulator cannot long-press on an iPhone or iPad, because when you hold down a button, the right-click text select function is triggered. And the web buttons have never had the page jump navigation (ie the "set surface to page number" does nothing. So it means the only navigation is clicking through sequential pages, or scrolling infinitely. Also, the benefit of the Stream Deck app is that it's an easy icon to jump in and out of, since on an iPhone you'll often be multitasking, and the layout is fixed, rather than floating around like a web page.

[Julusian]

To clarify, the windows behaviour in my previous comment was how it behaved before this checkbox. Which resulted in many many bug reports, and made users have to come up with various hacks to get companion to not detect the devices.

I am pretty sure I made the emulator in 2.2 handle long presses properly. If not then that is a bug that can be easily fixed. Yeah, making the tablet views handle page jumps is on my list of things to do, but has not been finished yet

[davidjoshuaford]

I think I may have mentioned this elsewhere but can't find it at the moment –

Can we have an Action to "set surface to page "X""... where X is a custom variable that can be used in any surface's name field?

Use case: I'd like to build a dual surface, so that as I update the stream deck buttons, the virtual emulator pulls up a related extension page. For instance, when creating an AUX routing page, I need more than the 32 buttons to see all assignable ATEM inputs. The variable is needed because it would be useful to reassign which surface the extension is targeting, be it on a computer screen, tablet, or a second XL surface. I'd name the first surface "1" and the second surface "2", and the "set surface..." action would look for that name or variable.

[Julusian]

Would this be covered by https://github.com/bitfocus/companion/issues/570? By putting that extension surface into a group by itself. Then you would be able to change out the surface in that group and retain the existing programming

[davidjoshuaford]

I think there are two use cases here -

570 sounds more like locking multiple 32 button grids together (ie a 2x1 or 16x4 array... or a 4x4 or 16x8 array)

That could have one use case, where as the Action I'm talking about to "set surface to page X" where X is a variable custom value, would enable more ad hoc implementation, so that some page jumps would update the secondary surface, and others wouldn't.

I often use a single surface, so I'd like to design a layout with the flexibility where I could turn on or off 1x1, 1x2, 1x3, or 2x2 Stream Deck XL or emulator support.

Here's an example of naming emulators 1, 2, 3, 4.....

And then in this screenshot, being able to reference a specific surface (in this instance, surface "1") with an action:

Alternatively, an emulator could be used on a computer monitor as a HUD that updates according to what pages I'm selecting on the stream deck - for instance, if I'm switching the ATEM it would show tally feedback and Rec/Stream info, if I'm controling VLC or Hyperdeck the emulator surface would update to show timecode countdown and track names and clock.

[davidjoshuaford]

One more thought - i know there has been discussion about a later version of Companion having an unlimited grid rather than the 8x4... even if it were unlimited, the user would still have to choose a size that is suited to the usability of the device. I actually think the 8x4 is well suited for the SD XL, iPhone, iPad screen sizes. Hence, grouping multiples of 8x4 banks would be a good way around this.

[Julusian]

Yeah #570 is more about that, but I still think it would resolve what you are asking for. What I am afraid of is that once that is done, if we also allow addressing a surface by its name or something, then there are going to be many actions that all do the same thing but in different ways. we already have by serial and index. do we need to add by group and by name?

And as I suggested before, if the group only contains one "streamdeck", then it wont do anything fancy like synchronised page changes, so functionally it should be the same as using that name field.

One more thought - i know there has been discussion about a later version of Companion having an unlimited grid rather than the 8x4... even if it were unlimited, the user would still have to choose a size that is suited to the usability of the device. I actually think the 8x4 is well suited for the SD XL, iPhone, iPad screen sizes. Hence, grouping multiples of 8x4 banks would be a good way around this.

My current thinking is that the size will be entirely user chosen. I don't think we should impose any restrictions on size because everyone will want something different (plus it will be more work to impose any limits. If you consider just the models of streamdeck that starts off with 4 different possible sizes, and perhaps you want to pair an XL next to a 5x3 instead of 2 of the same.

[davidjoshuaford]

Index number could work, except that they cannot be user-assigned. So if you have your SD XL hardware laid out in a specific way in the real world, companion wont necessarily reference/honor the intended surface sequence.

If the user could set the index number themselves, this could be a way around it.

The problem I have with building a serial number into a profile is that it is locked to that specific device and can't be readily adapted or swapped out without trawling through the whole profile to find instances where that serial number page jump was referenced.

Hence, being able to use an alias (for instance, in the name field for the surfaces, "SD1" "SD2" etc), means you could reassign a surface as needed. This would help switching switching out a failed or missing SD, or even help switching over from two XLs to two tablets, if you want to go wireless.

[Julusian]

I don't think we want to do the original ask here of 'individual surface selection', as it will ultimately result in the two bits of software fighting over streamdecks. This was originally asked for to be able to use the mobile app, but the tablet view has had improvements so it should no longer have the same flaws. If it does, then that is a bug which can be fixed