Hi folks, I’m finding myself a bit stuck, and wondering if anyone might have an idea for an efficient way to emulate a certain physical behavior. Consider this example:

[metro 1000]
|
[random 1000]
|
[/ 1000]
|
[pack f 1000]
|
[line]

The output will be a series of random one second ramps between 0-1. This gives a rough impression of drifting/floating about the range, however the change in velocity between each ramp is instantaneous & jagged.

What I’m wondering is: how can one smooth out the transitions between ramps, and give the output a sense of inertia/momentum, while preserving the unpredictable, random motion?

I am aware of the pmpd library, which is a powerful tool for physical modeling, but I suspect there might be a computationally cheaper way to accomplish this task. (which is important for my use case)

Do I need to break out the dusty old physics calculations & calculate acceleration/velocity/etc., or is there a simpler solution that has a similar effect? Perhaps using [line] is the wrong approach, since it outputs linear ramps… I wonder if I should be polling a value for current velocity with a metro, and then curving the change in velocity towards the new random position via table lookup or some [expr] function?

Thanks in advance for any thoughts!

The easiest way to do it would be to put the the data through a low-pass filter. The lower the cut-off frequency, the smoother the curve will be. There are some drawbacks to this method of course: you'd have to do it at audio level, and you wouldn't have that much control of the curve, other than the cut-off.

@beep.beep You can emulate a capacitor (smoothing) by adding a second [line]......
cap.pd
You will need to play around with values probably.
Maybe put a multiplier after the first [line] to get some overshoot?
David.

Thank you both for the great ideas! Much simpler than what I was trying to do, so yes indeed, I had thought myself into a corner there....

I like the simplicity of the [lop~] approach, however I'm guessing the dual [line] method will work best for me in terms of efficiency (I may eventually have hundreds of these running at once). Adding a multiplier sounds like a fine idea; I think I'll also shift the random range to be centered on zero (adding a [- 0.5] after [/ 1000]), so that the multiplier will expand the output in both directions.

Again, many thanks!

Yeah, David's approach is definitely better. I didn't think of it either!