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.
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:
Yes, EffectSequence<> calls run() on all colors.
should it behave like that? Good question, I’m not entirely sure.
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<>.
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.