XML Feeds

.

[maxmsp] 'path' message to thispatcher object in collectives/standalones

evan.raskob [lists] lists at lowfrequency.org
Fri Aug 24 11:40:21 MDT 2007


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 at well.com         |  This is why conservatives mostly agree,
>> http://www.xfade.com |  and radicals always argue." - Brian Eno
>> _______________________________________________
>> maxmsp mailing list
>> maxmsp at cycling74.com
>> http://www.cycling74.com/mailman/listinfo/maxmsp
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>
> _______________________________________________
> maxmsp mailing list
> maxmsp at cycling74.com
> http://www.cycling74.com/mailman/listinfo/maxmsp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cycling74.com/pipermail/maxmsp/attachments/20070824/10a34f9f/attachment.htm


More information about the maxmsp mailing list