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 http://www.dspaudio.com/

    • 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 http://www.dspaudio.com/
    • 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 http://www.dspaudio.com/
    • 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
      ////////////////////////////////////// // bleh.pat
    • 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 http://www.dspaudio.com/
    • 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