aps502

The attached patch shows how I am currently finding the acceleration of a body from the velocity using delta~ .

However, it seems that while velocity is constantly changing the acceleratioin plot shows the acceleration to be "pulsing". i.e. it has a non-zero value then a zero value in the next sample. This shouldn't be the case while the speed is changing. I assume it is related to sampling conditions, but I can't work out a good explanation or solve the issue.

approximating-acceleration-from-velocity

Yeah, this patch raises two issues: I don't understand EXACTLY what/how [delta~] does; the difference between signal vector size and Max control rate:

[scope~] is also perhaps not ideal in these measurement scenarios, I am reliably informed. PB or raja (or many others) might throw in a gen~ demo here (fingers crossed)

Hi
Yeah, this patch raises two issues: I don't understand EXACTLY what/how [delta~] does; the difference between signal vector size and Max control rate:

[scope~] is also perhaps not ideal in these measurement scenarios, I am reliably informed. PB or raja (or many others) might throw in a gen~ demo here (fingers crossed)
Brendan


Indeed, based on the description of delta in the documentation it should continuously produce the difference between the last two input samples, meaning unless speed is constant the output should not be 0.

I guess the issue could well be scope although I don't know what a good alternative would be, suggestions anyone?

@APS502 the pulsing is because when you move the slider with the mouse, you do not do it smooth... The mouse is polling faster than the slider value changes, so the [delta~] get some sequential same values so it outputs 0 causing the "pulsing" thing.if you put a [line~] after the slider like Brendan, it should look (it already works) fine.

this is usually how I do velocity/direction approximation in MaxMSP:

ps
this is usually how I do velocity/direction approximation in MaxMSP:

yeah, the difference between control rate and signal vector size; scope may be the culprit/weakest link

This address the issues. Thanks very much to both for your time.

I continued with this issue, I wanted direct control over the delay and scaling factor and so I implemented what i thought would be the best solution to the issue for signal processing. i.e. where the input is a signal (not a number).

[When using the patch make sure you double click LOADMESS to initialise the delay correctly]

However, if you record the output samples using CAPTURE~ it is clear that there is still a "pulsing" effect and this suggests that SCOPE~ was not the problem per se.

I used MATLAB to perform the operation on the same LINE~ input and the resulting calculated acceleration plot is attached as an image. It shows that after the initial delay has passed the acceleration is a constant 33.3 m/s^2 as expected. MAX capture is showing the results to be wrong, not only the value but also the "pulsing" effect. i.e. non-zero values followed by zero values repeatedly.

Any help or insight would be really appreciated.

[When using the patch make sure you double click LOADMESS to initialise the delay correctly] 

However, if you  record the output samples using CAPTURE~ it is clear that there is still a "pulsing" effect and this suggests that SCOPE~ was not the problem per se.

I used MATLAB to perform the operation on the same LINE~ input and the resulting calculated acceleration plot is attached as an image. It shows that after the initial delay has passed the acceleration is a constant 33.3 m/s^2 as expected. MAX capture is showing the results to be wrong, not only the value but also the "pulsing" effect. i.e. non-zero values followed by zero values repeatedly. 

Part of the problem is the DELAY~ object, i replaced it with tapin~ and tapout~ and that solves the "pulsing", but they still produce an accelration value that oscillates around the correct value, which is just as wrong. It seems like a timing issue somehow but I don't know how to address it.

Part of the problem is the DELAY~ object, i replaced it with tapin~ and tapout~ and that solves the "pulsing", but they still produce an accelration value that oscillates around the  correct value, which is just as wrong. It seems like a timing issue somehow but I don't know how to address it.

I can't describe in strictly DSP terms/equations why you are seeing this behaviour,, but I suspected that it was something to do with the conversion from scheduler/control rate to signal domains. I made one subtle change to your patch and it works as (I think) you intend:

Hi
I can't describe in strictly DSP terms/equations why you are seeing this behaviour,, but I suspected that it was something to do with the conversion from scheduler/control rate to signal domains. I made one subtle change to your patch and it works as (I think) you intend:

. . . . this thread, regarding delay~ versus tapin~/out~

https://cycling74.com/forums/tapintapout-vs-delay-am-i-imagining-this/

That worked but I have no idea why can you explain the parameters in delay and the funky patching on line?

That worked but I have no idea why can you explain the parameters in delay and the funky patching on line?
Thanks very much.


The delay values = 40ms as samples (1764 I think). The 'funky patching' on [line~] simply resets it to zero at the end of the ramp. Note that I used [line~] and not [line].

Approximating Acceleration from Velocity