New Counter Actor Behavior - Please Discuss

mark

Dear Community,

A user noticed a subtle change I made to the Counter and Float Counter actors in 2.0. So, I wanted to bring to your attention and start a discussion about what makes the most sense to the most people.

n 1.3.1f06, when you change the 'minimum' or 'maximum' input of the Counter actor, it would automatically

Adjust the Scale Min/Max of the 'cur value' input so that Scale Min matched the 'minimum' input, and Scale Max matched the 'maximum' input.
Adjust the Limit Min/Max of the 'output' output so that Limit Min matched the 'minimum' input, and Limit Max matched the 'maximum' input.

to match the new 'minimum' or 'maximum' value.

Over the past couple of years, I decided this was a bad design decision because Isadora was doing this "behind your back" -- it wasn't clear to everyone that this was even happening. Furthermore, the automatic scaling that would occur when connecting the Counter's output to other actors was often not the behavior that was desired. (At least this was very often the case for my own shows.) Usually -- at least for the output -- you really wanted a Limit Min/Max value of MIN and MAX, to prevent any automatic scaling.

So, I decided to change the behavior of this actor. In Isadora 2.0, you must set the Scale Min/Max of the 'cur value' input, or the Limit Min/Max of the output manually. Changing the 'minimum' or 'maximum' input has no effect on the scaling parameters of the 'cur value' input or the 'output' output.

What would you all prefer? I feel like the new behavior should be the correct behavior, but I'm very willing to hear differing opinions.

The other option would be to add an 'auto limit' input that can be turned on or off. Turn it on, and the behavior would work as it did in 1.3.1f06\. Leave it off, and it uses the new behavior. I would only do this if there are very strong arguments that both behaviors are useful.

Let me know what you all think.

Thanks,

Mark

LPmode

I like the newer approach, where min-max aren't automatically set. I have had a few occasions where the input fields needed to be set dynamically but the min max values were stuck to an previous range and the only way to fix that was to use a new actor. It's was not just the counter actor and it would be better in my opinion if the behavior was not automatically set.

dbini

exactly what LPmode said.

DusX

Me too.

Its cases where I want to change the min and max dynamically (rather often actually) where this has been a big bother.

I think 1 or 2 other actors do similar, so I personally would like to ensure all work like the new counter.

vanakaru

I find the new way a bit more intuitive.

mark

OK, well, I think it's decided. I will keep the new Counter and Float Counter actors so that they don't do anything "behind your back." It will all be manual. I agree that this should be the situation for all actors. I need to go through and figure out which ones might be doing this still. I'll post a list once I've determined which ones.

Best Wishes,

Mark

gunther

I also like the new behaviour more. Moreover, I would like to propose one more change: A change of the actor input "cur value" should in my opinion result in a change of the output immediately (and not waiting for triggering "add" or"sub").

This would be very useful in many of my patches, for example if you consider to start from "minimum" more than once. Maybe I did it too complicated, but I set "cur value" to "minimum"+"amount" and after that trigger "sub". After that procedure I can start with the "add" trigger to count.