Understanding EffectSequence<>

ProffieOS
1

If we have a 2-way EffectSequence<>, and there’s a TrDoEffect in one of the states, is it expected behavior that it triggers anyway if it’s currently the non-active state of the EffectSequence?
I guess I thought that the code in other slots were “ignored” and not available/active. I mean if you have

EffectSequence<EFFECT_WHATEVER, Red, Blue, Green>

there’s no RGBA_um_nod compile errors about stacking solid colors, so it seems like they’re off the grid.

Anyway, if the TrDoEffect is in play like:

EffectSequence<EFFECT_USER1,
TransitionEffectL<TrDoEffect<TrInstant,EFFECT_BLAST>,EFFECT_USER2>,
AlphaL<Black,Int<0>>
>

and no USER1 has occurred, the TrDoEffect is still triggering.

So does everything inside EffectSequence remain always active and just not shown? Or is it the nature of TrDoEffect.

2

In the past, we’ve had several problems because we didn’t call run() on inactive elements. Styles like ColorCycle, InOutHelper and others gets frozen when we switch from one color to another. So, for a long time, the idea was to always call run() on everything, visible or not. There are a few exceptions to this, partially because calling run on everything is kind of expensive, and partially because I missed some places…

Anyways, with the advent of TrDoEffect, it seems like not calling run to make things not happen has become a desirable thing, and putting TrDoEffect in various places showing the somewhat inconsistent run() behavior in lots of new and interesting ways…

Now, when I added TroDoEffect, I was thinking that it would be ok if transitions have side effects, since they have running state anyways, but these side effects have rapidly spread into the color domain, and I’m not sure how I feel about that.

So… to answer your question:

  1. Yes, EffectSequence<> calls run() on all colors.
  2. should it behave like that? Good question, I’m not entirely sure.
3

Maybe a different thing that’s not Transition based, but more just a raw trigger from in the style?
Like just DoEffectF? and that can be made to not run.

4

Isn’t that exactly what you’re already doing though? What’s the difference between DoEffectF and TransitionEffectL<TrDoEffect<....>> ?

One solution that doesn’t rely on run/not run logic to work is to use TransitionPulseL, to trigger TrDoEffect, and then write an expression that contains the required logic to only happen when you want it. However, that tends to be fairly cumbersome and unintuitive.

EffectSequence isn’t a stack of layers, it works more like Mix<> or Gradient<>.

5

Oh I guess I was saying a new thing like DoEffectF could be made to not call run to make things not happen in lieu of changing something already in place.
Mostly the same thing can be achieved currently using combos like you point out above, so call it good enough for now.

Ok I see that, thanks.

6

But I don’t understand how DoEffectF could be made to not call run(). Maybe you can provide an example to show what you mean?

7

Nope.
Nevermind.