moving objects with script/thispatcher:colour problem

Dec 28, 2006 at 5:50pm

moving objects with script/thispatcher:colour problem

hello
i may have confused people with my last patch

the following example shows how moving an object “q” using script messages to a [thispatcher] object with a patch cord connected to it , seems to get redrawn in green or cyan rather than black. its quite hard to design my interfaces with this problem. how can i keep my objects the right colours?

you may find that the effect only occurs after locking and unlocking the patch once

max v2;
#N vpatcher 20 74 511 332;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 62 73 27 196617 i;
#P number 198 57 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user multiSlider 118 100 16 105 0. 127. 1 2665 47 0 0 2 0 66 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 objectname q;
#P message 198 155 108 196617 script move q $1 100;
#N thispatcher;
#Q end;
#P newobj 197 177 61 196617 thispatcher;
#P connect 4 0 2 0;
#P connect 1 0 0 0;
#P connect 3 0 1 0;
#P pop;

#29409
Dec 28, 2006 at 6:06pm

I find that the effect doesn’t occur at all. What version of Max,
what OS, etc. etc. etc. are you testing this under?

jb

Am 28.12.2006 um 17:50 schrieb bin ray:

> you may find that the effect only occurs after locking and
> unlocking the patch once

#91891
Dec 28, 2006 at 6:52pm

os x 10.4.8 max msp 4.6.2, on a 1.25ghz powerbook g4.

the effect only occurs if the patch is locked. sometimes other patch cords or objects also change colour. unlocking and then relocking the patch restores the correct colours

#91892
Dec 28, 2006 at 7:23pm

happens here too (afetr unlocking and re-locking the patch)
when clicking the slider, correct (black) colour is restored.
pb g4, 1.5 ghz, max/msp 4.5.7
?
hans w. koch
im krahnenhof 11
d-50668 koeln
+49-221-554902
http://www.hans-w-koch.net

Am 28.12.2006 um 17:50 schrieb bin ray:

>
> hello
> i may have confused people with my last patch
>
> the following example shows how moving an object “q” using script
> messages to a [thispatcher] object with a patch cord connected to
> it , seems to get redrawn in green or cyan rather than black. its
> quite hard to design my interfaces with this problem. how can i
> keep my objects the right colours?
>
> you may find that the effect only occurs after locking and
> unlocking the patch once
>
> max v2;
> #N vpatcher 20 74 511 332;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P newex 62 73 27 196617 i;
> #P number 198 57 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P user multiSlider 118 100 16 105 0. 127. 1 2665 47 0 0 2 0 66 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 objectname q;
> #P message 198 155 108 196617 script move q $1 100;
> #N thispatcher;
> #Q end;
> #P newobj 197 177 61 196617 thispatcher;
> #P connect 4 0 2 0;
> #P connect 1 0 0 0;
> #P connect 3 0 1 0;
> #P pop;
>
> –
> http://www.myspace.com/binray

#91893
Dec 28, 2006 at 10:19pm

There’s a problem in your patcher.
(conflict with object name)
Start from this one, all should work fine now:

max v2;
#N vpatcher 133 106 605 377;
#P user multiSlider 133 100 16 105 0. 127. 1 2665 47 0 0 2 0 66 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 objectname blurps;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 258 65 38 196617 + 100;
#P message 258 85 126 196617 script move blurps $1 100;
#P user multiSlider 75 100 16 105 0. 127. 1 2665 47 0 0 2 0 66 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 objectname a;
#P newex 210 85 30 196617 + 42;
#P message 210 108 108 196617 script move a $1 100;
#P user multiSlider 33 100 16 105 0. 127. 1 2665 47 0 0 2 0 66 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 objectname z;
#P flonum 75 47 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 33 47 27 196617 i;
#P number 194 30 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 194 139 108 196617 script move z $1 100;
#N thispatcher;
#Q end;
#P newobj 193 161 61 196617 thispatcher;
#P connect 3 0 5 0;
#P connect 4 0 8 0;
#P connect 9 0 0 0;
#P connect 6 0 0 0;
#P connect 1 0 0 0;
#P connect 2 0 1 0;
#P connect 2 0 7 0;
#P connect 7 0 6 0;
#P connect 2 0 10 0;
#P connect 10 0 9 0;
#P pop;

#91894
Dec 29, 2006 at 1:57am

sorry i dont understand what you mean by a conflict with the object name. your patch seems to work but i dont understand why….

#91895
Dec 29, 2006 at 2:14am

Max is a very susceptible boy!

#91896
Dec 29, 2006 at 2:21am

please tell me what you mean by object name conflict!

#91897
Dec 29, 2006 at 2:38am

:-)
I wanted you to imagine the reason of this behaviour.
Max gives a default name to each scriptable object:
Works fine until we replace the default name for a custom name.
Sometimes, [thispatcher] keeps track of both the default name and the custom name.
Tip: Once put a new object in the patcher, give it a name *before* chording script messages to [thispatcher].
It’s what I did in your example, and it works as expected.

HTH,
Philippe

#91898
Dec 29, 2006 at 5:03am

Is this possibly the reason why changing the color of a patch cord won’t actually change until you bring to front / send to back the originating object or lock, unlock the patch?

Interesting about the thispatcher remembering both names, I didn’t know that.

–CJ

#91899
Dec 29, 2006 at 5:58am

Quote: seejayjames wrote on Fri, 29 December 2006 06:03
—————————————————-
> Is this possibly the reason why changing the color of a patch
> cord won’t actually change until you bring to front / send to
> back the originating object or lock, unlock the patch?

I don’t have this problem OMM with a custom set of colors.
Have you tried to change the default colors (Options menu/Colors…)? This could resolve the prob.
Otherwise, could you send a patcher illustrating this behavior?

> Interesting about the thispatcher remembering both names,
> I didn’t know that.

It is not systematic!
It just occurs, sometimes…

Bye,
Philippe

#91900
Dec 29, 2006 at 8:02am

how strange. thanks for the tip

#91901
Dec 29, 2006 at 8:40am

Here’s an example patch showing the connectcolor scripting bug. Win XP, 4.6.2.

Really not a big deal because you can use the bringtofront message, only an extra step, but it does seem like it was meant to work without that.

I use Macs at school and it doesn’t work there either, but am interested to see if it does on any of yours.

–CJ

—————————-

max v2;
#N vpatcher 15 55 761 436;
#P window setfont “Sans Serif” 14.;
#P number 344 127 35 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
#P objectname numbox3;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P hidden message 321 254 50 9109513 1;
#P hidden newex 322 229 63 9109513 loadbang;
#P toggle 340 281 30 0;
#P newex 340 313 91 9109513 gate;
#P window setfont “Sans Serif” 14.;
#P comment 258 33 184 9109518 Windows XP , Max 4.6.2;
#P window setfont “Sans Serif” 9.;
#P window linecount 4;
#P comment 477 93 133 9109513 This one works only if the bringtofront message is let through. Also , unlocking / relocking sets the new color.;
#P window linecount 1;
#P message 416 273 205 9109513 script bringtofront numbox3;
#P newex 436 204 91 9109513 t b i;
#P button 435 135 33 1;
#P newex 436 177 91 9109513 random 15;
#P message 490 242 205 9109513 script connectcolor numbox3 0 numbox4 0 $1;
#P window setfont “Sans Serif” 14.;
#P number 344 169 35 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
#P objectname numbox4;
#P button 152 133 33 1;
#P window setfont “Sans Serif” 9.;
#P newex 153 175 91 9109513 random 15;
#P message 72 207 205 9109513 script connectcolor numbox1 0 numbox2 0 $1;
#P window setfont “Sans Serif” 14.;
#P number 49 168 35 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
#P objectname numbox2;
#P number 49 126 35 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
#P objectname numbox1;
#P window setfont “Sans Serif” 18.;
#N thispatcher;
#Q end;
#P newobj 146 304 146 9109522 thispatcher;
#P window setfont “Sans Serif” 9.;
#P window linecount 4;
#P comment 120 70 137 9109513 Banging the random *should* generate a new connection color. It only changes upon unlocking / relocking the patch.;
#P connect 2 0 3 0;
#P lcolor 5;
#P connect 5 0 4 0;
#P connect 15 0 1 0;
#P connect 8 0 1 0;
#P connect 4 0 1 0;
#P connect 6 0 5 0;
#P hidden connect 17 0 18 0;
#P hidden connect 18 0 16 0;
#P connect 16 0 15 0;
#P connect 19 0 7 0;
#P lcolor 12;
#P connect 11 0 12 0;
#P connect 12 0 15 1;
#P connect 10 0 9 0;
#P connect 9 0 11 0;
#P connect 11 1 8 0;
#P pop;

#91902
Dec 29, 2006 at 10:05am

The bug is there.
Because it works as expected using ‘bringtofront’, I think this is an old problem that came with Max 4.5 bringing the alpha blending support. The cords need to be redrawn when they lose focus, but they are not redrawn.

The problem is still not resolved with other objects too:
< http://www.open-tuning.com/Transparency-problem.zip>

Best,
Philippe

#91903
Dec 29, 2006 at 10:33am

this is not a fix but a hack: reset the slider color after every move:

[script move q $1 100, script send q frgb 0 0 0(

hth

/*j

> the following example shows how moving an object "q" using script
> messages to a [thispatcher] object with a patch cord connected to
> it , seems to get redrawn in green or cyan rather than black.

#91904
Dec 29, 2006 at 11:13am

same procedure here (i mean the bug is reproducable)
pb g4, 1.5 ghz, max/msp 4.5.7

hans w. koch
im krahnenhof 11
d-50668 koeln
+49-221-554902
http://www.hans-w-koch.net

Am 29.12.2006 um 09:40 schrieb Seejay James:

>
> Here’s an example patch showing the connectcolor scripting bug.
> Win XP, 4.6.2.
>
> Really not a big deal because you can use the bringtofront message,
> only an extra step, but it does seem like it was meant to work
> without that.
>
> I use Macs at school and it doesn’t work there either, but am
> interested to see if it does on any of yours.
>
> –CJ
>
> —————————-
>
>
> max v2;
> #N vpatcher 15 55 761 436;
> #P window setfont “Sans Serif” 14.;
> #P number 344 127 35 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
> #P objectname numbox3;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 1;
> #P hidden message 321 254 50 9109513 1;
> #P hidden newex 322 229 63 9109513 loadbang;
> #P toggle 340 281 30 0;
> #P newex 340 313 91 9109513 gate;
> #P window setfont “Sans Serif” 14.;
> #P comment 258 33 184 9109518 Windows XP , Max 4.6.2;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 4;
> #P comment 477 93 133 9109513 This one works only if the
> bringtofront message is let through. Also , unlocking / relocking
> sets the new color.;
> #P window linecount 1;
> #P message 416 273 205 9109513 script bringtofront numbox3;
> #P newex 436 204 91 9109513 t b i;
> #P button 435 135 33 1;
> #P newex 436 177 91 9109513 random 15;
> #P message 490 242 205 9109513 script connectcolor numbox3 0
> numbox4 0 $1;
> #P window setfont “Sans Serif” 14.;
> #P number 344 169 35 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
> #P objectname numbox4;
> #P button 152 133 33 1;
> #P window setfont “Sans Serif” 9.;
> #P newex 153 175 91 9109513 random 15;
> #P message 72 207 205 9109513 script connectcolor numbox1 0 numbox2
> 0 $1;
> #P window setfont “Sans Serif” 14.;
> #P number 49 168 35 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
> #P objectname numbox2;
> #P number 49 126 35 14 0 0 0 139 0 0 0 248 0 0 222 222 222 0 0 0;
> #P objectname numbox1;
> #P window setfont “Sans Serif” 18.;
> #N thispatcher;
> #Q end;
> #P newobj 146 304 146 9109522 thispatcher;
> #P window setfont “Sans Serif” 9.;
> #P window linecount 4;
> #P comment 120 70 137 9109513 Banging the random *should* generate
> a new connection color. It only changes upon unlocking / relocking
> the patch.;
> #P connect 2 0 3 0;
> #P lcolor 5;
> #P connect 5 0 4 0;
> #P connect 15 0 1 0;
> #P connect 8 0 1 0;
> #P connect 4 0 1 0;
> #P connect 6 0 5 0;
> #P hidden connect 17 0 18 0;
> #P hidden connect 18 0 16 0;
> #P connect 16 0 15 0;
> #P connect 19 0 7 0;
> #P lcolor 12;
> #P connect 11 0 12 0;
> #P connect 12 0 15 1;
> #P connect 10 0 9 0;
> #P connect 9 0 11 0;
> #P connect 11 1 8 0;
> #P pop;
>

#91905
Dec 30, 2006 at 9:05am

Jeremy Bernstein wrote:
> I find that the effect doesn’t occur at all. What version of Max, what
> OS, etc. etc. etc. are you testing this under?

It does happen with my setup as well (with both patches the object turns
green):

Max 4.6.2, OS X 10.4.8, PPC Powerbook 12″ 1.5 GHz

There seems to be a bug…

Stefan


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

#91906
Dec 30, 2006 at 5:56pm

jasch wrote:
>
> this is not a fix but a hack: reset the slider color after every move:
>
> [script move q $1 100, script send q frgb 0 0 0(

script bringtofront q does it as well…

The explanation of Philippe doesn’t explain anything and if it would be
that, it should be fixed. But that is up to those who have the source of
Max…
Anything else should remain speculation and not explanation…

Stefan


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

#91907
Dec 30, 2006 at 11:03pm

Hi Stefan,
—————————————————-
> The explanation of Philippe doesn’t explain anything and if it
> would be that, it should be fixed. But that is up to those who
> have the source of Max…
> Anything else should remain speculation and not explanation…

About scripting thispatcher, this was a deduction by some of us (and I) we did several years ago. Reason why I was able to post back the fixed patcher to his author.
About alpha blending, this was the explanation reported by David Z. himself in 2004.
And I’m still waiting for this fixing too:
< http://www.cycling74.com/forums/index.php?t=msg&goto=38813&rid=0&srch=Transparency+problem#msg_38813>

And:
<
http://www.open-tuning.com/Transparency-problem.zip>

Good night;-)
Philippe

#91908

You must be logged in to reply to this topic.