Inclusion of platform-specific modules

[thedist]

Following a recent discussion on Slack I was asked to bring this discussion here so more people can weigh in on how Companion should handle modules that may interact with apps on one specific platform.

Backstory:
In 2019/2020 I was hired to make a module that integrates with Voicemeeter, a Windows only software audio mixer. The official way to access their API is by finding the install location, finding a specific dll within and binding to that. Back in 2020 I believe it was I tried to get this module included in Companion and was told because it binds to a dll the core team declined to include it. At this point my client decided Companion wasn't fit for purpose for their studios and moved to developing their own in-house app to utilize streamdecks.

Fast forward to 2023 and the number of module requests for Voicemeeter has grown, both on the Companion feature request issue page and within the broadcast communities I'm a part of (mostly esports, and game dev studios). As Companion 3 is on the horizon I again asked if I could get the module which I've now been porting to Companion v3 for personal usage included in Companion, and again issues came up but this time about platform-specific reasons.

So my question for discussion is, why does it matter if a module may be platform-specific?

In my case the plan always was to have the module support a socket to connect to a proxy on a remote machine, that way the proxy would run on the remote Windows machine running Voicemeeter, and the Companion module could be running on linux, mac, windows, whatever. The initial version though would be based off of my usage, and the vast majority of users who would be running Companion on the same machine as Voicemeeter.

Should the Discord module for Companion also have not been allowed because that's platform specific? That connects to the locally running Discord client, so is specific to whatever platforms Discord can run on.

If someone wants to develop a Companion module for controlling the Windows Sound Mixer, should that be not allowed because Mac and Linux don't use the Windows Sound Mixer?

As long as the modules gracefully handle being run on the wrong platform, eg logging a message saying "The Windows Sound Mixer is not available on Linux", and doesn't crash or negatively impact Companion as a whole, why should Companion be restricting the inclusion of such modules?

One of the suggestions was that Companion v3 makes it easier to load external modules, to which the response of myself and others has been that's another barrier to entry, and it makes for a poor user experience if users have to jump through more hoops to get to what they want to control, and it harms discoverability as some may not know those modules exist in the first place.

Eventually the Voicemeeter module was allowed to be included and a repo created, but before that finally happened the response on the module requests github was:

"I'm still sour about the core dev team's decision, though I get their reasoning."

So as you can see some of these restrictions, which have come with little or no explanation or communication from the core team to the 3rd party developers as developer relations is non-existent, is having a negative impact on end users who just want to control stuff with Companion, and while I may be in a minority of developers creating these sorts of modules I have made modules for vMix, Twitch, Google Sheets, Discord, Unreal Engine, and a couple under NDA, so I consider myself a fairly experienced module dev yet even I have these restrictions/changes sprung on me without warning or communication.

Hopefully this discussion can lead to Companion having some more solid and communicated guidelines or what modules will or wont be eligible to be included in Companion.

[Julusian]

I think the problem here is that there isn't a very well defined governance or defined roadmap, so personal opinion often seeps into decisions like this.

Personally I am not a fan of modules which can only interact with the local machine, as many users are running Companion on a pi (or a linux vm) and so would be unable to use these modules. And that is the core of my problem with modules like this, they limit the flexibility for users
So I would prefer for these to be done with a proxy app instead. I do appreciate that it adds additional complexity both for developers and users though.

But I suppose I don't really have a strong objection to having modules like this.
It would be pretty simple to add some way of defining the supported platforms in the runtime object in the manifest, which would then allow us to either hide them in the ui or show them as unsupported.

There are others which do local things already, there is a gpio one for pi which is not included in the builds. thingm-blink1 can do local usb or http

[thedist]

Could perhaps one option be to allow these sort of modules into Companion, but limit them from the official release until a Proxy is available? Or perhaps having a Proxy be in development for a future release? This would at least allow larger scale testing in beta versions of Companion.

One of the reasons why the Voicemeeter module wont be ready for the v3.0 RC is that all of the hassle and delays just getting an okay to have the module included in the first place meaning some of the features weren't ready in time, or had enough testing. If I could have had the module included when I asked, we could have had it being publicly tested for a long time while I worked on the proxy (which is now available, as the module connects directly if on Windows, or otherwise the module itself can be used a proxy on a windows machine and run a socket.io server that Companion connects to).

To outright deny such modules is preventing ALL users using Companion from using these modules, rather than just those on unsupported platforms until a proxy is developed.

It is also worth taking in to account the use case for such modules. Keep in mind that Voiccemeeter is very much a consumer audio mixer, and not something designed for a professional environment and so the vast majority of its users are individual home users, so the chance of Companion running on a separate machine is already reduced compared to a professional multi-user production environment.

A lot of areas like this I think need solid, written, guidelines on what the requirements for modules to be included are and not just the whim or some user who has no clue about the software/module wanting to be used, or the end users wanting its inclusion (including those willing to pay for it to be developed).

[dnmeid]

IMHO there are no objections against modules binding to a dll or platform specific modules in general. But when I have a look at the modules currently shipped with Companion and the average user then the common case is that a Companion module is platform independent and the users expect it to be platform indepentent and they do not read manuals or help pages. Every module which works different then the normal modules will lead to user dissapointment and in my opinion this outweighs the benefit of offering another module.
At the moment Companion is not ready for some modules which behave different. With v3 the module API has changed and we now have an easy to see marker for legacy modules. I think it should be possible to extend that functionality to give users standardised and easy to reach information on what to expect from a module. If we can manage the user expectation and let them know in advance if the module is only working on a specific platform or does need any kind of helper this would be beneficial to users and developers.
As long as it is not clear to the user what limitations a module has and we have no way of communicating them I think it is better to keep such modules at the abolute minimum.

Another point: I also hope that this discussion (and the whole discussion board) helps to find a common standpoint for the maintainers and improves communication. But please keep in mind that the result might also not be 100% what you want.

[thedist]

So lets break this down.
Voicemeeter is a Windows only app, and it can only be controlled locally. This means that if Companion is running on the same machine, it can connect directly, otherwise it would need a proxy.

If you wanted users to have the exact same experience regardless of platform:

1. Users adds the Voicemeeter module to Companion
2. User sees it doesn't work, goes to config/help and sees it requires a proxy
3. Find the download link and download and run the proxy and get it to run at startup
4. Configure the Voicemeeter module to connect to that proxy

Now lets look at my usage:
If the user is on Windows running Voicemeeter -

1. Users adds the Voicemeeter module to Companion
2. this is no 2. they're done.

If the user is on Mac or Linux -

1. There is no 1, Voicemeeter is unsupported on these platforms so this subset of the Companion userbase is ineligible to run Voicemeeter to begin with

if the user is on Mac or Linux and has a separate Windows machine running Voicemeeter -

1. Users adds the Voicemeeter module to Companion
2. User sees it doesn't work, goes to config/help and sees it requires a proxy
3. Find the download link and download and run the proxy and get it to run at startup
4. Configure the Voicemeeter module to connect to that proxy

So right away, your goal to want to make modules entirely platform independent and work the same way, ends up resulting in a degraded user experience for those on Windows as you would require them to download additional software that has to be kept updated by that end user, and go through additional configuration steps within Companion that can be entirely avoided for the userbase who run Companion on the same machine as Voicemeeter.

Additionally when it comes to userbase, as previously mentioned those running a Mac/Linux only environment can't run Voicemeeter so those users don't factor in to this, and the vast majority of Voicemeeter users are those running a single Windows machine. That is the target audience of the application, that is the userbase my client previously contracted me to create a module for, and throughout my work in the Voicemeeter community that's where almost entirely the users are. So this means if you wanted to enforce uniformity regardless of platform (ie, by making all user run the proxy) you'd be creating a worse experience for those who actually want to use the module, while the outliers who would have to use a proxy would need to go through the same steps one way or another so it makes no difference to them.

I could understand your point if Voicemeeter had a larger userbase that more commonly wanted to control it remotely, but that is not the case here. Even Elgato's plugin to control Voicemeeter only works locally. If the Companion core team of developers is going to decide what modules do/don't get allowed in to Companion then please make sure you reach out to the developers of the software, and the communities that want to use it so that you can make an informed decision, or defer to those of us who are actually part of those communities for many years and worked with them, rather than jump to conclusions about user expectations for whatever may be the specific module in question rather than generalise about the Companion userbase as a whole who may not even all be eligible to use the app/service/hardware a module would offer in the first place.