vade

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 

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 

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 

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 

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

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.

bug-bpatcher-load-order-effects-coordinate-system

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.

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


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 

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.

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.

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.

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.

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. 

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

at loadbang time the no offset, 0,0 is at the bpatchers 0,0 (ie 

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 

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

got it. for some reason the first time I tried your fix, it did not 

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 

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

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

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?

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

> 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

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.

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

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

[Bug?] BPatcher load order effects coordinate system