Easy Snapshots For User Actors With User Actors Inside Them

Woland

Hello all,

I theoretically made a system that allows for Snapshots to control all of the internal values of a User Actor/Macro while only requiring a single User Input on the User actor. Great for multilayered User Actors built for MIDI controllers (I should think).

This is just a proof of concept at this point. I'm sure it could be refined further. Sorry in advance for the lack of explanation in this post, I'm a bit tired so I explained with screenshots.

>>>ISADORA PATCH, USER ACTORS, PICTURES<<<

Shoutout to @DusX for the Javascript system.

I haven't put this into use for a specific purpose, so I'm sure it could be refined. If you do improve the system, I'd love for you to annotate your changes and re-upload an example Patch so that others can use the improved version.

Best wishes,

Woland

jtsteph

Hello, @Woland .

Using your input on this thread and your thread on the @DusX method of grouping multiple values into a JSON string using the JS actor, I have managed to put together a system to enable me to snapshot the state of my midi controller values, and recall those values when entering a scene. In addition, I worked to be able to send this state back to the midi controller to update the indicators and rotary encoder values.

This system will enable me to have multiple "setups" for my system. As I am working as a part of an improvised audio visual group, this will give me readily available starting points for my improvisations.

I have chosen, in my workflow here, a preference for operating scene by scene rather than snapshot by snapshot. It is a more verbose manner of working in which I can label the scenes according to what they do. My show methodology would be to duplicate my patch into multiple scenes, work out something cool, snapshot it, and then move on to the next duplicated scene. During performance, I will use the scenes as starting point for each improvisation.

I am including some screenshots here to explain what I did. I have not yet integrated this into my performance patches, but this "midi controller snapshot" rig will be usable by me in all manner of situations. You will need to excuse my patching style - it's not quite as tidy as many of the users here.

-----------------------------------

Here is my top level: I choose the controller port, channel(track#), and snapshot to recall on scene enter.

I use 4 presets on the BCR2000, each with identical CTL ID#s but with different channels. Each channel is assigned to a video track.

The BCR lets you easily switch between user defined presets. I used the excellent Mountain Utilities "BCR MANAGER" to program the CTL ID#s in a way that each ID# is +1 of the same CTL on the previous rail. This means I only need to store the ID#s for one rail and can calculate the other based on that.

Here is the top level:

-------------------------------------------
My Global Values User actor is used to set the midi controller id values:

-----------------------------------

The MIDI out to JSON uses a user actor that receives the midi values from the BCR rail by rail. These are input into the JSON Grouping actor that @Woland put together. I used two JSON groups as there are 108 values total which is more than the 99 possible inputs.

-----------------------------------------------

For completeness, here is the user actor that receives the midi values from the BCR. It calculates the controller id# using the Global Values from the first rail and the user defined BCR RAIL#.

-----------------------------------------------------

Back to the main top level. The JSON values can be stored in a snapshot. When I enter the scene it recalls the snapshot# I define and then sends these values to the BCR to update the rotary encoder and toggle button values (it uses a user actor that is the reverse the user actor that retrieves the midi values from the bcr). To my delight, the BCR picks up all the update values simultaneously without having to put then into any kind of time based midi stream (yuck).

This patch will serve as the bases for not only this project, but for any project in which I use midi controllers (like all of my projects :-)
In addition to the Ungrouping patch by @Woland based on the awesome work of @DusX I worked out a couple of ways of parsing the JSON.

--------------------------------
Large ungroup without @DusX 's addition of the array size (I need to keep my group and ungroup indexes consistent for my workflow)

function main()
{
    var parsed = JSON.parse(arguments[0]);
    var array = [];
    for (elem in parsed ) {
       array.push(parsed [elem]);
    }
    
    return array;
}

-------------------------------
Retrieve a single midi value from the JSON. Input 1 is the JSON. Input 2 is the index for the value.

function main()
{
    var parsed = JSON.parse(arguments[0]);
    var array = [];
    var arrayindex = arguments[1];
    array.push(parsed [arrayindex]);
    return array;
    }

--------------------------
Retrieve a range of values from the JSON. Input 1 is the JSON, input 2 is the starting index of the values you wish to retreive, input 3 is the end of the values you wish to retrieve.

function main()
{
    var parsed = JSON.parse(arguments[0]);
    var array = [];
    var indexstart = arguments[1];
    var indexend = arguments[2];
    var i;
    for (i = indexstart; i<= indexend; i++) {
    array.push(parsed [i]);}
    return array;
    }

In any event. Thanks to @Woland and @DusX for their work. Standing on the shoulders of giants makes our work easier.

- J

DusX

@jtsteph

Looks great!

Nice clean patching & powerful.

jtsteph

@Woland . As I am digging in to optimize all of this in izzy3, I decided to switch to a pair of midifighter twisters. They are very logically laid out so doing the patching is about 100% easier. The CC values for the Encoder, Push Encoder and Push Button are all the same for each bank, they just change the channel. I am wondering if there is a more elegant way to do the bank selection. I am using a router to feed triggers to tigger text with the given names of global variables for the cc id numbers. It's in the "Twister Bank Selector" user actor here. (I cannot seem to get the stills to display in the right order, so I have numbered them here)

# 3 Bank Selector

#1 Json Out

#2 Twister Bank Out

Juriaan

Hi there @jtsteph

This is the actor that I use for the Midi Fighter Twister, feel free to take a look :) (I absolute love my Midi Fighters !).

All the knobs are in my setup in "Super Knob mode". In the Twister Scene you see what I do with two seperate user actors, one is the main logic, one is the receiver. Just select the bank and the knob that you wish to receive and you are done. It also allows you to send it using a broadcaster to an other scene (Please be aware that the Twister scene needs to be active in the background)

MidiFighterTwister.izz

jtsteph

@juriaan. Thanks for this. I will check it out tomorrow!
Edit: just took a quick peruse. Super cool! I am not using superknobs - but am using push encoders and toggles. I am particularly interested in your Parser actor! Very powerful.

Woland

Upload your magnificent creation to the Plugin page ;)

jtsteph

@juriaan. Do you find the the broadcast/receiver actors slow things down for you at all? I will be using 2 twisters with encoders, push encoders and toggle buttons over 4 banks = 348 possible receivers from 8 senders ( i organized my jsons into small groups based on the banks - my javascript is not very good :-).

Juriaan

Hi there @jsteph,

I personally never tried it out with 348 possible receivers. I don't think that Isadora will take an massive hit, but with anything with Isadora, try it out and optimize if it seems that it doesn't work out.

If you ever need help with some JavaScript, hit me up at the forums or send me an email at hello@juriaan.me

DusX

@jtsteph said:

broadcast/receiver actors slow things down

Assuming you mean broadcast listeners, I think it is very unlikely that these actors will have any noticeable overhead. The grouping/ungrouping of the JSON is far more processing intensive, however; my testing indicates you can use loads of it before you see any real effect. Still its something to consider.. the ungrouping is heavier than grouping.

jtsteph

@juriaan. Thanks for your input and offer to help with some Javascript. I am going to work through my patch and see if there is not some way of optimizing it. Quick question for you. You are updating your actors based on a pulse. Is this to optimize overhead?

jtsteph

@dusx Yes. I mean the broadcast listeners. Thanks for your input on the overhead of the overhead of broadcast listeners vs Javascript JSON unpacking. Perhaps rather than unpacking single values from the JSON, I should unpack a bunch at once (IE a whole row from the Twister) and route them from there. I will run some tests.

Juriaan

@jtsteph

No that is because Isadora JavaScript actor has some gotcha's, the final input needs to be triggered for the code to run. Since I use Pressed / Released triggers this had to built in for the sole purpose of forcing Isadora to run the code and give me the correct values. If you remove that you won't get proper triggers :)