@dillthekraut said:

Mutable values (the ones with the green connectors) take the ranges from the actor values you connect them to

It sounds like this to me too. The Set and Get Global Values actors' 'value #' inputs/outputs start with a default range of "MIN" and "MAX". They can only have a set range if they're manually given one through a user setting a range via the Property Inspector or if they're connected to an input/output of another actor that has a set range. Perhaps a manual range was set for one instance of a Get Global Values actor that you were using for something, then you copied it and used it somewhere else.

It's worth saying that if you disconnect a mutable actor from the actors around it, right-click it, then select "Reset to Default Values" it'll set the ranges back to the default.  Another tip I'll give is that you can select the links connected to your mutable actor and use Actors > Detach Link at Input and Actors > Detach Link at Output to just take the links connected to a mutable actor and "store" them temporarily by attaching them to a random Gate actor or something, then you can free up your mutable actor, reset its values to default, then re-instate its connections using Actors > Detach Link at Input and Actors > Detach Link at Output to take them back from the "storage" Gates.

@miketutaj

Thanks for offering to share your workaround. It would be wonderful if you could post the file here for others to use if/when they run across this thread.

@wwachalovsky said:

additionally, when I am using the Send PJLink actor, Isadora stops being able to receive OSC commands

 Yes, we've had other reports of this issue and are looking into it.

@jtsteph said:

I got it working using the persitent state of the Javascript output. I added an enter scene trigger that sends the output to a new input called stored JSON, then I trigger an initialize on a small delay, which builds the JSON from the last JSON state. A bit more complex, but not overly so.

You could also keep all your control actors in a background Scene that stays active so that you never leave the Scene that needs the info. You can send data to and receive data from the background Scene using either Broadcaster actors (only sends data when a value is pushed into it) and Listener actors (new data is not spit out unless data is pushed into the Broadcaster while the Listener is active in a Scene) or Set/Get Global Values actors (Set Global Values sends all its values to all relevant Get Global Values actors whenever any of its values has something pushed in and also upon entering the Scene and Get pushes all of its values out whenever it receives any new data from Set Global Values and upon entering a Scene).

This file isn't entirely about background Scenes, but explains how to always keep your "Control" Scene active: 2018-global-mapping-template.zip

1. Go to the Scene Named "CONTROLS" and look inside the Macro named "Broadcast CONTROLS Scene # Macro" near the top center
2. Go to the Scene named "SCENE Template" and look inside the User Actor named "Activate CONTROLS Scene"

@jtoenjes said:

this behavior seems to be particular to Oculus screen cast

 There might not be anything we can do about it then, unfortunately

@jtoenjes I had a nasty time capturing an Oculus out a few years ago. This may not be what you are looking for but I used a chromecast to get the stream and then plugged that into an hdmi splitter that happened to strip the HDCP protection. Then I could capture it via a capture card with an HDMI in. It was less intensive for the computer this way as well. 

I got it working using the persitent state of the Javascript output. I added an enter scene trigger that sends the output to a new input called stored JSON, then I trigger an initialize on a small delay, which builds the JSON from the last JSON state. A bit more complex, but not overly so.

streamdeck-xl-video-player-track-buttons-json.izz

@woland. Your javascript for the toggles was inspiring and lead me to an complete shift in how I am handling midi. The idea of generating the JSON values for the toggle based on the button pressed and the use of a global variable to hold the current state of the JSON were revelations to me. 

Previously, I had created a receiver user actor that I used for each page which would take midi values from a defined range of controller#s and then output values for each button. These were then combined into a JSON for the page. I itterated this over the 9 pages (2-10) and then combined this into the larger JSON that you have seen.

Here's some grabs of that build. It's huge. 

Looking at how you did your Javascript I broke it down into chunks: the calculation of page#/button# based on my midi layout, calculate which midi values were for the only-one-on toggles (designated buttons) and which were for non designated buttons. I created a script  (with the help of CHATGPT) that would output the the correct page/button and a booelan each for designed and non designated button presses for midi values that are in range for a given track. I filter the boolean for the designated buttons for 0 so that the script will not trigger when the button is released. 

From there I used your only-one toggle generation for the designated buttons and am updating the JSON with any non-designed button values - I have some value cycles on some buttons to choose audio track, bank/page group etc. The result is this tiny thing that builds and updates my entire JSON for the Streamdeck XL. 

While I am a bit sad to throw away all that other work, I learned a lot and am ultimately very happy to find this sleak solution. It will make me think much differently about how to solve some of problems moving forward. I am also slowing learning some more advanced Javascript from you and from Chat GPT I am an oldschool Basic/Pascal/C guy from my earlier years. I know how to break a problem down, but I am unfamilar with many Javascript operations, the way it works with classes, and the fineries of its syntax....but i'm learning.

A quick question for you. It looks like the global variable in the javascript actor is cleared when changing scenes. This  causes an error for me when I reenter the scene. Is there a way in javascript to store a global variable that is persistent, or would I use a global variable actor and trigger this on scene enter to restore the current state of the JSON for the JSON Generating Javascript? 

Thank-you again for all of your help.  

@wwachalovsky Just following up on this as it continues to be an issue for me.  In my experience the crashes only occur when jumping between scenes at the same time as sending a plink command.  I've come up with a successful workaround by creating a second instance of Isadora that only sits in one scene, but receives command via a listener (or OSC) from the main show file which broadcasts the desired triggers to the pj link actor in this secondary instance.  It's maybe a little clumsy, but it has resolved my issue.  I can share a file to give you an example of how this works if that's useful.

@fred Thanks for this. I have to wrap my head around it since I'm not a programmer...