'path' message to thispatcher object in collectives/standalones


    Aug 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

    • Aug 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.
    • Aug 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. > >
    • Aug 23 2007 | 4:54 am
      Dunno, don't have 4.6.3 here yet...
    • Aug 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:
    • Aug 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
    • Aug 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 //
      www.vade.info abstrakt.vade.info
    • Aug 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:
      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 > > >
    • Aug 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.
    • Dec 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
    • Jan 09 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 >
    • Jan 09 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 >> >
    • Jan 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
    • Jan 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 > >
    • Jan 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
    • Jan 14 2008 | 10:55 pm
    • Jan 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
    • Jan 15 2008 | 9:41 am
    • Jan 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
    • Jan 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
    • Jan 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
    • Feb 05 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
    • Nov 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
    • Nov 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
    • Apr 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:
    • May 09 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
    • Aug 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?
    • Aug 17 2011 | 6:19 pm
      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.