nilloc

I'm just playing around with filling matrices and something strange is happening. When I turn on a [metro] to re-fill the matrix at regular intervals it stops working. But if I click on a button (the red one in the patch copied below) to do the same thing it works fine. I've slowed the [metro] way down, tried a [qmetro]... nothing works. What am I doing wrong?

I just slowed the metro down to 1000 and let it run for a bit. Every 6 or 8 bangs, it changes what's showing in the pwindow and it seems totally random. When I manually click the button it works every time.

I'm just playing around with filling matrices and something strange is happening.  When I turn on a [metro] to re-fill the matrix at regular intervals it stops working.  But if I click on a button (the red one in the patch copied below) to do the same thing it works fine.  I've slowed the [metro] way down, tried a [qmetro]... nothing works.  What am I doing wrong?

I just slowed the metro down to 1000 and let it run for a bit.  Every 6 or 8 bangs, it changes what's showing in the pwindow and it seems totally random.  When I manually click the button it works every time.
(Max5, OSX 10.6.8, Mac Pro)


metro-not-doing-the-same-thing-as-pressing-button-at-the-same-speed

Thanks, Chris. That helps a little bit, but it still only works every 2 or 3 bangs, even with the metro at 1000ms. I can click as fast as I want on the button and it changes with every button click. I don't get why bangs coming from the metro and through the button would be any different than button clicks. ??

Thanks, Chris.  That helps a little bit, but it still only works every 2 or 3 bangs, even with the metro at 1000ms.  I can click as fast as I want on the button and it changes with every button click.  I don't get why bangs coming from the metro and through the button would be any different than button clicks.  ??


It's something to do with not liking the high priority thread, but Chris got his deferlow in the wrong place, so the left hand side was being deferred, but not the right. Probably the right hand subpatch was therefore crunching several times before the left hand bang were processed, In this case anyway, I think you also only want defer. The below works for me:

I've noticed that similar problems happen quite often, in particular also with M4L.

It would be nice to have some warning/error message in such cases.

I've noticed that similar problems happen quite often, in particular also with M4L.
It would be nice to have some warning/error message in such cases.


Thanks, Alex. Like Chris's, that helps a little, but doesn't solve the problem. It still only changes the image in the pwindow every 2 or 3 bangs. It's not like I'm on a wimpy machine (8-core, 14GB RAM) that can't handle a 100x100 matrix. I'm confused.

Thanks, Alex.  Like Chris's, that helps a little, but doesn't solve the problem.  It still only changes the image in the pwindow every 2 or 3 bangs.  It's not like I'm on a wimpy machine (8-core, 14GB RAM) that can't handle a 100x100 matrix.  I'm confused.


Hmm, it looks like jit.qball solves the problem. I still don't understand what's causing the problem, but jit.qball does the trick.

Hmm, it looks like jit.qball solves the problem.  I still don't understand what's causing the problem, but jit.qball does the trick.


All of these approaches have one thing in common: moving timer-based events to a lower priority thread.

Actually my solution works if overdrive is on (at least on my computer). It does not work if overdrive is off, but jit.qball works either way. The difference is that this will (in default mode) not queue backlogged messages of the same type, but replace them. I still don't understand quite why this seemingly simple example works this way, but apparently it does...

[metro] not doing the same thing as pressing button at the same speed