No question: This technique is really performance intensive, but it should demonstrate how easy it is to react on special settings within the document. Sure, you can do all of this with layerSets, but imagine. If you want to use a dynamic range of inputs, then you have to manipulate everything on screen dynamically. So, think about using something like this, especially when you want to react on your settings once while a special event.
This document contains a watchdog, which reacts on the current settings at the layer stack, as long as the script is active, and this may be too performance intensive to use this technique for everything on every frame…
Notice:
For a second demo, which uses the script once after the change, click here.
By the way: It’s not as performance intensive if you use a web-control-button, which toggles the audio, and starts the script once afterwards to trigger the change. Simply add it as an action to the button after the audio toggle… Then it’s some kind of post processing.
For this you’d need simply a “done” status for your script (or simply use the automatic mode which processes the script exactly once).
Hint:
If you want to use the trigger with audio which is faded in/out, please start the script with a sleep()-command. It should wait for a bit longer than the audio needs to fade in/out. While a transition, the layer status might not be exactly on or off. So, the script should wait before triggering it.
What do you think? How many buttons may be saved by this technique in a real setup? How many layerSets and click-handling is avoided during a show, especially when you have 8 dynamic inputs? Yes, the script is complex, but the result is so easy that one person can switch it while doing a one-man/-girl show.
