Forums > MaxMSP

'path' message to thispatcher object in collectives/standalones

August 22, 2007 | 8:33 pm

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


August 22, 2007 | 11:24 pm

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.


August 22, 2007 | 11:34 pm

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


August 23, 2007 | 4:54 am

Dunno, don’t have 4.6.3 here yet…


August 23, 2007 | 6:31 pm

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;


August 23, 2007 | 7:15 pm

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


August 23, 2007 | 7:43 pm

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


August 24, 2007 | 5:40 pm

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


August 26, 2007 | 11:53 pm

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.


December 22, 2007 | 3:31 pm

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


January 9, 2008 | 8:49 pm

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
>


January 9, 2008 | 9:08 pm

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


January 14, 2008 | 10:07 pm

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


January 14, 2008 | 10:26 pm

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


January 14, 2008 | 10:27 pm

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;



jln
January 14, 2008 | 10:55 pm



jln
January 14, 2008 | 11:17 pm


January 15, 2008 | 12:02 am

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



jln
January 15, 2008 | 9:41 am


January 16, 2008 | 11:18 am

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


January 16, 2008 | 2:12 pm

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


January 16, 2008 | 9:28 pm

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



jln
February 5, 2008 | 1:18 pm

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


November 27, 2008 | 2:12 pm

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


November 28, 2008 | 10:32 am


November 28, 2008 | 11:07 am

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


April 15, 2010 | 11:41 am

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

May 9, 2010 | 4:10 pm

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

Many thanks

DiGiTaLFX


August 17, 2011 | 5:17 pm

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?


August 17, 2011 | 6:19 pm

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.


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