To address this concern, have a Speed node that multiplies fixed timers earlier in the chain with each Speed node adjusting all prior nodes' speed related parameters, timers and oscillators and combining with earlier Speed nodes. A speed of 0.5 would cancel a speed of 2.0 allowing one to adjust the speed across sections of a chain. In the example image, each of the rotations (0.1, 0.2 and 0.05) would run at half speed (0.05, 0.1 and 0.025) due to the Speed node. For additional security (and maybe efficiency), have an 'ignore' option for speed in the same way we have an ignore option for resets. For maximum flexibility it could be enabled/disabled for each time-based modifier.Eric wrote:Global BPM - yes, this is on our list. But as you describe it, some users might be upset if the BPM affected things they don't want to be affected. So there would have to be some way to indicate for every individual setting (i.e., every individual modifier) whether or not it should be affected by the BPM. This might be complicated.
One could possibly achieve this with an expression that uses a global to scale timers but this requires a global that would have to be added separately to scale each parameter/modifier, or similarly a scale modifier controlled by midi/osc. A Speed node seems easier, more powerful and more transparent way to achieve this. Used in a Post-processing node, this could go a long way to providing a Global BPM feature.