Forums > MaxMSP

[Bug?] BPatcher load order effects coordinate system

February 3, 2006 | 1:51 am

Hello

Odd issue here – im working on a proper bug report, but im curious if
anyone has run in to this before I code up an example reproducing the
behaviour:

My patch loads at runtime a bunch of scripts that dynamically create
bpatchers. I hit a performance penalty for doing this (all driven at
once). To fix this, I strictly controlled their load order, via a
loadbang t b b b b with my different [forward loadbang_1], [forward
loadbang 2] etc etc messages. This Greatly improved my patches
startup time, however, my bpatcher started looking all weird. Ive
isolated it to when the script is run that creates to sub bpatchers.

ie: if my main bpatcher loads and runs the script at load, my
bpatchers load correctly.

if I delay the loadbang, or click the script to run manually, to load
the fx modules, I get major issues with where my bpatchers offset is
relative to its 0,0. correcting the patch to load the subbpatchers at
load time fixes this.

ie: does bpatcher do something, or work a certain way so that the
coordinate system will be different right at patchload (loadbang
time) vs after? My patch is off CONSISTENTLY by 23 pixels. Odd thing
is is that no where – NO WHERE – do I specify any offsets vertically
or horizontally in my main bpatchers. sans-loadbang a vertical offset
is introduced.

wtf. ? Anyone have any clue. Ill try and get that example out shortly.

v a d e //

http://www.vade.info
abstrakt.vade.info


February 3, 2006 | 2:05 am

move your bpatchers around in relation to the origin of the parent
patcher and see how the numbers change. we almost got this once but
I gave up. other than that I really can’t help with out an example.
. . . . . . . . . . . .
http://www.EstateSound.com
http://ideasforstuff.blogspot.com
. . . . . . . . . . . .


February 3, 2006 | 2:10 am

hi. here is the bug report patch. excuse my language – im from NYC.
yes, that is an excuse, dont question it !

for those smarter than me and more max experienced, perhaps one could
offer some better strategies wrt what I am trying to do (dynamically
load patches efficiently at runtime – so that users can add their own
fx to my main patch). I have to insert the delay in the patch
otherwise I beachball endlessly when loading my somewhat complicated
actual jitter fx patches. Ive sorted the bug down to some searchpath/
patchsize issues (esp. when jsui is involved), ie: if I lower the
amount of bpatchers in my fx patches, it loads much faster, BUT THAT
TOTALLY DESTROYS THE WHOLE CONCEPT OF MODULARITY AND CREATING OBJECTS
LIKE ANY NORMAL LANGUAGE, AND THE EXTENDED USE OF BPATCHERS AT ALL?

apologies, but this is srsly pissing me off. Cycling, please show me
the way.

v a d e //

http://www.vade.info
abstrakt.vade.info


February 3, 2006 | 2:15 am

nah, it isnt that (I dont think)… , but I am aware of that issue as
well. this is a bit more ‘subtle’ I just sent the patch off.

v a d e //

http://www.vade.info
abstrakt.vade.info


February 3, 2006 | 5:13 pm

anyone?

v a d e //

http://www.vade.info
abstrakt.vade.info


February 3, 2006 | 6:02 pm

Basically the trick here is to make a hidden comment label (or any other object) and name it something like "myOrigin". Then, after you’ve script created any bpatchers in that patch (make sure to name them!), you can position them relative to that point using the "script offsetfrom myobject myOrigin" message to thispatcher. This message is also key if you want to be able to remove, rearrange, or resize FX on the fly.

Also, instead of having a "t b b b b b", where each bang goes to a different sub/b-pacther, you may want to adjust this so that the first patch is responsible for banging the 2nd patch when you are sure it is done loading, and so on. I’ve found this is just a good habit in general for coding in Max, if possible you should only have one (1) loadbang in your entire patch. You may also want to keep this in mind when you are script creating b-patchers as well.

- Dave @ VV


February 3, 2006 | 6:31 pm

the issue is that depending on when the script is run, the origin of
the bpatcher is different.

at loadbang time the no offset, 0,0 is at the bpatchers 0,0 (ie
getinto, offsets at 0, normally)

running the script post loadbang time, changes the origin (ie the
position of the sub patch in the bpatcher says its at 0,0, but is
visibly not).

why?

v a d e //

http://www.vade.info
abstrakt.vade.info


February 3, 2006 | 8:49 pm

got it. for some reason the first time I tried your fix, it did not
work.. playing with it again it does.

thanks a lot David.

curious: is there a mechanism to know via thispatcher that a script
is finished , or do you simple say ‘message bang’ as the last script
item to some object that triggers the script in the next patcher to
be loaded?

thanks again!

I guess the lesson is that the origin is relative unless you force it
for patchers?

v a d e //

http://www.vade.info
abstrakt.vade.info


February 3, 2006 | 10:01 pm

Hey vade,

> got it. for some reason the first time I tried your fix,
> it did not work.. playing with it again it does.

>I guess the lesson is that the origin is relative unless you force it for patchers?

Glad to hear you’ve got it working. I’m not sure if it’s a lesson to be learned about the way that patchers work, but it certainly is easier to work around a fixed origin instead of having to worry about offsets at all.

> or do you simple say ‘message bang’ as the
> last script item to some object that triggers the script in the
> next patcher to be loaded?

Bingo.

As far as I know, there’s no way to know when thispatcher is done creating/moving stuff. On a local (sub/b-patcher) level, I don’t try to be totally OC about having a single loadbang path, just careful to avoid too much branching. Within the larger scale of the entire application, I try keep the loading chain as simple as possible. Typically in each patch I have a loadbang inlet connected to a single trigger for the patch. The last thing the trigger does is send a bang out an outlet for the next patcher, usually with a short delay for good measure. I don’t know if it’s even so important anymore, maybe just force of habit at this point.

- Dave @ VV


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