Forums > MaxMSP

pattrhub does deferlow?

October 8, 2006 | 5:22 pm

Hi, I wondered if this behaviour was intentional. The pattrhub seems to defer its output to the end of the queue.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 55 103 34 9109513 print 1;
#P newex 72 149 34 9109513 print 2;
#P message 40 79 50 9109513 getanswer;
#P newex 40 126 42 9109513 pattrhub;
#P newex 110 36 61 9109513 loadmess 42;
#P newex 110 58 59 9109513 pattr answer;
#X prestore 1 0 42;
#P objectname answer;
#P button 40 39 15 0;
#P newex 40 58 40 9109513 uzi 4;
#P connect 5 0 4 0;
#P connect 5 0 7 0;
#P connect 3 0 2 0;
#P connect 4 1 6 0;
#P connect 0 0 5 0;
#P connect 1 0 0 0;
#P window clipboard copycount 8;

Cheers,
Mattijs


October 9, 2006 | 7:47 am

Mattijs Kneppers wrote:
> Hi, I wondered if this behaviour was intentional. The pattrhub seems
> to defer its output to the end of the queue.

I can’t reproduce. And as your patch doesn’t test it, I moved the print
1 to the left, and it will fire after the print 2.
Not deferred on my machine…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


October 9, 2006 | 8:55 am

I believe he do test it, and it seems to be defered here on Mac OSX
10.4.7, Max 4.5.7. All 4 "print 1" are printed before any of the "print
2". If it was not defered, print 1 and 2 should be merged. This is what
I get in the Max window:

1: getanswer
1: getanswer
1: getanswer
1: getanswer
2: answer 42
2: answer 42
2: answer 42
2: answer 42


October 9, 2006 | 9:11 am

Max 4.6.2, OSX 10.4.8:
Max 4.5.7 with incremental pattrhub update

1: getanswer
2: answer 42
1: getanswer
2: answer 42
1: getanswer
2: answer 42
1: getanswer
2: answer 42

I see that on the 18th of March, I "fixed a defer_low bug in anything
method", according to my notes, which involved removing the
unnecessary defer from the code. Are you guys running the pattrhub
from the incremental updates page? Because that version should have
the correct code in it, and works properly on my 4.5.7 install.

jb

Am 09.10.2006 um 10:55 schrieb Trond Lossius:

> I believe he do test it, and it seems to be defered here on Mac OSX
> 10.4.7, Max 4.5.7. All 4 "print 1" are printed before any of the
> "print 2". If it was not defered, print 1 and 2 should be merged.
> This is what I get in the Max window:
>
> 1: getanswer
> 1: getanswer
> 1: getanswer
> 1: getanswer
> 2: answer 42
> 2: answer 42
> 2: answer 42
> 2: answer 42


October 9, 2006 | 10:04 am

Ah, I should have included version info and my output. Sorry for that. I use Max 4.5.7, without the incremental pattrhub update. I got the same output as Trond. Good to know it has been fixed!

Mattijs


October 9, 2006 | 5:22 pm

I do now…

%-)

Upgrading to the incremental pattrhub solved the problem. Thanks for the
new layout of the incremental page, it makes it a lot easier to know
what updates do exist.

Trond

Jeremy Bernstein wrote:
> Max 4.6.2, OSX 10.4.8:
> Max 4.5.7 with incremental pattrhub update
>
> 1: getanswer
> 2: answer 42
> 1: getanswer
> 2: answer 42
> 1: getanswer
> 2: answer 42
> 1: getanswer
> 2: answer 42
>
> I see that on the 18th of March, I "fixed a defer_low bug in anything
> method", according to my notes, which involved removing the
> unnecessary defer from the code. Are you guys running the pattrhub
> from the incremental updates page? Because that version should have
> the correct code in it, and works properly on my 4.5.7 install.
>
> jb
>
> Am 09.10.2006 um 10:55 schrieb Trond Lossius:
>
>> I believe he do test it, and it seems to be defered here on Mac OSX
>> 10.4.7, Max 4.5.7. All 4 "print 1" are printed before any of the
>> "print 2". If it was not defered, print 1 and 2 should be merged.
>> This is what I get in the Max window:
>>
>> 1: getanswer
>> 1: getanswer
>> 1: getanswer
>> 1: getanswer
>> 2: answer 42
>> 2: answer 42
>> 2: answer 42
>> 2: answer 42
>
>
>


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