-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Variables missing #226
Comments
+100 Missing tons of variables. No way to track active input when it's part of a Multiview/Overlay. All "Feedback" should also be available as Variables to be used in Companion Triggers tab. For example, I can't trigger camera tally lights based on active input if the camera/input is part of a Multiview/Overlay. |
No, not everything will be made a variable for performance reasons. There's a reason why config options had to be added to reduce the current set of variables for users struggling with performance on slower systems such as Raspberry Pi's. If you have 100s of missing variables, list them here and your use case and depending on the need for them there'll be considered for the next update. |
I just want a way to track what input is active in the program output. vMix doesn't consider an input to be active when it's used in a Multiview/Overlay, and that Multiview/Overlay input is shown in the program output. It only considers the Multiview/Overlay input itself to be active, not all the inputs that are part of that input.
The vMix plug-in in Companion has functions and feedback that isn't part of the vMix API, making vMix more usable, but most of the feedback variables aren't available to use as variables for triggers. It should be easy to track what camera is active, then setup a trigger in Companion to trigger a function in the Sony VISCA plug-in to control camera tally and other things.....but no.
|
I'm using the Studio Coast vmix plugin in Companion, and I noticed that variables do not update. Specifically, the $(vmix:connected_state) remains "True" permanently....even when vMix is not running on the machine and the status on the "Connections" tab in Companion is Error ...because there's no connection. This makes it impossible to trigger events at startup.
|
Regarding the Studio Coast vMix plugin for Companion
I reported previously that the variable $(vmix:connected_state) remains "True" permanently, making it unusable.
I also can't use the variable "internal:instance_errors - instances with errors" to determine if vMix is running, because when vMix is not running, the Studio Coast vMix plugin constantly switches states between Error and Warning, and Warning is not considered an instance error. Any trigger setup to use this variable gets triggered repeatedly as the plugin switches states between Error and Warning.
Does anybody test this stuff? I'm just trying to find a way to trigger actions based on vMix starting.
|
There's no need to cover the same things multiple times. You've mentioned the
This is free software. You don't pay for the time developers spend working on Companion, or my time developing this module. Testing does take place but there is limited time and resources so I invest my time in more important and critical features first. No one but you has reported this issue until 18 hours ago, so calm down, a fix will be released as and when I get to it. |
I reported 3 separate issues.
I'm forced to use connected state because there's no other way. That's why I'm reporting these issues to begin with. I just spent 2 days writing a program to communicate between vMix and Companion, just to track what input was active in a Multiview input and trigger a tally light. Companion is free yes, but I paid $800 for vMix. That's the source of my frustration.
|
Perhaps go to vMix and take your frustration there then for not being able to support your use case themselves. What you paid for vMix is irrelevant here, as we don't work for vMix or have any association with the vMix developers, all of those who contribute are people who give their free time to work on these modules because we also use vMix. You also do not see all of the work that is going on behind the scenes in branches not available to you, so please be patient as things are being worked on, and if that is still not acceptable to you then I suggest writing your own vMix integration separate from this module. |
I'm coming very late to this discussion re $(vMix:connected_state) not working and have some additional insight to offer. First, I just upgraded to 3.1.1 from a 2.x.x version and the bug appeared then. When we first starting using Companion close to two years ago, this same bug was in whatever version we were using at the time (v2.x.x) and the author of the Companion vMix module was able to squash the bug with a quick update/patch that they sent to me. A subsequent build of Companion included the fix. It appears the same bug has now re-appeared and wonder if there's a way to find the update/patch that was applied back then? I recognize use of this function may not represent best practice, yet it is the only way we can do what $(vMix:connected_state) does for us. I'm going to try rolling back to v2.4.2 which is available on the Companion site in hopes that the function returns to proper operation. In the meantime, a huge THANK YOU to the volunteer team that maintains Companion and specifically this vMix module. The time and expertise that is involved is truly appreciated. We really do want to get to v3.1.x when we can! |
Quick update. I just successfully rolled back to v2.4.2 and $(vMix:connected_state) works as advertised! One additional note: we've used $(vMix:connected_state) for 2 years and never had a dropped connection. Our use case is to turn on/off some KASA power modules when vMix starts and stops. We also use this to start a vMix script or two when vMix starts. Hope we can find the v3.1.1. bug and get I squashed! |
One additional note. I noticed this is included under "Variables missing" which is tagged as an enhancement. Perhaps we should separate the $(vMix:connected_state) into a separate thread tagged as a bug since that appears to be what it is. |
Ack I hate seeing that this tread got Hijacked by someone who doesn't respect the enormous work that is being done here in this module ... Thanks for all the hard work Jeff, its very appreciated by the majority of the community ! I see that the variable for Solo made its way in the module :) Thanks . |
Some variables that are usefull are not present in the vmix module and that information is available in the API
Companion 3.1.0+6066-beta-04b04a4b
selectedIndex
for a Powerpoint/Photos/... input type to replace the removed feedback inputSelectedIndexName
solo
for feedback of audio monitoring channel, The feedback for Solo works good, but with the variable you can do expression etc
The text was updated successfully, but these errors were encountered: