[Bug?] BPatcher load order effects coordinate system


    Feb 03 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 //
    www.vade.info abstrakt.vade.info

    • Feb 03 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 . . . . . . . . . . . .
    • Feb 03 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 //
      www.vade.info abstrakt.vade.info
    • Feb 03 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 //
      www.vade.info abstrakt.vade.info
    • Feb 03 2006 | 5:13 pm
      anyone?
      v a d e //
      www.vade.info abstrakt.vade.info
    • Feb 03 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
    • Feb 03 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 //
      www.vade.info abstrakt.vade.info
    • Feb 03 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 //
      www.vade.info abstrakt.vade.info
    • Feb 03 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