Automatic trigger in entering a scene

LPmode

the user actor input value will trigger the value it has, thus changing the init value assigned to the speed of the movie player.

you can initialize the user actor field linked with speed to 0, then add a trigger value that can be sent subsequently.

as a practice, I do not use init within a user actor if the actor is reused in multiple scenes. but rater set it on the actor field changing the value on the user actor. will not affect the other scenes.

jpjoubert

Thanks for the answer.

Don't worry about the initialization of the speed to 0\. I tried both. Inside the user actor and on the user input. But I can see the link connected to my user input coming green when I enter the scene. So I see the value I didn't sent yet going to my user input.

Reinhard

Hi,

I have my problems with this new behavior as well. Here is the 'in deep' description of that:

http://troikatronix.com/changes-to-how-actors-pass-values-in-isadora-v2-0/

I go to 'actors' in the menu bar and mark the 'Pre-2.0 Actor Processing Mode' and everything behaves as before and well known.

best

r

jpjoubert

Thanks! I wasn't able to find again this article!

But I'd like to learn the new way of working, cause it won't be the last time I'll face this issue!

Reinhard

I'm with you but I'm doing it the other way round and keep this in mind until I come to a point where I really need this. At the moment I can see no sense in a 'trigger value' or 'envelope generator' that send data when entering a scene. If I need this I use 'enter scene trigger'. Too many of my patches do not work as expected anymore with the new mode. And I'm pretty sure I'm not the only one with this problem.

So I will stick to the old one, at least till the mentioned actors have a feature like 'reset after firing' or something like that.

mark

Dear @ jpjoubert,

What you did not mention, but what is critical about your initial question, is what was the trigger input to the trigger value? I would really appreciate if you could post this scene from your patch, or an example of what went wrong, I would really appreciate it.

@Reinhard - I thought a lot about changing this behavior, because it is the way we've all been working for years. But, the fact of the matter is this: the old system had a number of problems that often required workarounds. (The User Input initializing problem being the biggest one of all - it was totally counter intuitive.) I believe the new system is the right way to go, but I also understand it is not what we are used to.

That being said, I am ready to hear from you all about what is confusing about this, and how you think it could be better. I would have to say that "it doesn't work like it used to" isn't so useful in this context. But, saying something like "this doesn't help me/causes problems in situations I encounter all the time" is most definitely something that is useful to discuss.

In addition, if there is something that people feel is a _bug_, then I most definitely want to know about it so that it can get fixed as soon as possible.

I know this transition is tricky. But I'm also listening. We will continue to actively to refine and improve 2.0\. We want everyone to love it, and part of loving it is making it easy to understand. Share your thoughts and opinions and we'll see what we can do.

Sincerely,

Mark

Reinhard

Dear @Mark,

I'm not a heavy user actor builder so far, just starting, so maybe I will encounter the problematic soon by myself. For now I would be happy with a 'trigger value' that sends data when I want and an 'envelope generator' that resets the output window to value 0.

best

r

jpjoubert

Thanks @ mark,

I'll post my patch tomorrow afternoon (GMT -5), when I'll be back at my desk.

For sure, I think that you made the good choice. I often had hard time with the ancient way of working. Just need to find how the new one is working now!

Thanks

JP

mark

@Reinhard,

Regarding this comment: "so maybe I will encounter the problematic soon by myself." -- well, the new Actor Processing mode should _prevent_ you from encountering the problem. But I can see how, for long time users, the new behavior will give unexpected results.

"a 'trigger value' that sends data when I want" -- regarding this comment, I need a further explanation of what's going wrong in your opinion. When I trigger a Trigger Value, the value at the 'value' input is most definitely sent to the 'output' output. In what situation is this actor not sending a value?

Finally, regarding "n 'envelope generator' that resets the output window to value 0" -- again, I'm not sure what you mean. The Envelope Generator will never send a value until you trigger it. Let's go through this:

1) In "Scene A" is an Envelope Generator that ramps from 0 to 100\. You trigger this, and it ramps from 0 to 100.

2) You go to "Scene B" -- do some stuff

3) You return now to "Scene A". At this point, the output of the Envelope Generator is still 100 because you have not triggered it.

Are you expecting something else?

Please respond on all points as I want to ensure that this behavior is better in all situations. Hearing from users like you really helps.

Best Wishes,

Mark

Reinhard

@Mark

I often use keyboard watcher with trigger value to trigger events within a scene on a keystroke, e.g. speeding up a pulse generator. Until now I set the initialize frequency of the generator to my desired starting frequency and speed it up by pressing 1,2,3\. Now on entering the scene the upper or more right trigger value 'overrules' my initialize setting. A workaround could be to place an extra trigger value as a 'super initializer' - but that I would call 'funky' :-)

The envelope generator is fine upon the first entering of the scene - here e.g. I use it to fade something in with the intensity control of the projector, so again I set the initialize of the projectors intensity to 0, trigger the generator and everything is fine, but when returning to that scene the initialize setting is again overruled and my movie or whatever is already there. That's not what I expect of an envelope generator that it sends 'ancient' data.

best

r

mark

Thans @Reinhard,

Your comments will help me to address the problem. Until I can deliver a solution, you may want to turn on the "Pre 2.0 Actor Processing Mode" in the Actors menu -- that will give you the old behavior.

More soon,

Mark

jpjoubert

Hi! I'm back @mark

Here's my file.

Both scene are doing the same thing.

In D, my video actor has "go input" initialize to 0 and "active input" to on.

In normal condition, I'd press the space bar and it send the 1 in "go". Second space bar will deactivate image. (I simplified the patch to see the problem)

But, when you enter the scene there's is a trigger automatically sent that put 1 in "go" and 0 in "active", bypassing the behavior I'm trying to program.

In D2, you can see the same thing on the 3 video user actor. They should be all on 0, then the space bar activate the first one and the others after a delay.

I can precise that the Go cue actor, cue 3 voies has been copied from older patch created with previous Isadora 2 version.

Many thanks for your help!

d9ead7-trigger-test-for-mark.izz