joshua goldberg

This is a tentative question before I submit something closer to an 

is there a reason why the 'path' message to thispatcher doesn't work 

in collectives & standalones? bug or feature?

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?

path-message-to-thispatcher-object-in-collectivesstandalones

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.

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.

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


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

osx 10.4.1 (MBP)
maxmsp 4.6.3
jitter 1.6.3

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.

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

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?

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


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.

> Chris Muir | "There are many futures and only one status 

> cbm@well.com | This is why conservatives mostly agree,

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

> 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

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:

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

>> Chris Muir | "There are many futures and only one status 

>> cbm@well.com | This is why conservatives mostly agree,

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:

> 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 //
>
> www.vade.info
> abstrakt.vade.info
>
>
>


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 

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.

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.


> 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 

> 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

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 

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 

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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:

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

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

> 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 

> 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 

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

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


Oops. "path" -> [thispatcher] -> [absolutepath] works in collectives. 

JB mentioned this to me off list. Thanks JB!

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

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

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

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

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

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


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

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

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

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

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


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

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 

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

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 

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

> 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 

I had opened just before Jeremy's helpfile to his filetype external. The 

Then I created the collective with the patch you just posted. I saved it 

Expected result: it would give me the absolute path to the collective.

filetype :: bootsquadresearch :: jeremy@bootsquad.com

print: Guepys Powerbook:/Applications/MaxMSP 4.6/3rd Party Max 

complete/Jeremy Bernstein/Filetype Universal Binary/

Then I created the same collective another time out of the search path.

To make the test complete, I saved the collective to an external hard 

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

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.

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/

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

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

'path' message to thispatcher object in collectives/standalones