Is "setcell" messages to jit.matrix defered?


    Sep 27 2006 | 11:46 am
    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 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.
    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. Trond
    Save as jmod.stats.mxt:
    save as jmod.stats.help:

    • Sep 27 2006 | 4:56 pm
      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 > 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.
      -Joshua
    • Sep 27 2006 | 6:06 pm
      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.
    • Sep 27 2006 | 6:26 pm
      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 matrix for further calculations.
      Or maybe it is just as easy to make an external...
      Best, Trond
      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.