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.