Forums > Jitter

Is "setcell" messages to jit.matrix defered?

September 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:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 665 565 133 196617 graph display for debugging;
#P outlet 647 564 15 0;
#P newex 185 426 29 196617 t b f;
#P newex 283 483 27 196617 f;
#N vpatcher 614 177 875 386;
#P window setfont "Sans Serif" 9.;
#P newex 50 80 147 196617 jit.expr @expr "in[0] * in[0]";
#P newex 64 137 29 196617 sqrt;
#P newex 50 105 53 196617 jit.3m;
#P newex 50 50 63 196617 jit.op @op -;
#P inlet 50 30 15 0;
#P inlet 103 30 15 0;
#P outlet 64 159 15 0;
#P connect 2 0 3 0;
#P connect 3 0 6 0;
#P connect 6 0 4 0;
#P connect 4 1 5 0;
#P connect 5 0 0 0;
#P connect 1 0 3 1;
#P pop;
#P newobj 185 398 102 196617 p root_mean_square;
#N vpatcher 20 74 620 474;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 174 155 33 196617 t dim;
#P window linecount 0;
#P newex 174 89 51 196617 t counter;
#P newex 50 92 27 196617 i;
#P newex 50 50 27 196617 t b i;
#P newex 50 135 65 196617 maximum 1.;
#P newex 50 114 27 196617 + 1;
#P newex 67 71 40 196617 peak 0;
#P inlet 97 30 15 0;
#P inlet 50 30 15 0;
#P outlet 50 157 15 0;
#P connect 1 0 6 0;
#P connect 6 0 7 0;
#P connect 7 0 4 0;
#P connect 4 0 5 0;
#P connect 5 0 0 0;
#P connect 6 1 3 0;
#P connect 3 0 7 1;
#P connect 2 0 3 1;
#P connect 1 0 8 0;
#P connect 5 0 9 0;
#P pop;
#P newobj 557 180 54 196617 p set_dim;
#B color 13;
#P inlet 22 28 15 0;
#N comlet (float) standard deviation;
#P outlet 311 547 15 0;
#N comlet (float) mean;
#P outlet 283 567 15 0;
#N comlet (float) maximum;
#P outlet 367 507 15 0;
#N comlet (float) minimum;
#P outlet 339 527 15 0;
#N comlet (int) count;
#P outlet 395 487 15 0;
#P comment 412 488 35 196617 count;
#P comment 356 528 50 196617 minimum;
#P comment 384 508 53 196617 maximum;
#P comment 300 568 33 196617 mean;
#P comment 328 548 95 196617 standard deviation;
#P message 506 253 41 196617 dim $1;
#B color 13;
#P newex 185 293 162 196617 jit.submatrix @dim 1 @offset 0 0;
#P newex 311 334 53 196617 jit.3m;
#P message 476 91 41 196617 dim $1;
#P newex 443 90 27 196617 – 1;
#P newex 443 60 53 196617 route dim;
#P newex 341 35 112 196617 patcherargs @dim 500;
#P newex 22 65 139 196617 select clear;
#P newex 22 87 49 196617 t clear 0;
#B color 12;
#P newex 151 92 40 196617 t b f b;
#P message 185 193 87 196617 setcell $2 val $1;
#P newex 185 169 51 196617 pack 0. 0;
#N counter 0 499;
#X flags 0 0;
#P newobj 226 143 74 196617 counter 0 499;
#P newex 185 227 162 196617 jit.matrix $0_data 1 float32 500;
#P comment 201 247 137 196617 matrix functioning as buffer;
#P comment 367 336 116 196617 getting min , mean , max;
#P connect 14 0 28 0;
#P fasten 14 0 13 0 190 322 316 322;
#P fasten 14 0 31 0 190 315 652 315;
#P fasten 7 1 3 2 66 130 263 130;
#P lcolor 13;
#P fasten 7 1 27 1 66 128 606 128;
#P lcolor 13;
#P connect 3 0 4 1;
#P fasten 3 0 27 0 231 164 562 164;
#P fasten 27 0 21 0 562 455 400 455;
#P fasten 27 0 15 0 562 243 511 243;
#P lcolor 14;
#P connect 10 0 12 0;
#P connect 10 0 11 0;
#P connect 9 1 10 0;
#P fasten 13 2 23 0 344 367 372 367;
#P fasten 13 0 22 0 316 375 344 375;
#P fasten 30 1 25 0 209 453 316 453;
#P fasten 13 1 28 1 330 383 282 383;
#P fasten 13 1 29 1 330 428 305 428;
#P connect 11 0 3 4;
#P connect 29 0 24 0;
#P fasten 30 0 29 0 190 465 288 465;
#P connect 6 2 3 0;
#P connect 28 0 30 0;
#P fasten 15 0 14 0 511 280 190 280;
#P lcolor 14;
#P connect 2 0 14 0;
#P connect 5 0 2 0;
#P fasten 6 0 2 0 156 214 190 214;
#P fasten 12 0 2 0 481 217 190 217;
#P fasten 7 0 2 0 27 222 190 222;
#P lcolor 13;
#P connect 4 0 5 0;
#P connect 6 1 4 0;
#P connect 8 1 6 0;
#P connect 8 0 7 0;
#P lcolor 13;
#P connect 26 0 8 0;
#P window clipboard copycount 33;

save as jmod.stats.help:

#P user jit.pwindow 393 226 436 158 0 1 0 0 1 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 394 205 160 196617 jit.graph @mode 3 @rangehi 127.;
#P toggle 106 91 15 0;
#P newex 106 114 52 196617 metro 20;
#P message 219 99 33 196617 clear;
#P user multiSlider 226 289 141 93 0. 127. 1 3193 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 190 190 190;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P comment 66 392 50 196617 min;
#P comment 66 420 46 196617 max;
#P comment 66 406 33 196617 mean;
#P user panel 33 420 30 9;
#X brgb 74 105 182;
#X frgb 0 0 0;
#X border 0;
#X rounded 0;
#X shadow 0;
#X done;
#P user panel 33 407 30 9;
#X brgb 37 52 91;
#X frgb 0 0 0;
#X border 0;
#X rounded 0;
#X shadow 0;
#X done;
#P hidden newex 34 240 29 196617 t b f;
#P hidden message 141 243 39 196617 set $1;
#P window setfont "Sans Serif" 18.;
#P comment 12 17 155 196626 jmod.stats;
#B frgb 255 255 255;
#P window setfont "Sans Serif" 9.;
#P comment 12 44 190 196617 calculate statistics on running data;
#B frgb 255 255 255;
#P user panel 7 12 298 48;
#X brgb 67 65 107;
#X frgb 0 0 0;
#X border 0;
#X rounded 0;
#X shadow 0;
#X done;
#P user multiSlider 33 289 28 93 0. 127. 3 2937 15 0 0 2 3 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P hidden newex 72 269 61 196617 pak 0. 0. 0.;
#P user multiSlider 60 289 141 93 0. 127. 1 3193 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 190 190 190;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P toggle 35 91 15 0;
#P newex 35 114 57 196617 qmetro 20;
#P newex 35 139 65 196617 drunk 128 2;
#P flonum 88 200 47 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 35 200 47 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 194 200 47 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 141 200 47 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 247 200 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 247 223 35 196617 Count;
#P comment 141 223 50 196617 min;
#P comment 194 223 46 196617 max;
#P comment 35 223 33 196617 mean;
#P window linecount 2;
#P comment 88 223 52 196617 standard deviation;
#P window linecount 1;
#P newex 35 169 276 196617 jmod.stats.mxt @dim 100;
#P user panel 33 394 30 9;
#X brgb 0 0 0;
#X frgb 0 0 0;
#X border 0;
#X rounded 0;
#X shadow 0;
#X done;
#P hidden fasten 16 0 17 0 77 287 38 287;
#P hidden connect 10 0 22 0;
#P connect 14 0 13 0;
#P fasten 30 0 12 0 111 134 40 134;
#P connect 13 0 12 0;
#P connect 12 0 1 0;
#P fasten 29 0 1 0 224 163 40 163;
#P connect 1 0 10 0;
#P fasten 12 0 15 0 40 163 26 163 26 271 65 271;
#P hidden fasten 22 0 16 0 39 265 77 265;
#P hidden fasten 21 0 16 0 146 263 77 263;
#P connect 1 1 11 0;
#P hidden fasten 22 1 16 1 58 260 102 260;
#P connect 31 0 30 0;
#P hidden fasten 9 0 16 2 199 266 127 266;
#P connect 1 2 8 0;
#P hidden connect 8 0 21 0;
#P connect 1 3 9 0;
#P connect 8 0 28 0;
#P connect 1 4 7 0;
#P fasten 1 5 32 0 305 196 399 196;
#P connect 32 0 33 0;
#P window clipboard copycount 34;


September 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


September 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.


September 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.


Viewing 4 posts - 1 through 4 (of 4 total)