I'm attempting to build an abstraction calculating running statistic
values on a flow of floats, in a somewhat similar way to lp.stacey. I am
using a jit.matrix as a circular buffer. However I notice that the
setcell message that is used to feed a new value to the buffer doesn't
always seem to update the matrix fast enough for the new value to become
part of the subsequent calculation. The problem only seems to happen if
the incoming floats arrives from the timed scheduler.
Is the setcell message defered inside jit.matrix? If so, is there any
way to push it to not defer it?
Steps to Reproduce:
1) Save the two patches below in the same folder as jmod.stats.mxt and
2) Open jmod.stats.help
3) Start metro and observe the jitter graph displayed, in particular for
the time before the buffer is all filled up.
I sometimes see that the end of the buffer contains zero values,
something it shouldn't unless drunk is going all the way down. You can
use the clear message to start over again.
4) Now stop metro and start qmetro instead. Using qmetro the patch no
longer display any problems.
Expected and actual results:
The trigger object inside jmod.stats.mxt is supposed to ensure that the
new cell value is set before the matrix is banged and calculations
performed. However it seems to happen every now and the that the new
cell value has not been set before the matrix is banged. Thus if the
counter has nit yet wrapper round, the last cell will contain 0. instead
of the value it is supposed to have. The only possible explanation I can
imagine is that setcell is defered inside jit.matrix, and thus might be
performed after the matrix has been banged.
The fact that the problem only seems to happen if triggered using metro
instead of qmetro seems to support this theory.
Probably this is a feature of the jit.matrix behaviour and not a bug, so
my question is primarily if there's a way I can avoid the problem
without having to defer the input to the jmod.stats abstraction. I want
to use this abstraction for e.g. processing of incoming midi/sensor
data, so it is important to me to be able to keep stats calculations
part of the scheduler it receives input from.
I've been testing this on PPC, Max 4.5.7. Overdrive on/off and scheduler
in audio interrupt doesn't seem to have any implications for the behavior.
Thanks for any insight.
Save as jmod.stats.mxt: