Thanks so much to both of you! Helpful to see what direction to move in. I really appreciate it!

@gertjanb

Aha!  Thanks for the info.  I was trying to connect directly to the camera, rather than the app.  The app is a little glitchy for me, and I'd rather use the control functionality of VISCA, but I might have to go the OSC route.

@tr742 said:

projected stages keystoning

It's also worth noting that you can also make a background Scene where you send all your video and then route it to the right Projector actor. Using this global projection mapping method, you only ever need to have one Projector (in the entire file) per Stage if your keystoning/mapping is the same for every Scene. It has the added benefit that if you ever have the need for different keystoning for the same Stage within the same file in different Scenes, you can use this same method, but use the actor chain Enter Scene Trigger > Trigger Value (2) > Broadcaster in the Scene that needs the "specialty" mapping/keystoning to affect a Router actor in the background mapping Scene to change the video's route so that instead of going to the "normal" mapped Projector actor (1 on the Router actor) the video goes to the "specialty" mapped Projector actor (2 on the Router actor), then have another Enter Scene Trigger > Trigger Value (1) > Broadcaster in the next Scene to switch the Router back.

@woland Once again, Woland you amaze me with little things I didn't know about Isadora..... thanks for being here !

@woland Very cool. I think this might be a great way to "save" the current state of a patch. When I build the the show, it would be really great if I could recall things using a simple switcher rather than creating a whole bunch of snapshots and scenes that I will inevitably get lost in.

I just put together a cool little recall actor that uses a pulse generator and some javascript to output a stream of midi to the controller to update their button states from the JSON. it seems to be working well and replaces a truly massive patch.

My previous recall patch. I put an entire page of 32 buttons in one user actor and duplicated this 9 times:

The new recall patch.

It might not be needed, but I thought that sending the midi information back to the controller as a stream would be more reliable than just sending it at the speed of Javascript. I thought to use a pulse generator to step through the javascript one JSON segment at a time. When the executeRecall is triggered, it turns the Processing_flag on which starts the Pulse Generator. Each pulse moves through a segment of the JSON and sends the stored values to the midi controller based on the track, page and button number. When it's finished it turns the processing flag back to 0. 

I started working with the pulse generator at 60hz and worked up to 480hz. It's all seemingly still sending reliably at 480hz so I stopped there. The whole thing is working smoothly and so much lighter than what I was doing before.

I am kind of crying about the time spent on the other patch, but perhaps it took me the time it took in order to sort out the procedures and functionality that I needed which really emerged as I worked.

With all of my midi stuff running I have .6% load now! Even when I initiate a recall, it hardly bumps the load at all.

@dusx Thanks. Given this, as most of my calculators are used in momentary situations (button press, dial turn) I think that Javascript makes more sense. It greatly simplifies my patching. If I run into a situation where they are updating as a stream, I'll try to use calculators. 

I appreciate your input. 

Best, J

@jtsteph said:

It much easier to put these together in Javascript, but I can do them with calculators if its quicker

 When we first added the Javascript actor, I did a series of deep tests to determine exactly this. What I found was that I could use hundreds/thousands of JS actors doing math and still have good performance... and I could also use Thousands of the Calculator actors.

I suspect you will have very similar performance either way, however; I believe a series of Calculator actors will be slightly less heavy.

Due to the nature and easy of doing this in JS, I would personally use JS. But you could easily build both and use a global to switch between the methods used.. allowing you to make a change if performance required it.

@jtsteph said:

The "persistent" state

This made me realize that there's also the Data Array actor. You could write your information to a text file whenever you need to update it and then read the most recent information from that text file in any Scene.

@woland said:

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

 I think this will be more reliable. The "persistent" state of the outputs is not always consistent unless snapshotting. I will try working with global values or broadcaster/listeners. Thanks, @Woland .

@em_tx

I'm also happy to meet with you and take a stab at this.