[ANSWERED, NOT BUG] Type inconsistency

Fred

There is a lot of type inconsistency in Isadora. Things like the output of the keytable watcher (most underrated actor!) cannot directly control a router or selector - this seems really odd as it must be an integer, but I need to put absolute value in between the two to use them together.

The output of a toggle is the same, connected to the speed input it will read -2 (off) and +2 (on), but this is a boolean so should be 0 and 1. Again the absolute value actor fixes this.

I have come across this for years and these are the two I found yesterday but there are a lot of cases where this occurs. It would be great to see an overhaul of the types identifiers and have them logical and consistent.

Fred

Skulpture

@fred said:

There is a lot of type inconsistency in Isadora. Things like the output of the keytable watcher (most underrated actor!) cannot directly control a router or selector - this seems really odd as it must be an integer, but I need to put absolute value in between the two to use them together. The output of a toggle is the same, connected to the speed input it will read -2 (off) and +2 (on), but this is a boolean so should be 0 and 1. Again the absolute value actor fixes this.I have come across this for years and these are the two I found yesterday but there are a lot of cases where this occurs. It would be great to see an overhaul of the types identifiers and have them logical and consistent.Fred

What version were you using, because I have a feeling this is going to change/has changed in V4?

Woland

@fred

What you are running into is the automatic scaling in Isadora, not a type inconsistency. Admittedly, it's not very transparent what's happening, but it's doing exactly what it's supposed to do. Automatic scaling occurs when you connect an output with a fixed range (like the output of the Key Table Watcher [Range: 1-255] and the Toggle actor [Range: 0-1]) to an input with a fixed range (like the 'select' input of a Selector or Router actor with three inputs/outputs [Range: 1-3] or the 'speed' input of a Movie Player actor [Range: -2 to 2]).

Here's a file explaining this concept: automatic-scaling-explained-2023-07-19-3.2.6.izz

Here's the explanation of the interaction you described between a Key Table Watcher actor and a Router actor. (Red is what happens by default, green is how to get the behavior you want).

Here's the explanation of the interaction you described between a Toggle actor and a Movie Player actor. (Red is what happens by default, green is how to get the behavior you want).

Here's TroikaTronix's YouTube Tutorial about value scaling in Isadora for any interested parties.

Best wishes,

Woland

Fred

@woland so that sort of makes sense but it does seem like a hindrance. When you see a number you should be able to use the number. Maybe an absolute tick box on the output where you can select scaling?

This stops really making sense when we change types though. I get it that the minimum and maximum speeds for video are -2 to 2. The scaling explains why a Boolean value becomes -2 or 2. But what about the other speeds in between??? We now only get the minimum and maximum speed, nothing else. It is explainable but I don’t think logical. Considering use cases I can see and have tried a lot of times thinking true or false are 0 or 1 so I should be able to set things to 0 or 1 with a toggle. This is common. I think it is much less common for anyone to have said. I want to use a toggle to switch between maximum and minimum.

The is a consistent aberration when changing types from one with more precision to one with less,

Like integers to floating point values. Again we get the range but lose the resolution and that doesn’t make much sense. A float input has. Lot of precision and that is all lost when we connect it to a integer It does adhere strongly to the design pattern of scaling but it’s hard to see if that is actually useful, especially compared to if it acted as an absolute value or had that as an option

So maybe this should be a feature request to have an absolute tickbox on the output of anything that has a number so we can choose it to be absolute there instead of having to add an actor. In fact as i mentioned having proper scaling and absolute options on every value out would be amazing.

For reference I I had a show to do, no prep allowed, 12 blended projectors in another system and I could only send NDI. This was a big international artist that just arrived and expected, rightfully so, that things got in shape on the spot and fast. The features I am requesting all would have helped that along and made each step faster. I also think that some of these things are a bit more logical and could be easier for new users too.

Fred

@skulpture the latest beta.

Woland

@fred said:

I get it that the minimum and maximum speeds for video are -2 to 2. The scaling explains why a Boolean value becomes -2 or 2. But what about the other speeds in between??? We now only get the minimum and maximum speed, nothing else. It is explainable but I don’t think logical.

Your request to be able to disable scaling for an input or output makes an enormous amount of sense. I'd love that too and will definitely log it, but what you've written here I disagree with.

If you have five people (-2, -1, 0, 1, 2) in a room with no windows and two doors (0 and 1) and you instruct everyone who is shorter than person 0 to leave through door 0 and everyone who is taller than person 0 to leave through door 1, there are only two possible options for where people can exit.
If I have two people (0 and 1) in a room with no windows and five doors (-2, -1, 0, 1, 2), if I ask the shortest person to leave through the door with the smallest number and the tallest person to leave through the highest-numbered door, again, there are only two options, -2 and 2.
If I have six apples and two baskets (0 and 1), I can't sort the apples into more than two groups because I've only got two containers.
If a sensor could tell you if I was in the left half of my flat or the right half of my flat at all times, that's all you'd be able to know from the sensor data because that's the entire range of data the sensor could provide, left or right, regardless of how close to or far I was away from either the left or right wall (the values in between).

You only get the minimum and maximum speed because with a boolean value, you can only produce the number that's the top of the range (1) and the number that's the bottom of the range (0) so when you scale that to any other range, you're always going to get the bottom of the range and the top of the range. If you want to get to the numbers in between at the moment, you need to use the enter matching ranges manually or do something tricky like stop a Gate from mutating by connecting it to another Gate before connecting the first Gate to your Key Table Watcher and Selector actors. (By the way, any numerical THRU User Actors you have will serve this purpose if you didn't pre-assign them any min or max values because they can't mutate their ranges: https://jmp.sh/T4jawiP2.)

Fred

@woland thanks for the detailed reply. The analogies are clear, but I do feel they are not super relevant as we are programming video not getting different height people out doors 😀

Jokes aside, again, I do understand the scaling, but I think sticking to rules for the sake of it might not be the best option. I want to suggest a few scenarios where the scaling seems to fail.

FIrst is the router and selector - the system obviously stops here with whatever mechanism is controlling it. If this scaling worked consistently I should be able to connect a counter set to a min of 0 and max of 100 and have the router or selector would switch every 25, but instead it accepts the output of the counter as an absolute value.

But this does scale with the wave generator:

But if I convert the float of the wave generator to an integer, it stops scaling as the design would suggest (the user actor just has a float in and integer out).

This is where scaling between different types seems strange.

Some actors with a variable number of inputs and outputs will update the scaling to match, the keytable actor always has its output max at 255 by default. This one would make more sense to update the scale max to the number of keys. If there are 10 keys there is no way to get to 255. This seems inconsistent with the design, the max should start off reflecting the max value that can be output from that actor. I guess if you set a different max and then change the number of keys there is a decision to make as to whether to force update the max, but if you have done made this change I guess you are ready to adjust it.

I do still feel that the use case for a boolean giving the max and min values by default is so rare that it would make more sense to have these as absolute, but again an absolute value out checkbox on each output would be cool.