|
View your shopping cart.
Recent topics
Recent Comments |
SLSpeed and iterators I've been using Alessandro's wonderful SLSpeed patch which I found over on quartz compositions.com a while back to smoothly increase the speed (usually via MIDI continuous control) of objects which are moving automatically. This has worked all until I needed to use it inside an iterator. I wanted to have each iteration start at 0 when it is triggered. Think of it as LFO sync. I hit keys to trigger sprite iterations that are rotating. If they all feed off the same patch time, they rotate in sync with each other. Now I would like them to start rotating from 0 at the time they are triggered, in the case LFO sync would be off. It works fine, until I start to adjust the speed, at which point all triggered sprites jump around wildly to some new value. Any thought on how I can get the speed changes to work, or at least debug the value changes inside the iterator? Here's the Javascript from SLSpeed: /* name : SLSpeed * version : 0.1 * desc : outputs an accumulated scaled patch time * inputs : input[0] : patch time * : input[1] : speed * outputs : output[0] : old patch time * : outputs[1] : scaled patch time * auth : Alessandro Sabatelli * : 1012@acm.org * : http://www.decathexis.com */ /* inputs */ newPatchTime = inputs[0]; // this is the input patch time speed = inputs[1]; // this is the input speed multiplier /* outputs */ oldPatchTime = outputs[0]; // this is the time that was previously input newTime = outputs[1]; // this is our resulting time /* init */ if (inputs[0] == undefined) newPatchTime = 1; if (inputs[1] == undefined) speed = 1; if (outputs[0] == undefined) oldPatchTime = 1; if (outputs[1] == undefined) newTime = 0; // get the difference in time diff = newPatchTime - oldPatchTime; //if (oldPatchTime > newPatchTime) diff = 0; // set the oldPatchTime = newPatchTime outputs[0] = newPatchTime; // adjust for speed val = diff * speed; newTime += val; // accumulate //if (inputs[2] == 1) // {newTime -= val} //else // {newTime += val}; // output... have to abs b/c -time seems to break things outputs[1] = Math.abs(newTime);
More like this
|
Depending on the algorithm you use calculate a patch time, it can cause the resultant patch time to jump large amounts of time just by changing the speed co-efficient.
So take
Patch_time = speed * system_time/1000for example,Say the current system_time = 600,000ms (600seconds) and current speed is 1 resulting in Patch_time of 600s. Then in the next frame you double the speed to 2.0. So values for the next frame: system_time = 600,010ms (600.01s: not much change there) but your Patch_time = 600,010 * 2 /1000 = 1,200.02s, that's a jump of 600.01 seconds in one frame! Bound to throw out some previously smooth operations.
This is where integrating patch time becomes useful. Alessandro's code has an integration method commented out from what I can see in your post. Try using that. You basically keep adding the speed value rather than multiplying by it so as you change it the existing patchtime is only effected by the changes in speed for the time they are made, not back thru time. I hope that helps you to understand it, may have been more confusing for you.
This is a common issue when you start playing with patch time and I think it's what's your 'bug' is. Hard to say without a composition. See if you can cut a simplified example out of your comp and post it.
Well, the thing that is curious is that outside an iterator, the change in speed works as expected. Inside an iterator, if I simply feed off of patch time, it also changes smoothly. However, once I switch from patch time to patch time minus a sample & hold snapshot of the time the key was hit (my LFO sync switch if you will), then I see the jump in rotation values.
I think the math in the JS patch is fine, the commented out code is mine and was just for handling rotational direction. I suspect something about the way the iterator + patch time vs. patch time minus sample & hold may be altering things in ways I don't expect.
I've attached 2 samples with and without the iterator the demonstrate the issue. In the iterated example you can turn the LFO sync from 0 to 1 to repro the issue. I should note I am adjusting the speed via MIDI continuous controller, and applying some match the the MIDI CC value (divide by 12.7 to keep the value to n more than x10). The change in value of speed even with the subtlest of changes (1 or 2 MIDI points/12.7) is still very dramatic.
The patches require Kineme MIDI tools.
Thanks for any insight!