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.
loopingSwitch.toe (3.9 KB)
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.
I have a solution .tox that I use that does exactly this.
I’ll reach out, shortly.
Also you could just tack
%len(me.inputs) onto whatever python expression is in the index parameter of your Switch TOP to get it to loop.
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!
Here’s a top-switcher. It might be WAY BEYOND what a simple use-case is, since it has a lot of features.
Make sure you thank the friends over at olib for this component. - it’s their design.