cellbock behavior


    Oct 27 2010 | 9:29 am
    Is it expected behavior that cellblock displays incoming matrix to jit.matrix even when not passed through?

    • Oct 27 2010 | 9:55 am
      I can copy, this looks like a good find. Intuitively, the matrix should not show in the cellblock, of course. Jit.submatrix (the semi-hack object) does not work on it either, nor does other stuff. Cycling's under the hood technology!
    • Oct 27 2010 | 10:10 am
      Oh btw, if this annoys you, you can send 'deref' to the jit.cellblock to cause it to lose it's connection to the matrix internally (Timo Rozendal just pointed that out to me).
    • Oct 27 2010 | 4:01 pm
      Yes, I was aware of deref - but I was using cellblock for debugging, so not very convenient with such a workaround… I guess we'll just have to see what may happen to future versions of cellblock.
    • Oct 27 2010 | 4:53 pm
      I can understand why this might be a hassle, but what is happening is that once cellblock gets a jit_matrix message, it is then relying on that matrix to maintain it's data structure, regardless of the "physical" connection of a patch cord. jit_deref or deref will indeed remove this connection.
      Maybe there is some other attribute we could have to have it not output if it doesn't receive a jit_matrix message again or something, but the intention for cellblock being used in conjunction with jitter matricies is for this reference connection to be made regardless of a patch cord.
      -Ben
    • Oct 28 2010 | 3:59 am
      I see what you're saying, Ben. Could be convenient to have an attribute that could invoke the expected max behavior as well, as it is very useful to have.
      Thanks again for all your efforts,
      Lars
    • Oct 28 2010 | 4:25 am
      Lars,
      'refer'-ring to a coll will override the jit_matrix reference, or you can do something like this with 'jit_deref' or 'deref':
      A bit too much overhead though for common usage. I'll put in a feature request in for something like this.
      -Ben