Forums > MaxMSP

Loading onecopy-extras via pcontrol

April 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/


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


April 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/


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


April 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

#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P comment 11 220 461 196617 Written by Peter Castine , based on
ideas by bine~. Feel free to adapt to suit your needs. Credit where
credit is due.;
#P window linecount 3;
#P comment 11 180 461 196617 Usage: this abstraction requires one
symbol argument , which must be unique to the using patcher. Per
convention this argument is the same as the patcher filename. The
outlet from this abstraction must be connected to a thispatcher
object in the top-level patch.;
#P comment 268 112 206 196617 Send the front message to all
instantiations of the object. The dispose message only goes to this
particular instantiation.;
#P window linecount 1;
#P newex 78 133 187 196617 r $1.front;
#P newex 12 44 46 196617 t 1 bang;
#P outlet 12 159 15 0;
#P newex 78 113 187 196617 s $1.front;
#P newex 12 91 76 196617 t dispose front;
#P newex 12 23 48 196617 loadbang;
#P newex 12 70 180 196617 value $1;
#P window linecount 3;
#P comment 64 24 410 196617 If this is the first instantiation of the
mother patcher , the value object is empty and does nothing when
receiving a bang. After the first instantiation , the value object
contains the value one , which is sent through the outlet on
receiving a bang.;
#P connect 2 0 6 0;
#P connect 6 0 1 0;
#P fasten 6 1 1 0 53 65 17 65;
#P connect 1 0 3 0;
#P fasten 7 0 5 0 83 154 17 154;
#P connect 3 0 5 0;
#P connect 3 1 4 0;
#P window clipboard copycount 11;

————– 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/


April 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;
#N vpatcher 630 55 984 400;
#P window setfont "Sans Serif" 12.;
#P newex 202 280 85 9109516 s safety_bang;
#P newex 202 255 60 9109516 loadbang;
#P hidden newex 202 306 121 9109516 bgcolor 220 220 220;
#P newex 86 239 42 9109516 _ load;
#P newex 86 263 52 9109516 pcontrol;
#P newex 156 124 46 9109516 _ store;
#P newex 48 214 48 9109516 leftgate;
#P newex 48 102 48 9109516 t l l 1;
#P newex 156 100 70 9109516 r one_state;
#N coll one_copy_state 1;
#P newobj 156 174 127 9109516 coll one_copy_state 1;
#P message 48 48 52 9109516 bleh.pat;
#P comment 103 205 52 9109516 override;
#P comment 105 49 74 9109516 < ---- loadz0r;
#P connect 2 0 5 0;
#P connect 5 0 6 0;
#P connect 5 2 6 1;
#P fasten 3 0 6 1 161 205 91 205;
#P connect 6 1 9 0;
#P connect 9 0 8 0;
#P connect 4 0 7 0;
#P connect 5 1 3 0;
#P connect 7 0 3 0;
#P connect 11 0 12 0;
#P pop;

//////////////////////////////////////
// bleh.pat

max v2;
#N vpatcher 20 56 620 266;
#P window setfont "Sans Serif" 12.;
#P window linecount 1;
#P newex 185 42 82 9109516 r safety_bang;
#P newex 377 104 73 9109516 s one_state;
#P message 377 81 62 9109516 bleh.pat 1;
#P newex 377 56 66 9109516 closebang;
#P newex 105 104 73 9109516 s one_state;
#P message 105 81 62 9109516 bleh.pat 0;
#P newex 105 56 60 9109516 loadbang;
#P comment 251 81 43 9109516 BLEH!;
#P comment 105 130 133 9109516 close further instances;
#P comment 375 130 97 9109516 reopen on close;
#P fasten 9 0 4 0 190 80 110 80;
#P connect 3 0 4 0;
#P connect 4 0 5 0;
#P connect 6 0 7 0;
#P connect 7 0 8 0;
#P pop;


April 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/


April 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


Viewing 8 posts - 1 through 8 (of 8 total)