Tried flocking behavior with lowpass filters. I'd like to try and do this with recursion eventually, any suggestions? Specifically is there a way to low pass a stream of numbers in the control domain?
-
Sputnik
-
Get the average. Low pass is y(n) =
n) + n-1)(actually you should also divide by two)
So, just store the last value add it to the current one, divide by two and you have the average.
For higher (smoother) averages just repeat for more past numbers, eg take the last three numbers and divide by three.
Use the Source.
-
That's what I thought, kind of a Delta Average? How would you do this, some fancy triggering and [float]s?
-
Yes,
The last value idiom to get n-1 is
[t f b]
X
[f]see attached... (the evaluation orders are tricky but this should put you on the right track)
Use the Source.
-
Okay, certainly behaves similarly to the [lop~] based example. However the visible 'lag' is much less, what in the equation is analogous to the frequency of a [lop~]?? And, can this be scaled to be done 36, 64, 128 times?
-
The frequency depends on the sample rate. Because we are in the message domain now normal filter equations don't quite make sense, but they still hold. If your input stream went 1, -1, 1, -1, 1, -1... then the output would be 0 (the average of 1 and -1). That would correspond to the filter being a single real zero filter and 1, -1, 1, -1.... to a oscillating signal at the Nyquist frequency.
So, don't think about absolute frequencies for now, think about where this "zero" falls relative to the number of input values you give. For 2 your average zero needs only two steps, for 3 it needs three steps -1, 0, 1, 0 -1, 0, 1, 0 ... , and so on.
Increasing the number of stages increases the lag, so to make the filter smoother add more past values.
Use the Source.
-
I don't think I'm getting past the basics here. You've said "Increasing the number of stages increases the lag." are We referring to the same lag? I am referring to the lag of the small circle behind the larger, or the time it takes the filtered stream to "catch up" as the larger slows. In this example, I've increased the filter to 11 stages (white circle). The red circles are sampling every other input, I don't think this is what you mean by 'sample rate.'
-
Sorry I can't folllow it Nestor, I broke GEM.
Maybe it's more helpful if you describe the desired behaviour again. If you want one object to deliberately lag behind the other (rather than averaging event values) a delay [pipe] might be more appropriate.
If it's not working then it may be that the rate of chage of data is too slow compared to the filter.
There is also an [average], might be part of Zexy, that can create large average windows (100 values or more)
Use the Source.
