Forums > MaxMSP

bpatcher2bpatcher messages

March 23, 2007 | 11:05 am

offset message, in bpatcher, to [thispatcher] of bpatcher = works

offset message, from root, to [thispatcher] of bpatcher = works

offeset message, coming from _another bpatcher = does not work,
even when the offset message is produced in root (fopr example
by triggering a messagebox).

does not work = weird drawing problem, old stuff isnt refreshed.

whats up? bpatcher refreshes fine when offeset from root, but not
when mouse is inside another bpatcher?

-110


March 23, 2007 | 1:25 pm

I’m able to copy the behaviour you described. I’ve included the sample patch that I made below. Unexpected behaviour, since the message does seem to reach the correct bpatcher object, and it does work if you trigger the message anywhere else. Luckily I haven’t come across this before.

It’s too bad that the bpatcher object is recently (at least, to me) showing some weird behaviour, especially since it is one of the very few ways to make a more complicated interface in Max.

Let’s hope Cycling finds the time to solve these problems and possibly add to the functionality of the bpatcher object:
- A way to see only part of a subpatcher in a patch without having to use a separate file.
- An option that makes the top left corner of a bpatcher the origin (0,0) when moving objects around using thispatcher.

Other recent bpatcher problems:

http://www.cycling74.com/forums/index.php?t=msg&goto=94703&rid=5118&S=94f71fc2118610c7bb2bf6ddc7a9ce97&srch=bpatcher#msg_94703

http://www.cycling74.com/forums/index.php?t=msg&th=25207&start=0&rid=5118&S=94f71fc2118610c7bb2bf6ddc7a9ce97

Main patch:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 225 125 32 196617 print;
#P message 240 68 55 196617 offset 0 0;
#P newex 225 25 41 196617 sel 1 0;
#P message 225 51 67 196617 offset 50 50;
#P bpatcher 302 25 48 107 0 0 bpatch2 1;
#P objectname bpatcher[1];
#P bpatcher 4 25 217 177 0 0 bpatch1 1;
#P objectname bpatcher;
#P connect 3 1 4 0;
#P connect 4 0 5 0;
#P connect 2 0 0 0;
#P connect 2 0 5 0;
#P connect 3 0 2 0;
#P connect 1 0 3 0;
#P connect 4 0 0 0;
#P window clipboard copycount 6;

Save as ‘bpatch1′:

#P inlet 23 28 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#N thispatcher;
#Q end;
#P newobj 23 54 61 196617 thispatcher;
#P connect 1 0 0 0;
#P window clipboard copycount 2;

Save as ‘bpatch2′:

#P toggle 17 27 15 0;
#P outlet 17 68 15 0;
#P connect 1 0 0 0;
#P window clipboard copycount 2;



jln
March 23, 2007 | 1:47 pm


March 23, 2007 | 2:55 pm


March 25, 2007 | 8:50 am

i am not "including", but i second your request about
"unincluding".

if we had that, maybe i would finally see some sense in
"including" bpatchers? :)

btw this is mac os classic – so it seems a persistent
problem.

funny thing is, i am 100% sure now that it is realy only
a drawing (i.e. refreshing) problem – yet i solved putting
a [pipe 0] into the controlling bpatcher. (like we are used
to solve the common initialisation order problems.)

i guess its to do with the mouseclick (in an [lcd], but
it does not seem to matter), however its weird.


March 26, 2007 | 4:28 pm

Bas van der Graaff schrieb:
> I’m able to copy the behaviour you described. I’ve included the
> sample patch that I made below.

Thanks, elsewise nobody else would have jumped on it

> Unexpected behaviour, since the message does seem to reach the
> correct bpatcher object, and it does work if you trigger the message
> anywhere else. Luckily I haven’t come across this before.

I am sure you came across this before, it just looked different. Its the
same reason as all the other bpatcher problems: redraw. If you send max
a redraw command after the offset message, it will display correctly…

Stefan


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


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