Add anchor to any connection

Fred

It would be great to have an add anchor function to any connection - by anchor I mean something like an empty user actor that passes the data transparently. This would allow for fast experimentation when editing. I know that now a lot of actors can be inserted into a chain by putting them in the right place, but lots of actors (and way more user actors), wont work with that - maybe because their inputs and outputs are mutable? Or maybe because, like on the gate, the input and output are not horizontally aligned.

For fast work in situ having the ability to work around this by adding anchors would be great (especially if they can work in a block. In the pic below (i know it was messy but I had an hour to make a patch for a gig in situ with the artist) there are 7 values. If I could run down these and make a pair of anchors between the outputs and inputs it would be much easier to add or remove things in the chain without messing up the exiting connections.

Skulpture

@fred I interpret this as a null actor? So an actor that does nothing other than it has a point in the chain that allows video to pass through? It would be handy in that case if it had a very small preview window (togglable) for reference?

Notdoc

@fred

i drag in an empty GLSL Actor to do exactly what you describe

jfg

@fred

for this purpose I made a macro named "value thru"

Best regards,

Jean-François

Woland

@jfg said:

for this purpose I made a macro named "value thru"

Same, but I did all the data types: thru-user-actors-2023-11-03.zip

Woland

@fred said:

For fast work in situ having the ability to work around this by adding anchors would be great (especially if they can work in a block. In the pic below (i know it was messy but I had an hour to make a patch for a gig in situ with the artist) there are 7 values. If I could run down these and make a pair of anchors between the outputs and inputs it would be much easier to add or remove things in the chain without messing up the exiting connections.

I almost always put Gate actors in as I'm building to use as "breakouts" so they're already there if I need to make another connection, with the added bonus that I already have the ability to allow or stop the flow of data in the future if I need to.

I do this especially often right after User Inputs or before User Outputs inside User Actors and Macros.

I also generally use Gates as a way to move the Control ID one level upstream from a User Actor (because I try to only have one instance of any given Control ID in every patch and feed everything from that same location rather than putting it in multiple places and running the risk of needing to change it and forgetting to change it in one or more locations). This also prevents the User Actor from having Control IDs built into them, so if I save them to my Global User Actor Folder or want to share them, they don't have random Control IDs attached to them by default.

This has the added benefit of allowing me to easily enable/disable the use of that Control ID, and I can also rename them and make them start with a "#" so that I can search up my Control IDs using the Hashtag List at the bottom right of the Scene Editor

Additionally, when I've built a block of actors and want to wrap it in a User Actor, I'll generally connect everything up using Gates, label the Gates, and give them the right ranges so that when I copy the whole block and paste it into a fresh User Actor, it's super clear what inputs and outputs I need to create and what their ranges, data types, and ranges need to be. (I didn't do that for every input and output in the User Actor below, but I highlighted a couple examples of that inside it.)

Here's a better example:

But yes, I totally understand your desire to be able to speed up patching for complex files:

Best wishes,

Woland

Fred

@woland yep I sometimes use gates and also have made all the pass through user actors (but why aren’t they mutable though??? I always thought I could just use one and have it match the input type).

Anyway the anchor or null actor or pass through would just be handier than this that’s all.

jfg

@fred said:

always thought I could just use one and have it match the input type).

that's exactly what the "gate actor" does, with the added bonus of being a switch.

Best regards,

Jean-François

Woland

@fred said:

I always thought I could just use one and have it match the input type

I'd love to have a searchable one as well, but right now you can get pretty close by just hiding the 'gate' input of a Gate actor.

If one could write C++ code, using the SDK to make this actor should be fairly easy. (Though now that I realized that just taking the code for the Gate actor and removing the function of the top two inputs + removing the icon would be a game-changer, I'll be pestering Mark about this after the release of Isadora 4 )

Woland

@jfg said:

that's exactly what the "gate actor" does, with the added bonus of being a switch.

Yes but I totally understand the desire for one that's ready to use out of the box, is searchable, and can be hotlinked across the top. The on/off input on the Gate prevents it from working like this, and you don't want to make that input hidden by default because then you'd have to unhide it every time you wanted a Gate actor to function as an actual gate.

jfg

@woland said:

Yes but I totally understand the desire for one that's ready to use out of the box, is searchable, and can be hotlinked across the top. The on/off input on the Gate prevents it from working like this

I agree with you but I think there is more important problems to solve before (e.g. the sound in the movie player). A simple solution would perhaps be to reverse the order of the inputs: "in" as first and the *gate" as second. Also for the "Limit-scale value" actor there is a similar problem. Moving the value input to the top of the actor would simplify things.

Best regards,

Jean-François

Woland

@jfg said:

A simple solution would perhaps be to reverse the order of the inputs: "in" as first and the *gate" as second.

If I recall correctly, actors have their inputs executed top to bottom, so I believe it needs to know whether the Gate is on or off before it accepts data.

@jfg said:

I agree with you but I think there is more important problems to solve before (e.g. the sound in the movie player).

Multi-channel audio routing in the Movie Player is a job that will take several weeks of programming and testing to complete. Possibly months. Removing the top input from the Gate actor to make a mutable thru actor would be like 20 minutes of programming and 20 minutes of testing, an hour of each max. They're not on the same level, so it makes no sense to compare them.