'path' message to thispatcher object in collectives/standalones

Aug 22, 2007 at 8:33pm

'path' message to thispatcher object in collectives/standalones

This is a tentative question before I submit something closer to an
Offical Bug Report.

is there a reason why the ‘path’ message to thispatcher doesn’t work
in collectives & standalones? bug or feature?

j

#33366
Aug 22, 2007 at 11:24pm

Now that’s interesting. A while ago I had thought it wasn’t working in a standalone and was avoiding relying on it, but lately I’ve found that it is. Maybe a version thing?

Max 4.6.1 (yeah, must update…), OS X 10.4.10, PPC.

#111062
Aug 22, 2007 at 11:34pm

it works in 4.6.1 but doesn’t work in 4.6.3?

On Aug 22, 2007, at 7:24 PM, John Pitcairn wrote:

>
> Now that’s interesting. A while ago I had thought it wasn’t working
> in a standalone and was avoiding relying on it, but lately I’ve
> found that it is. Maybe a version thing?
>
> Max 4.6.1 (yeah, must update…), OS X 10.4.10, PPC.
>
>

#111063
Aug 23, 2007 at 4:54am

Dunno, don’t have 4.6.3 here yet…

#111064
Aug 23, 2007 at 6:31pm

well it dont work here!

osx 10.4.1 (MBP)
maxmsp 4.6.3
jitter 1.6.3

and i was going to rely on it for doing some filepath stuff in a collective… cheers for flagging this one up!

j

test patch:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 55 89 48 196617 loadbang;
#P message 55 115 29 196617 path;
#P message 106 186 270 196617 “path”;
#P newex 106 157 62 196617 prepend set;
#N thispatcher;
#Q end;
#P newobj 55 133 61 196617 thispatcher;
#P connect 1 0 2 0;
#P connect 0 1 1 0;
#P connect 3 0 0 0;
#P connect 4 0 3 0;
#P window clipboard copycount 5;

#111065
Aug 23, 2007 at 7:15pm

At 4:33 PM -0400 8/22/07, joshua goldberg wrote:
>is there a reason why the ‘path’ message to thispatcher doesn’t work in collectives & standalones? bug or feature?

I don’t know if this is your problem, but the thispatcher object has to be directly in a saved patch. It can’t be in a sub-patch.

-C


Chris Muir | “There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue.” – Brian Eno

#111066
Aug 23, 2007 at 7:43pm

not the problem. I was with Josh and we found it together. Workaround
is just using a JS with the apppath etc stuff :(

On Aug 23, 2007, at 3:15 PM, Chris Muir wrote:

> At 4:33 PM -0400 8/22/07, joshua goldberg wrote:
>> is there a reason why the ‘path’ message to thispatcher doesn’t
>> work in collectives & standalones? bug or feature?
>
> I don’t know if this is your problem, but the thispatcher object
> has to be directly in a saved patch. It can’t be in a sub-patch.
>
> -C
>
> —
> Chris Muir | “There are many futures and only one status
> quo.
> cbm@well.com | This is why conservatives mostly agree,
> http://www.xfade.com | and radicals always argue.” – Brian Eno

v a d e //

http://www.vade.info
abstrakt.vade.info

#111067
Aug 24, 2007 at 5:40pm

I think this is expected behavior, no? The apppath replaces it. The
“path” of a patcher in a standalone of collective is not a really
meaningful – the path of the *application* is what you’re after. Do
a “max runtime” check and you can easily find it:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 150 226 103 196617 files in the subfolder;
#N vpatcher 763 213 1321 727;
#P window setfont “Sans Serif” 9.;
#P newex 175 275 134 196617 value subdirPath “MyHD:/”;
#P newex 35 129 58 196617 r appPath;
#P window linecount 2;
#P newex 72 155 179 196617 sprintf symout %sAPPNAME.app/Contents/MacOS/;
#P window linecount 1;
#P newex 101 278 66 196617 s subdirPath;
#P message 16 375 33 196617 count;
#P newex 90 241 207 196617 sprintf symout %ssubdirectory;
#P message 57 375 75 196617 autopopulate 1;
#P newex 71 329 104 196617 t b l;
#P newex 273 367 50 196617 t b l;
#P newex 311 432 72 196617 s filepathsSet;
#P newex 348 340 78 196617 prepend append;
#P newex 90 215 58 196617 tosymbol;
#P newex 313 393 86 196617 filepath search 0;
#P outlet 165 426 15 0;
#P newex 90 301 78 196617 prepend prefix;
#P newex 177 61 73 196617 r getMainPath;
#P newex 120 61 50 196617 deferlow;
#P newex 120 40 48 196617 loadbang;
#P newex 420 151 83 196617 s toMainPatcher;
#P newex 279 101 151 196617 sel 1 0;
#P newex 279 77 53 196617 r runtime;
#P newex 90 191 58 196617 r mainPath;
#P window linecount 2;
#P message 120 84 129 196617 ; max getruntime runtime;
#P message 279 144 129 196617 ; max sendapppath appPath;
#P window linecount 1;
#P message 420 129 50 196617 path;
#P connect 17 0 20 0;
#P connect 17 0 18 0;
#P connect 10 0 17 0;
#P connect 3 0 13 0;
#P connect 13 0 19 0;
#P fasten 23 0 19 0 40 237 95 237;
#P fasten 22 0 19 0 77 237 95 237;
#P connect 19 0 10 0;
#P connect 19 0 21 0;
#P connect 7 0 8 0;
#P fasten 9 0 2 0 182 81 125 81;
#P connect 8 0 2 0;
#P connect 17 1 11 0;
#P connect 18 0 11 0;
#P connect 20 0 11 0;
#P connect 19 0 24 0;
#P fasten 14 0 16 0 353 362 278 362;
#P connect 4 0 5 0;
#P connect 5 0 1 0;
#P fasten 16 0 15 0 278 425 316 425;
#P connect 16 1 12 0;
#P fasten 5 1 0 0 354 123 425 123;
#P connect 0 0 6 0;
#P pop 1;
#P newobj 56 223 89 196617 p DeterminePaths;
#P number 202 299 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 202 272 60 196617 route count;
#P user ubumenu 56 248 156 196617 0 1 1 0;
#X add clip49.mov;
#X types MooV;
#X prefix_set 0 1 GhostPlanetHD:/Users/evan/cvs/lowfrequency/
consulting/marcus_lydall/Singing_Keyboard/note_clips/ 0;
#X pattrmode 1;
#P window linecount 0;
#P message 60 134 498 196617;
#B color 10;
#P noclick;
#P window linecount 1;
#P hidden newex 60 81 65 196617 prepend set;
#P hidden newex 60 60 70 196617 r subdirPath;
#P hidden newex 60 158 73 196617 s getMainPath;
#P button 42 134 15 0;
#P comment 60 116 68 196617 the full path:;
#P hidden connect 3 0 4 0;
#P connect 9 0 6 0;
#P connect 6 2 7 0;
#P connect 7 0 8 0;
#P hidden connect 4 0 5 0;
#P hidden connect 1 0 2 0;
#P window clipboard copycount 11;

On Aug 23, 2007, at 8:43 PM, vade wrote:

> not the problem. I was with Josh and we found it together.
> Workaround is just using a JS with the apppath etc stuff :(
>
> On Aug 23, 2007, at 3:15 PM, Chris Muir wrote:
>
>> At 4:33 PM -0400 8/22/07, joshua goldberg wrote:
>>> is there a reason why the ‘path’ message to thispatcher doesn’t
>>> work in collectives & standalones? bug or feature?
>>
>> I don’t know if this is your problem, but the thispatcher object
>> has to be directly in a saved patch. It can’t be in a sub-patch.
>>
>> -C
>>
>> —
>> Chris Muir | “There are many futures and only one status
>> quo.
>> cbm@well.com | This is why conservatives mostly agree,
>> http://www.xfade.com | and radicals always argue.” – Brian Eno
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

#111068
Aug 26, 2007 at 11:53pm

Quote: lists@lowfrequency.or wrote on Sat, 25 August 2007 05:40
—————————————————-
> The “path” of a patcher in a standalone of collective is not a
> really meaningful – the path of the *application* is what you’re
> after.

No it isn’t. If I’m loading a patcher from disk (NOT from within the collective) as a user-selectable component of my app, I might conceivably want to know where that was loaded from so I can look for additional components there. Sure, there are other ways to get this info, but that’s no reason why path->thispatcher shouldn’t be usable.

#111069
Dec 22, 2007 at 3:31pm

John Pitcairn schrieb:
> Quote: lists@lowfrequency.or wrote on Sat, 25 August 2007 05:40
> —————————————————-
>> The “path” of a patcher in a standalone of collective is not a
>> really meaningful – the path of the *application* is what you’re
>> after.
>
> No it isn’t. If I’m loading a patcher from disk as a user-selectable
> component of my app, I might conceivably want to know where that was
> loaded from so I can look for additional components there. Sure,
> there are other ways to get this info, but that’s no reason why
> path->thispatcher shouldn’t be usable.

I know this is an old thread, but I have the same problem at the moment:
I desperately need the path to a collective. Yes the collective, because
in this case the path of the application is completely irrelevant, I am
not at all after it…
The collective might be on a different hard drive/CD or in heaven,
together with a folder. I need access to that folder…

I even consider this a bug. The application is loading the collective,
that’s why its shouldn’t be too hard to get the path out of thispatcher…

My patch works fine and finds what it is supposed to find (a folder at
the same place as the collective). The collective doesn’t work…
This is too bad. (I can’t distribute the patch as source, its too
complicated…)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#111070
Jan 9, 2008 at 8:49pm

I am also in need of this functionality. I need the path to the
collective, and cannot distribute as source.

if there is a (isruntime), can there be an iscollective in javascript?

I may not always be running in the runtime, so a

On Dec 22, 2007, at 10:31 AM, Stefan Tiedje wrote:

> John Pitcairn schrieb:
>> Quote: lists@lowfrequency.or wrote on Sat, 25 August 2007 05:40
>> —————————————————-
>>> The “path” of a patcher in a standalone of collective is not a
>>> really meaningful – the path of the *application* is what you’re
>>> after.
>> No it isn’t. If I’m loading a patcher from disk as a user-selectable
>> component of my app, I might conceivably want to know where that was
>> loaded from so I can look for additional components there. Sure,
>> there are other ways to get this info, but that’s no reason why
>> path->thispatcher shouldn’t be usable.
>
> I know this is an old thread, but I have the same problem at the
> moment:
> I desperately need the path to a collective. Yes the collective,
> because in this case the path of the application is completely
> irrelevant, I am not at all after it…
> The collective might be on a different hard drive/CD or in heaven,
> together with a folder. I need access to that folder…
>
> I even consider this a bug. The application is loading the
> collective, that’s why its shouldn’t be too hard to get the path out
> of thispatcher…
>
> My patch works fine and finds what it is supposed to find (a folder
> at the same place as the collective). The collective doesn’t work…
> This is too bad. (I can’t distribute the patch as source, its too
> complicated…)
>
> Stefan
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>

#111071
Jan 9, 2008 at 9:08pm

Oops. “path” -> [thispatcher] -> [absolutepath] works in collectives.
JB mentioned this to me off list. Thanks JB!
On Jan 9, 2008, at 3:49 PM, vade wrote:

> I am also in need of this functionality. I need the path to the
> collective, and cannot distribute as source.
>
> if there is a (isruntime), can there be an iscollective in javascript?
>
> I may not always be running in the runtime, so a
>
> On Dec 22, 2007, at 10:31 AM, Stefan Tiedje wrote:
>
>> John Pitcairn schrieb:
>>> Quote: lists@lowfrequency.or wrote on Sat, 25 August 2007 05:40
>>> —————————————————-
>>>> The “path” of a patcher in a standalone of collective is not a
>>>> really meaningful – the path of the *application* is what you’re
>>>> after.
>>> No it isn’t. If I’m loading a patcher from disk as a user-selectable
>>> component of my app, I might conceivably want to know where that was
>>> loaded from so I can look for additional components there. Sure,
>>> there are other ways to get this info, but that’s no reason why
>>> path->thispatcher shouldn’t be usable.
>>
>> I know this is an old thread, but I have the same problem at the
>> moment:
>> I desperately need the path to a collective. Yes the collective,
>> because in this case the path of the application is completely
>> irrelevant, I am not at all after it…
>> The collective might be on a different hard drive/CD or in heaven,
>> together with a folder. I need access to that folder…
>>
>> I even consider this a bug. The application is loading the
>> collective, that’s why its shouldn’t be too hard to get the path
>> out of thispatcher…
>>
>> My patch works fine and finds what it is supposed to find (a folder
>> at the same place as the collective). The collective doesn’t work…
>> This is too bad. (I can’t distribute the patch as source, its too
>> complicated…)
>>
>> Stefan
>>
>> —
>> Stefan Tiedje————x——-
>> –_____———–|————–
>> –(_|_ —-|—–|—–()——-
>> — _|_)—-|—–()————–
>> ———-()——–www.ccmix.com
>>
>

#111072
Jan 14, 2008 at 10:07pm

vade schrieb:
> Oops. “path” -> [thispatcher] -> [absolutepath] works in collectives. JB
> mentioned this to me off list. Thanks JB!

But it deliveres the wrong path, the path of the application, not the
path of the collective. I need the path of the collective!…

If I would want the path of the application, there is the max_sendappath
message to max which is sufficient for that purpose…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#111073
Jan 14, 2008 at 10:26pm

? it works for me in a collective, providing the absolute path. Unless
im smoking crack. Ill check it again when I have my wits about me.
On Jan 14, 2008, at 5:07 PM, Stefan Tiedje wrote:

> vade schrieb:
>> Oops. “path” -> [thispatcher] -> [absolutepath] works in
>> collectives. JB mentioned this to me off list. Thanks JB!
>
> But it deliveres the wrong path, the path of the application, not
> the path of the collective. I need the path of the collective!…
>
> If I would want the path of the application, there is the
> max_sendappath message to max which is sufficient for that purpose…
>
> Stefan
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>

#111074
Jan 14, 2008 at 10:27pm

On 14 janv. 08, at 23:07, Stefan Tiedje wrote:

> But it deliveres the wrong path, the path of the application, not
> the path of the collective. I need the path of the collective!…

Nope, with the following patch, saved as collective, it gives me the
path of the collective not of the Max application. At least, with Max
4.6.3 on a MacBook Pro.

ej

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 38 69 29 196617 path;
#P newex 38 170 32 196617 print;
#P newex 38 129 66 196617 absolutepath;
#N thispatcher;
#Q end;
#P newobj 38 99 61 196617 thispatcher;
#P connect 0 1 1 0;
#P connect 1 0 2 0;
#P connect 3 0 0 0;
#P window clipboard copycount 4;

#111075
Jan 14, 2008 at 10:55pm

#111076
Jan 14, 2008 at 11:17pm

#111077
Jan 15, 2008 at 12:02am

On 15 janv. 08, at 00:17, Rabin Julien wrote:

> Wow. I’m getting tired. I hope I did not get confused by writing so
> many “path” and “thispatcher” in a same post… Am I clear ?

Maybe I’m getting tired too, but I can’t reproduce that with Max
4.6.3, on PPC or Intel, with leopard.

ej

#111078
Jan 15, 2008 at 9:41am

#111079
Jan 16, 2008 at 11:18am

Emmanuel Jourdan schrieb:
> Nope, with the following patch, saved as collective, it gives me the
> path of the collective not of the Max application. At least, with Max
> 4.6.3 on a MacBook Pro.

Maybe enough for a bug report:

I had opened just before Jeremy’s helpfile to his filetype external. The
help file was not open!

Then I created the collective with the patch you just posted. I saved it
to a place within my search path.

Expected result: it would give me the absolute path to the collective.
Result (copy from the max window):

filetype :: bootsquadresearch :: jeremy@bootsquad.com
Starting Build for pathtest.mxf…
Processing script…
Copying External absolutepath
Finished script.
print: Guepys Powerbook:/Applications/MaxMSP 4.6/3rd Party Max
complete/Jeremy Bernstein/Filetype Universal Binary/

This is weird and certainly not correct.

Then I created the same collective another time out of the search path.
This time it reported the correct path.

To make the test complete, I saved the collective to an external hard
drive, and yes, there it worked too.

Beside the weird behaviour when it was within the search path, it did
work, and would work for my purpose probably…

it seems to be a bug of absolute path by the way. It just takes the last
value it had seen or something like that. This is sort of reflected in
the helpfile of absolutepath as well, it will put out a notfound if I
click on the absolutepath.help message box…

An update to the incremental pages would be nice…

I am still on a 12″ PPC Powerbook with OS X 10.4.11 and Max 4.6.3 btw…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#111080
Jan 16, 2008 at 2:12pm

On 16 janv. 08, at 12:18, Stefan Tiedje wrote:

> it seems to be a bug of absolute path by the way. It just takes the
> last value it had seen or something like that. This is sort of
> reflected in the helpfile of absolutepath as well, it will put out a
> notfound if I click on the absolutepath.help message box…

Which is a normal behavior, considering that absolutepath.help is in
the max-help folder which is not part of the search path.

Thanks, I can now reproduce. In the meantime, you just need to save
the collective out of your search path.

ej

#111081
Jan 16, 2008 at 9:28pm

Emmanuel Jourdan schrieb:
> Thanks, I can now reproduce. In the meantime, you just need to save the
> collective out of your search path.

That’s what I did, its fine for another week… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#111082
Feb 5, 2008 at 1:18pm

Reading this thread again, I don’t get why or how does ‘path’ -> thispatcher -> absolutepath work in collective. What does thispatcher output when in a collective ? I attached various [print], message boxes or [printit] to see what is going out but it doesn’t help. What is the magic ?

Best,
Julien

#111083
Nov 27, 2008 at 2:12pm

i completely forgot about this post, and i just wasted half a day trying to understand wtf was going on with thispatcher and collectives… :(

i’m still using 4.6.3 for the moment, and i’m wondering if this is still an issue with max 5 and collectives?

thanks,

justin

#111084
Nov 28, 2008 at 10:32am

#111085
Nov 28, 2008 at 11:07am

it’s not an issue (for me) anymore:

it works fine when using path > thispatcher > absolutepath in a collective, but not as a patch within max searchpath.

and path > thispatcher (without absolutepath) works fine as a patcher but not as a collective.

tbh, i just had a moment of max frustration (pun intended)!

prior to searching the forums, i searched through documentation and found nothing to suggest why this was happening. i should have searched the forums earlier…

i’m considering upgrading some fairly large patches to max 5, and just wondering if this undocumented “quirk” with thispatcher has been ironed out?

j

#111086
Apr 15, 2010 at 11:41am

i thought i’d finally seen the last of this annoying glitch. i’ve now updated to max 513 and i’m running osx snow leaopard 1063.

path > thispatcher > absolutepath does not work in a collective… it reports macintosh HD: rather than my desktop, which is where the collective is…

does anyone have any other suggestions on how to get this to work (for collectives)?

here’s the patch to build and test:

– Pasted Max Patch, click to expand. –
#111087
May 9, 2010 at 4:10pm

Hi, I’m experiencing the same problems as justin. Seems that Max 5.something has changed it’s behaviour?

Many thanks

DiGiTaLFX

#111088
Aug 17, 2011 at 5:17pm

Hi there, I’m trying to solve the same problem here… I’m building a collective, and I need the program to be able to find out where it is saved in order to save some sound files and retrieve them again.

I prefer using collective because it is cross platform, so I can just save one version and use it on windows as well as mac.

So: any news? Solutions?

#111089
Aug 17, 2011 at 6:19pm

This question was solved a few days ago.

http://cycling74.com/forums/topic.php?id=34724

May be I am wrong, the two solutions are quite different :
Mine gives you the path of the patch you open.
Seejayjames one shows you the Max5 path in standalone.

#111090

You must be logged in to reply to this topic.