Right now, if I have a Switch TOP with several inputs, and blending enabled, and I gradually change the index from last to first, it blends between all the inputs along the way.
Imagine a Switch TOP with, say, five inputs, and when the index was changed gradually from 4 to 5, the Switch would blend nicely from the last input back to the first, without going through the three in-between inputs.
In fact, I think it would be cool if all the Switch OPs (TOP, DAT, CHOP, MAT, SOP) had the ability to clamp the index in a looping fashion, but especially the TOP because of the aforementioned blending.
I might be missing something, but it seems like this behavior is currently possible by adding the first input again at the end and driving the index with a limited chop.
I appreciate your example (and Iāve had my own solutions to making looping carousels), but it requires two major extra steps required compared to what Iām requesting:
make sure the first input is repeated, and if the inputs change, this has to be tracked, especially if the first input changes
use an extra limit chop
Hence why Iām suggesting to beef up the Switch OP itself.
Thanks everyone for the workarounds. Personally I just use extra CHOPs, as I like to keep things visual rather than in scripts. In any case, I still believe the RFE is worth considering, as it makes fast prototyping even quicker using just built-in functionality without having to ādevelopā extra bits.
I think one of the strengths of TD is that so many of its OPs are so āready-to-goā already, and some OPs are simplified versions of other OPs (eg. Over / Multiply / Add TOPs are just subsets of the Composite TOP). Two of the absolute strengths of TD for newcomers are:
Not having to use scripting (at first)
A huge catalogue of self-explanatory OPs that have narrow functionality, but robust tweaks (ie. parameters)
Some of the things that make it easy for newcomers to get into TD are the same things that make fast prototyping possible for oldcomers (lol).
I think itās an interesting idea. My first impression would be that this is something I would rather have as an option than as the default behavior.
The current behavior, where the switch OP holds the highest index value when you pass it, means that you donāt need to perform a bounds check when automating control of the index parameter. This is a behavior that is likely exploited often.
For my own uses, I suspect that if I arrived at a point where I might want to have the wraparound behavior you describe, I would already be in a position to perform the CHOP and patching workarounds from my example.
Iām not opposed to the idea at all, but itās something I would like to see implemented as a āwrap indexā toggle that Iād be free to ignore.
[rant begins here]
With regards to your point about novices and OPs with narrow functionality and robust tweaks:
I feel that TDās simple OPs that can chain together to create complexity help to nurture a āfirst principlesā mindset. Having the ability to account for edge-cases by adding toggles to OPs that widen (de-narrow) their behavior is kind of a slippery slope.
For example: Iāve had occasion to work with many āMedia Serverā products and have noticed in the evolution of most applications in that category:
they start out as a really slick thing with maybe 3 distinguishing features
over the course of a few years, they wind up with deep menus with hundreds of checkboxes that allow users from competing products to get behaviors that deviate from the originally mandated workflow
you break into a cold sweat when it comes time to set up your project and you have to go into the settings to enable all the weird behaviors you always need
To be fair, your hypothetical āwrap indexā toggle isnāt a thousand checkboxes in an aptly-named Pandoraās Box. Some alarmist shits like me might suggest itās the first step on that journey.
@ScottieFoxās .tox (which I havenāt actually looked at) seems like the most TouchDesigner-y way to do this. Which is to say that you assemble your solution once and save it to your toolchain so that you donāt have to make those extra steps.
If the objective is to help guide novices into how to approach the platform, do we potentially rob them of an opportunity to learn scripting and .tox workflows by giving them a dumb toggle that solves this problem for them?
Hi Scottie, just googling around to figure out a solution to my ugly wrap around blending with a switch top, any chance this solution still exists and you would be willing to share? Thanks!
