Setting CTL numbers programmatically

[jtsteph]

Hello.

I am continuing work on a large patching network. I’m using JSON and user actors to route MIDI controller information and audio modulation to control effects parameters for four separate video "layers." The playback is handled in Resolume, while all the logic is managed in Isadora. Isadora controls Resolume using OSC.

Each video layer uses the same user actor, with an input for the layer number. The layer number is used to extract the appropriate parameter values from a JSON file, allowing me to tweak the entire system by editing the actors for a single layer.

Everything is progressing well, but I sometimes lose track of the parameters during performance while navigating through pages on my Streamdeck controllers. To address this, I'm builing a monitoring control panel that lets me see all the parameters at a glance. The control panel is for monitoring purposes only and doesn’t control parameters directly.

My current challenge is how to get the parameter values from each effect, layer by layer, into the control panel. Ideally, I’d like a way to assign the control numbers programmatically within the "video layers" user actor, so I can maintain the "single user actor" workflow and don’t have to create a large patch elsewhere to expose the effect parameter values and assign them to control numbers.

Here’s how the setup works:

Video Layer Effects Midi to OSC user actor X 4 (OSC is sent to Resolume for playback)

Video layer actor. Parameter values are extracted from a JSON in a global variable 
using parameter names and a .csv lookup table for JSON keys. Parameter values are 
modulated by audio and logic and then routed to the appropriate OSC address inside 
parameter user actors. Currently, I have exposed the parameter values on each effects 
parameter actor. This is where I would like to be able to assign the CTL#s 
programmatically using the layer# input and a lookup table or some math.

 Work in progress: control panel monitor for a single track

Is there a way of assigning CTL#s programmatically

I would grateful for any input.

Thanks, Justin

[bonemap]

@jtsteph

Hi,

I can see why you would want to be able to assign control ID numbers programmatically within your system. However, there is currently no way to do it - that I know of. Exposing the control ID assignment to allow a wire input would be a good option in a large system. I am sure this has been a feature request previously.

The workaround is to deploy User Outputs from the parameters within your layer User Actor and then manually assign Control ID’s to the User Actor outputs - looking at your description that will be around 500 control ID’s to slog through.

It is worth a feature request to make the Control ID system in Isadora accessible to programming and automation. There would need to be some way to define sets of parameter ID’s within the Scene Editor and the Control panel. This could be considered spatial ie. a set of controls relates to an area or zone of actors in the Scene Editor. Therefore, something like a Background module in the Control Panel could correlate to a Background module in the Scene Editor and a set of control ID’s be recognised in association across the defined area. It is perhaps a complicated feature to manage and implement but definitely a worthy one.

Best wishes

Russell

[Armando]

@bonemap I agree with Russel. Let's think about this feature request. What about a control id assignment window with a search field that exposes on one side all the controls that have been put on the control window and on the right all the actors that have been put into the patching window. Both lists can be long but with the search filter we could say I want to see all the video in inputs or all the value inputs, the text inputs, etc. So it is easier to match control IDs. Just an idea.

[jtsteph]

@bonemap said:

User Outputs to the parameters within your layer User Actor and then manually assign Control ID’s to the User Actor outputs

 Thanks for your notes and for the confirmation that it is a manual process at this point. It is what I was afraid of. The issue with doing anything within the Layer user actor is that the 4 tracks are the same actor - when I update one of them, it updates all of them.

I am now considering a globals/broadcasters/listeners network in which the layer number and a csv lookup table will determine the global or broadcaster channels in the "layers" actors. The listeners / global out would be in a "layer monitoring actor" where I would assign the CTL#s. 

Most of the parameters will change very little as I tweak things - I could use globals for these. The "values" outputs will be 30fps data streams - i could use broadcasters/listeners for these. With all 4 tracks this would be about 120 30fps streams + 360 "tweaking" parameters. There are already about 12 30fps broadcaster/listeners in the project. My concern is that this would add system overhead.

The other thing I could think if is to extract the "tweaking parameters" separately from the JSONs in the "layer monitoring actor" and wire the "streaming parameters" in. This would be less pretty, but if it means less overhead it might be the way to go.

@armando said:

Both lists can be long but with the search filter we could say I want to see all the video in inputs or all the value inputs, the text inputs, etc. So it is easier to match control IDs.

Thanks for the idea. Yes, some kind of "routing" interface like this would be useful with perhaps the ability to group the inputs and outputs into folders - this way one could organize things that have a lot of parameters. I do love this idea.

Thanks again for your input. I'll let you know how I get on.

[bonemap]

@jtsteph said:

Hi,

You said,

The issue with doing anything within the Layer user actor is that the 4 tracks are the same actor - when I update one of them, it updates all of them.

This is not the case with top-most Control IDs. You can apply Control IDs to the outputs of a User Actor that are exposed to the topmost scene editor window - these are not updated when you 'save and update all'. These topmost control IDs are copied and pasted with the User Actor, but you can modify them, and they will not update when you update the User Actor. A workaround exists for using them with your one user actor workflow.

Best Wishes

Russell

  

[bonemap]

@armando said:

What about a control id assignment window with a search field that exposes on one side all the controls that have been put on the control window and on the right all the actors that have been put into the patching window. Both lists can be long but with the search filter we could say I want to see all the video in inputs or all the value inputs, the text inputs, etc. So it is easier to match control IDs.

 Hi Armando,

Great idea, but how would this work? for one, the actors in the scene editor have, by default, identical names - every Wave Generator is indistinguishable by name - unless they are renamed. Then, every parameter of each actor type has the same name. A list item would require a unique naming system for each instance of an actor and each parameter of each actor. Wave Generator 01/frequency, Wave Generator 02/phase etc. What might work is for each actor to be assigned a unique name instance when placed in the Scene Editor. Control IDs could then be matched to a pre-set ID naming system. Another possibility would be to expose the property inspector popup (that has the control assignment for each parameter) differently, such as an option toggle that appends a parameter's inspector properties with the same input port style of the parent actor - thus exposing control ID and Scale variables to programmatic linking. In essence, actors could incorporate an option to expand a parameter's properties with accessible ports. 

Best Wishes

Russell

[jtsteph]

@bonemap and @Armando 

I love the idea of unique addresses...like OSC. You could map the whole thing out in a spreadsheet this way, which is how I have been doing all my midi and OSC mapping. It's very powerful and flexible.

I have another idea that is not a programmatic solution, but perhaps something easier to implement (?) that would save time for users:  

Perhaps a functionality that would allow the user to create actor/controller connection by selecting an actor value with a combo-key-click in the patching window and then a combo-key-click in the controller window on the controller. When this is done, the user could be prompted for a CTL# or have isadora choose an free CTL#. 

In addition, for controllers than have multiple values (IE X/Y coorinates), when combo-key-click-ing the controller, the user would get a prompt to specify which controller value will be connected to the actor value.

Just thinking out loud.

[Armando]

@bonemap Hello, that is why I asked the collective wisdom to participate. I imagined (but didn't say) that in the window I proposed, a value (i.e."rate" property of an envelope generator),  when clicking an entry of the window,  hilights (selects) the right envelope generator in the patching window. Again, just an idea. Mark is generally great at imagining better and simpler ways to do that. Another idea is to highlight in red all the control id number in each control that are not yet connected to a property in an actor in the patching window is red until it is connected to a property.

And I'd love the same thing in the patching window. As a matter of fact, at the moment, if in the patching window, an actor has a property with a control id it it means that there is a control that it is linked to. But if I erase the control of the actor with the same control ID, said control ID keeps looking the same. Now, this has never been a problem, for me, but in a large patch with dozens of controls having a red control ID in actors AND in controls that become red if either have been erased could make us see immediately the problem visually. Instead of looking through numbers

Another advantage of this window could be reassigning id. I generally tend to separate with 10 or 100. The 100 is video stuff, the 200 is the audio stuff, 300 is light, 400 sensors, 500 mocap 600 scenes activation. etc. In this hypothetical window a search field could function as a multi-criteria filter.

one way to filter is by number. This could also be a way to sort by number all the control IDs. Another filtering could be by actor name (even with multiple trigger text actors, for instance they could be put in a list. Also filtering could be by control name and put in a list. Clicking on a control in the control widow could hilight the right control and the right actor that are connected with the same control ID.

I am just trying to think wth all of you.

All the best

[jtsteph]

Just picking this up again after spending a bit of time figuring out the SHOW/HIDE control actors. This system gave me an idea about how controller data could be sent and recieved programatically. I wonder if sending/recieveing control panel data programmatically could be done using the same Controller Address functionality currently being use for the show/hide actor. 

It could perhaps be a second way of sending/receiving information to and from controllers - there could be a couple new actors: Send Controller Data and Recieve Controller Data. These would use the same addressing system used in the SHOW/HIDE controls.

The user can figure out how they want to to address their controller data sharing using the addresses, wildcards etc. This would allow the user to use lookup tables, or dynamic systems to send and recieve controller data. It would  mean that the address on the contols themselves would still need to be assigned manually, but it would allow for greater flexibility in how they are connected to patches. Using the controller group address, the same controls could be used for different states in the patch (for example track 1, track 2, track 3 in a video mixing system)

This would maintain the current CTL# functionality, but add the "Controller Data Address" functionality.

Just some thoughts.

- J