Trond Lossius

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 

1) Save the two patches below in the same folder as jmod.stats.mxt and 

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 

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.

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?

1) Save the two patches below in the same folder as jmod.stats.mxt and 
jmod.stats.help respectively.
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.

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.

is-setcell-messages-to-jit-matrix-defered

On Sep 27, 2006, at 4:46 AM, Trond Lossius wrote:

> 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 

> Is the setcell message defered inside jit.matrix? If so, is there 

Yes. All methods for jit.matrix are deferred or usurped when called 

from a patcher. You can either use jit.qfaker or call the methods 

from C or Java to avoid this behavior, but you better know what 

you're doing if you're using this stuff in the scheduler thread. It's 

not recommended usage unless you're savvy enough to do so.

> 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?

Yes. All methods for jit.matrix are deferred or usurped when called  
from a patcher. You can either use jit.qfaker or call the methods  
from C or Java to avoid this behavior, but you better know what  
you're doing if you're using this stuff in the scheduler thread. It's  
not recommended usage unless you're savvy enough to do so.

My preferred workaround for this sort of thing is to convert the float 

to a signal and use jit.poke~ to write values into the matrix.

My preferred workaround for this sort of thing is to convert the float 
to a signal and use jit.poke~ to write values into the matrix.

Thanks for the replies, Joshua and Andrew.

I was thinking of this as a workaround, but there will be a bit of 

overhead involved. Another possibility will be to use an audio buffer as 

buffer, write into it with peek~, and then use jit.buffer~ to get the 

Or maybe it is just as easy to make an external...

> My preferred workaround for this sort of thing is to convert the float 

> to a signal and use jit.poke~ to write values into the matrix.

I was thinking of this as a workaround, but there will be a bit of 
overhead involved. Another possibility will be to use an audio buffer as 
buffer, write into it with peek~, and then use jit.buffer~ to get the 
matrix for further calculations.

Andrew Benson wrote:
> My preferred workaround for this sort of thing is to convert the float 
> to a signal and use jit.poke~ to write values into the matrix.
>
>
> Cheers,
> Andrew B. 


Is "setcell" messages to jit.matrix defered?