User Actors, Scaling and Limits: Opinions Please.

mark

Hello All,

I am seeking some feedback regarding how User Actors work with regard to the scaling and limits of the User Inputs and Outputs.

I've spent the last several days tackling some bugs and inconsistencies in this area, and things are behaving a quite a bit better. But one thing I've head from a number of users is, "don't mess around with the 'scale min/max' and 'limit min/max' settings I've made on the individual User Actors." (Previously, when you edited a User Actor and choose "Save and Update All," Isadora would copy these values from the master User Actor you just saved to all the other User Actors.) But, in attempting to implement this suggestion, I see that there's all kinds of confusion that could arise, especially for users less familiar with User Actors.

The basic dilemma is this: how to offer power users the most flexibility, but not to confuse those new to User Actors.

If you are interested to offer your insight and opinions, I would direct you to a new "primer" I wrote. This document is based on the **new** functionality, not the existing functionality. You can find the document at [http://troikatronix.com/user-actor-scaling-primer/](http://troikatronix.com/user-actor-scaling-primer/) To enter into the discussion below, you really need to read this document and you must also have a strong understanding of the scaling/limiting features of Isadora.

As I wrote this document, I started to realize that what really is needed is some options for how the 'scale min/scale' max and 'limit min/max' are handled. I am envisioning the following:

1) Mode A (Novice Mode?): when choosing "Save and Update All" do the following:

for each User Input, copy the 'absolute min/max' to the 'limit min/max' setting
for each User Output, copy the 'absolute min/max' to the 'scale min/max' setting

then, when updating the all of the copies of the User Actor

copy the 'limit min/max' from User Inputs to both the 'absolute min/max' and the 'scale min/max' of the published User Actor outputs
copy the 'scale min/max' from User Outputs to both the 'absolute min/max' and the 'limit min/max' of the published User Actor outputs.

This keeps things as simple as possible when looking at the actor from the outside, and prevents unexpected values for 'limit min/max' on the User Inputs and 'scale min/max' on the User Outputs.

2) Mode A (Advanced Mode?): when choosing "Save and Update All" do the following:

copy the 'absolute min/max' and the 'limit min/max' from User Inputs to the 'absolute min/max' and the 'scale min/max' of the published User Actor outputs, respectively.
copy the 'absolute min/max' and the 'scale min/max' from User Outputs to the 'absolute min/max' and the 'limit min/max' of the published User Actor outputs, respectively.

In this mode, custom settings of 'scale min/max' and 'limit min/max' on copies of the User Actor will be lost. But, after choosing "Save and Update All," for every copy of the User Actor, all published inputs and outputs will be consistent with what is _inside_ the master User Actor that was just edited.

3) Mode C (Power User Mode?)

Do what is described in the "primer" mentioned above. This offers the most flexibility and customization, but also requires the user to pay attention for possible undesired values for 'scale min/max' and 'limit min/max' – both internally in the User Inputs and Outputs and externally on the published inputs and outputs of the User Actor.

So, first, I'd like your reaction to these various modes. I mean, in the end, it's a bit hard for me to know because my brain is totally geektastically organized, and Mode C seems good to me. But I understand that, for a great many users, such an option is going to be confusing.

If these multiple modes of working seem like a good idea, then the question becomes, how does one offer the user the option to decide how to update them. The "save" box for the User Actors is already a bit messy with options. I don't really want to add more. (I'm considering removing some of these... e.g., "New Instance" and/or "Convert to Macro" – these commands could be put in the Actors menu.)

A second dialog, with a "don't show again" checkbox could be another way to let people choose between Mode A, B or C If they choose "don't show again," Isadora will from that point forward use the option they chose, unless they can select a different mode in the Actors menu.

So, that's my pitch. I welcome your thoughts and insights so that I can make this part of the program better for everyone.

Best WIshes,

Mark

P.S. Many thanks to gavspan who got me going on this topic. He reviewed the primer and tried out some of the features proposed, and then spent some hours providing me with invaluable feedback. Much appreciated!

gavspav

Hey that is too confusing - we are the ADD generation you know.

Give me one sentence so I can choose whether to like it or not on facebook!

Its quite a difficult thing to get ones head around partly because of the terms.

But can you explain the advantage of having absolute min/max and scale min/max with user actors.

Can any flexibility not be achieved with the addition of a scale value actor?

One problem I've had with User Actors is that I quite often wanted to have different variables within them and I found it difficult having to pipe all these in from outside.

Other than that I think a global actor should probably be identical in all cases and scale differences should be handled by additional actors.

But like I said it's confusing......

MatthewH

To offer a counterpoint to gavspav, I would be very sad to see this option go. While its true that the most crucial functionality could be replaced with limit scale actors, I would rather avoid having to put all those additional actors in my user actor since that sort of kludges up what is going on and my patching style is muddled enough as it is.

Mark, I suppose I would probably qualify as a power user so on some level I'm not the best person to comment but I haven't really been unhappy with the current system ninety nine times out of a hundred and I would probably settle right into using mode C. That said, additional modes probably wouldn't hurt. My one concern would be what happens if I distribute an actor built in mode C and a less experienced user accidentally switches it to a different mode while editing it or checking out its internals. I foresee an increase in emails about my actors not behaving as expected.

LPmode

I like things to be consistent and predictable. and the primer makes sense on how things work. inputs and outputs are separate things. I would not want settings to update on their own.

On a slightly different note, I like to have the options that affect things as visible as possible and would even ask for a graphical feedback that show me which inputs/outputs are customized (There could be an easier way to set min.max). I use the scale/limit actor because I prefer to see things (that is true for preferring Isadora's programming approach as well). So I hope that the changes are consistent with that.

gavspav

Well now I understand what is going, on mode C seems fine!

Michel

I would prefer mode c. I wouldn't like the possibility to change the mode, that would be much to confusing. Also when explaining it to someone else you have to go through all modes first, before you can start with your help.

Best,
Michel

mark

Thank you all for your thoughts. But with regard to Matt H's question:

"what happens if I distribute an actor built in mode C and a less experienced user accidentally switches it to a different mode while editing it or checking out its internals. I foresee an increase in emails about my actors not behaving as expected."

This is not a problem unless the user chooses "Save and Update All," and if they're doing that with someone else's User Actor (especially one as generlized as yours) then they will simply need to accept what happens.

On the other hand, one could "bulletproof" the User Actor inputs and outputs by setting specific Absolute Min/Max (i.e., to something like -100 and +100) so that no other customizations on the outputs would be needed.

Best Wishes,

M