Forums > MaxMSP

moving objects with script/thispatcher:colour problem

December 28, 2006 | 5:50 pm

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;


December 28, 2006 | 6:06 pm

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


December 28, 2006 | 6:52 pm

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


December 28, 2006 | 7:23 pm

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


December 28, 2006 | 10:19 pm

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;


December 29, 2006 | 1:57 am

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


December 29, 2006 | 2:14 am

Max is a very susceptible boy!


December 29, 2006 | 2:21 am

please tell me what you mean by object name conflict!


December 29, 2006 | 2:38 am

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


December 29, 2006 | 5:03 am

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


December 29, 2006 | 5:58 am

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


December 29, 2006 | 8:02 am

how strange. thanks for the tip


December 29, 2006 | 8:40 am

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;


December 29, 2006 | 10:05 am

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


December 29, 2006 | 10:33 am

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.


December 29, 2006 | 11:13 am

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;
>


December 30, 2006 | 9:05 am

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


December 30, 2006 | 5:56 pm

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


December 30, 2006 | 11:03 pm

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


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