Loading onecopy-extras via pcontrol


    Apr 11 2006 | 2:02 pm
    Over and above the ever-popular 'help foo'->pcontrol for
    programmatically opening help file, there is also the 'load foo.mxb'
    message to open a patcher in the search path.
    I want to use this to open patchers in the patches/extras folder.
    So far, no problem. However, the all-important onecopy object is
    ignored.
    I'm trying to recall if there are any other techniques to make sure
    that a patcher is only loaded once? I can't recall/find any.
    I know we've been through this before, but I am reminded that Max'
    penchant for instantiating the same document a zillion times is, for
    this user, one of the most annoying UI idiosyncracies Max has to
    offer. A simple way to subvert this custom would be most welcome.
    Thanks,
    Peter
    -------------- http://www.bek.no/~pcastine/Litter/ -------------
    Peter Castine +--> Litter Power & Litter Bundle for Jitter
    iCE: Sequencing, Recording & |home | chez nous|
    Interface Building for |bei uns | i nostri|
    Max/MSP Extremely cool http://www.castine.de

    • Apr 12 2006 | 6:21 pm
      im guessing from the titleyou know onecopy only works via the extras menu, but hrm, i guess max doesnt know its an extra when called through thispatcher or pcontrol...
      maybe what you want is...
      ( -> is a connection )
      loadbang -> v alreadyOpen
      if alreadyOpen = 0 then alreadyOpen = 1
      if alreadyOpen = 1 then select 1 -> dispose -> thispatcher ??
      so, you know a global variable that gets a state other than default of 0 if a second or third patcher is open while the original is still intact..
    • Apr 12 2006 | 8:25 pm
      On 12-Apr-2006, at 20:21, bine~ wrote:
      > im guessing from the titleyou know onecopy only works via the
      > extras menu, but hrm, i guess max doesnt know its an extra when
      > called through thispatcher or pcontrol...
      Yeah, that's the problem.
      Basically I'd really like a onecopy object that worked for *any*
      patcher. (What I'd really like is for multiple instantiations to be
      the exception rather than the rule, but that's a battle that was lost
      decades ago)-.
      > loadbang -> v alreadyOpen
      > if alreadyOpen = 0 then alreadyOpen = 1
      > if alreadyOpen = 1 then select 1 -> dispose -> thispatcher ??
      Clever. I think.
      However, this disposes the newly opened patcher, leaving the already-
      opened-copy somewhere behind 50 other windows. I would sort of like
      to bring that copy to the front.
      Thanks for the idea, though. It might get me further.
      -- Peter
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • Apr 13 2006 | 2:36 am
      well, ok then, try this...
      the patch where the state goes from 0 to 1, IE the first one opened, could also open a gate which is closed for patches opened after IE the state is already 1. before dispose is sent to thispatcher for subsequent patches, "front" is sent to a global receive object which connects
      r globalState -> front -> gate [which is opened only for the first patcher] -> thispatcher
      that should do the trick, for now. i agree onecopy should work wherever, though. it would make some things much easier.
    • Apr 13 2006 | 6:55 am
      On 13-Apr-2006, at 4:37, bine~ wrote:
      > well, ok then, try this...
      A little different from your suggestion, but inspired by it.
      Save the attached text as an abstraction, call it OnlyOneCopy.mxb or
      something. Follow the usage instructions included in the patch. The
      effect is similar to the onecopy object inside an Extra, but works
      with any patch.
      This is a kludge. No question.
      Also: the second instantiation of the using patch flashes onscreen
      briefly before self-destructing. You can call this "cosmetic" or
      "ugly as all sin."
      I think I'll try wrapping this logic around a "load "
      message, that should circumvent the load/flash/self-destruct cycle.
      Still a kludge.
      Cheers,
      Peter
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • Apr 13 2006 | 10:16 am
      ok, this should work, a lot nicer too ;p ... save both these patches and then open _loader.pat first, but you can open the other one too as their is a safety measure to prevent an error if opened in reverse order...
      //////////////////////////////////////
      // _loader.pat
      max v2;
      //////////////////////////////////////
      // bleh.pat
      max v2;
    • Apr 13 2006 | 1:49 pm
      On 13-Apr-2006, at 12:16, bine~ wrote:
      > ok, this should work,
      Yes, stops the flashing.
      FTR: requires _ and leftgate, both of which are easy enough to
      replace if one wants to.
      To be really nice, it should send a front message when the patcher is
      already open.
      Left as an exercise.
      What would be cool is a way that only requires modifying one patch
      (either the opener or the openee) rather than modifying both. For
      ease of maintenance when Cycling '74 makes this a global option.
      I think I've figured this out, just need some time to make sure.
      Thanks for the ideas -- Peter
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • Apr 14 2006 | 8:17 am
      Peter Castine wrote:
      > I think I've figured this out, just need some time to make sure.
      Just to add some request for cycling:
      Though I do not want a general change of behaviour as Peter does, I
      would like to have some additions to patherargs which would make this
      issue much easier as well as my general concern about all of my patchers
      which incorporate some scripting for their instantiation. As I do not
      want to fire when loaded as main patcher; - the solution:
      let patcherargs output two extra messages out the right outlet:
      if its the main patcher: mainpatcher patchername
      if its a subpatcher: subpatcher patchername
      if its inside a [p]: patcher patchername_of_parent
      Should be easy to implement and its unlikely to break existing patches.
      If the latter is a concern, add a third outlet...
      With this its just easy to automate the whole issue.
      By the way, for the onepatcher suggestions (thanks for these ideas) I'd
      recommend to use wclose instead of dispose, as it would dispose it only
      if its loaded as main patcher. If you include as subpatcher into one of
      your help files and then double click to look inside, it would be thrown
      out of your help file elsewise...
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      Stefan Tiedje
      Klanggestalter
      Electronic Composition
      &
      Improvisation
      /~~~~~
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      -------------------------x----
      --_____-----------|-----------
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09