Roman Thilenius

a question, hopefully one with a short answer.

i use max 4 in OS9 an OSX 10.4 and will continue to do so for a while. today i checked out if my externals, programs, and bpatchers would work in the max 5 (runtime).

several small issues appeared today with bpatchers, which made me worry a bit, because i have several bigger projects each based on hundres of bpatchers. the problems are mostly releated to the interface.

- ubutton flashes in max5 when it has been flagged to dont flash in max4.

- many graphics objects such as numberboxes seem to be shifted for about 1v1h pixels.

- the most strange thing is that the bpatcher object boxes themselves appear to be one pixel smller than in max4.

has anybody already found a simple way of automatically correcting these things in his patches? i am mainly looking for a solution which would work in max 4.1 - 4.6 (as i dont have 5 yet), for example textprocessing of max text files with bbedit (or max itself, i have done such thing before.)

it is probably unnecessary to complain about the fact that [umenu] is bigger in max5, but it is bigger in max5, and little 110 does not like that!

 - ubutton flashes in max5 when it has been flagged to dont flash in max4.
 - many graphics objects such as numberboxes seem to be shifted for about 1v1h pixels.
 - the most strange thing is that the bpatcher object boxes themselves appear to be one pixel smller than in max4.

solving-max4-max5

max4´s "window flags float" correctly creates a regular 

palette style window which is 1. floating and 2. has the 

in max runtime 5 such a window opens as nonfloating window

without any borders (aka WIND resource Proc ID #2) with the

furthermore, such a window can not even be closed using command-W.

max4´s "window flags float" correctly creates a regular 
palette style window which is 1. floating and 2. has the 
thinner border in max 3 through 4.6.

in max runtime 5 such a window opens as nonfloating window
without any borders (aka WIND resource Proc ID #2) with the
result that you cannot move it.

furthermore, such a window can not even be closed using command-W.
!?

Roman Thilenius wrote on Fri, 27 March 2009 21:27

okay, so i am talking to myself here, no problem.

the problem has already shrunk as of today.

the positioning and "bpatcher size" issue described above in fact have been nothing more than this pheanomen when you sit in a train and the train on the other side starts moving.

what went wrong is - luckily - only releated to [fpic] positioning: in maxmsp 3 through 4.6.3. [fpic] has an offset of -1 -1 when it hits the border of the patcher window, in the latest max 5 runtime it is 0 0:

in other words, it is not a strange behavior of max 5, it is a strange behaviour of older versions.

as i have four to five bigger projects with each more than 150 bpatchers (+usually with background pictures) this is still an issue, but it seems possible to solve this easily now that obviouly only one line of text has to be changed.

or has anybody made eventually already a little fix for me? (a bbedit script?)

or is it eventually actually a max 5 bug that it does no longer support the strange behavior of max 4´s [fpic] object?

p.s. the ubutton flash flag issue is still present.

Roman Thilenius wrote on Fri, 27 March 2009 21:27
a question, hopefully one with a short answer.

p.s. the ubutton flash flag issue is still present.


solving max4 -> max5