[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