Peter Castine

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 

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.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

iCE: Sequencing, Recording & |home | chez nous|

Interface Building for |bei uns | i nostri|

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.

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.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter

loading-onecopy-extras-via-pcontrol

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

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

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


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

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 

> if alreadyOpen = 0 then alreadyOpen = 1

> if alreadyOpen = 1 then select 1 -> dispose -> thispatcher ??

However, this disposes the newly opened patcher, leaving the already- 

opened-copy somewhere behind 50 other windows. I would sort of like 

Thanks for the idea, though. It might get me further.

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

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

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.

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.

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

that should do the trick, for now.  i agree onecopy should work wherever, though. it would make some things much easier.


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 

Also: the second instantiation of the using patch flashes onscreen 

briefly before self-destructing. You can call this "cosmetic" or 

I think I'll try wrapping this logic around a "load " 

message, that should circumvent the load/flash/self-destruct cycle.

On 13-Apr-2006, at 4:37, bine~ wrote:
> well, ok then, try this...

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.

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.

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

FTR: requires _ and leftgate, both of which are easy enough to 

To be really nice, it should send a front message when the patcher is 

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.

On 13-Apr-2006, at 12:16, bine~ wrote:
> ok, this should work,

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.

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.

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 

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

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 Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

            /~~~~~
     \   /|() ()|
     ))))) )|  |  |( \
     ///     _/)/ )))))
             ___/   ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


Loading onecopy-extras via pcontrol