During the development of my various vMix VB.Net based scripts (see https://github.com/rse/vmix-scripts/) I've stumbled over the following shortcomings, which I would like to see improved in future versions of vMix:

1. Missing Function/Sub-Routines: for unknown reasons in the VB.Net 2.0 environment of vMix it seems one cannot declare neither functions ("function ... end function") nor sub-routines ("sub ... end sub"). This way one cannot define helper functions for complex scripts in order to reduce the script complexity. For one script I even had to change the algorithm from a recursive approach to an interactive one in order to cope with the limitation. VB.Net 2.0 is already a very old and nasty scripting environment, but without even functions/subs it is extremely nasty. Please support functions!

2. Missing Input Type: Although in the vMix documentation the type of inputs is defined to be "Input", this type is not available. There is only a global symbol "Input" for accessing things like Input.Output but no "Input" TYPE. In error messages vMix also tells one that the type of inputs actually internally is vMix.Scripting.Internal.Input. But even this cannot be used as a type as any "vMix." is not allowed. Please expose the type of inputs.

3. Missing Key on Inputs: One can go from numbers/names of inputs to Input-type-based objects via Input.Find(<name>) or Input.Find(<number>), but there seems to be no way to go from Input-type objects to the numbers/names. At least there is no ".Name" or ".Key" or whatever property on Input-type objects exposed. This e.g. dramatically limits the use of Input.Output and Input.Preview. Please expose at least the number and name of an input through a property.

4. Weak API Structure: the vMix API exposes an XML structure with some information on the current vMix configuration. Unfortunately, it is a rather weak exposure of the configuration only. Lots of information (e.g. whether a layer is enabled or disabled) is not exposed. This way one cannot easily react on those configuration aspects from within a script.

Yes and no. YES, in general I agree that when you would place the scripting code into an external program you can use an arbitrary scripting environment (in my case it would be Node.js or something like this). But, NO, this means you get lots of latency because of the involved HTTP API access (even over localhost). For instance, check out my Audio-Sidechain script (https://github.com/rse/vmix-scripts/blob/master/audio-sidechain.vb): every 10ms it has to check the state of vMix in order to perform its actions. It works great, but only because it is running from WITHIN vMix itself. It would fail to work if running externally because of the extra latencies. Also, there is the nasty case that for a complex production one needs multiple scripts anyway. And currently we can just store them as "local scripts" with the event preset. If the scripts are externally, they have to be kept in sync with the preset and also have to be started manually when vMix starts, etc. So, I see your point, of course. But in practice external scripting gets somewhat nasty.

If you can do this by accessing the vMix API then yes (i.s. not the HTTP calls method).


+1 - Implementation is incomplete. It should be finished.

+1 on subroutines and functions. Silly that you can't use them. Makes for much poorer scripts without them.

Microsoft has announced they are deprecating the use of VbScripting in programs so this unfulfilled request is now obsolete.

In it's place I suggest vMix create an API DLL that can be used to create "script" DLLS that vMix can call and use instead of the internal VBScripting language so that "scripts" for vMix could be made using Visual Studio in any language supported by Visual Studio.

It should include all the API calls and objects with properties that can be queried and set that currently exist plus events that can be "subscribed" to allow the creation of more sophisticated and substantially faster scripting hopefully allowing the additional control that would allow us to provide much more comprehensive and functional scripts AND perhaps allow control integration to and from other programs like lighting controllers and sound systems.

Once that is in place the existing VBScript system could be left to run for a few years while people migrate to the new system then eventually removed.