'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
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.
>
>
Dunno, don't have 4.6.3 here yet...
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:
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
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
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:
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 //
>
> 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
> 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.
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
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!
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
>>
>
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
? 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:
> 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
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
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
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
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
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
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
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
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:
Hi, I'm experiencing the same problems as justin. Seems that Max 5.something has changed it's behaviour?
Many thanks
DiGiTaLFX
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?
This question was solved a few days ago.
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.