problem opening max for live patches for edit

[dboles]

Hey everybody -
I created a small stand-alone application with Max that runs during my Ableton sessions and feeds global information to it (so that I don't have to adjust this in EVERY session whenever I make a global change). I've run into a problem though - whenever I have this application open, and I attempt to open a M4L patch to edit, it always gets "opened" by this Max-created application, rather than Max. This basically means that I cannot edit it at all! I've tried a number of different things, and it doesn't matter whether I have Max open, whether this other application is open but hidden, etc. The only solution I've found is to close both my app and Max/MSP and then restart, which is far from ideal. In Ableton preferences, my Max folder is set properly, and this custom application is not located there, so I'm not sure how to fix this. Any suggestions?

Thanks!

Drew

[dboles]

thank you Peter, this makes sense, and is the method that i will employ.

just out of curiosity though - i'm confused as to why the standalone app takes control of max runtime, regardless of max's presence. for example, even if i have a M4L patch open for edit in max/msp, and then open the standalone, all other M4L patches revert to the standalone. obviously, there is something with the functionality of standalone apps that makes this happen, but it seems weird to me that a standalone can "steal" max runtime from max/msp, but that max/msp cannot "steal" it back. (i also notice that if a M4L patch has opened in the standalone, but the standalone is then shut down, max/msp has to be restarted, otherwise trying to edit M4L patches just stalls.) no big deal, i'm just wondering why this would happen.

thanks for your response!

[pid]

you have to edit the "plist" file of your standalone to tell it not to do that. on osx that is. not sure what you have to edit on windows or if you can at all.

yes it is annoying. i think i would make a feature request to ableton/cycling that m4l editor knows not to do this (i.e., somehow thinks of itself differently, even though it isn't).

[dboles]

OK, that sounds promising (and, for me, preferable to keeping the standalone if possible, rather than just running a patch with Max), but can you be more specific about how I need to edit the plist file? I'm looking at it, but nothing jumps out as being an obvious solution (not much a coder here). If you can provide some further assistance, that would be great! Thanks!

Drew

[dboles]

well, i think i may have figured it out. i removed this line from the plist file:

<string>MaxMSP Runtime 5.1.9 (build 48561), Copyright 2010 Cycling '74</string>

it seems to have corrected the problem where M4L is concerned, and my standalone still seems to be functioning as intended. does this seem correct?

[pid]

hmm, i cannot remember.

i do not make standalones often and when i do i open the plist and piss around till i get it right.

i think pay attention to 'document types' (from memory) and the 'bundle'.

i think there is a jeremy bernstein comment in a post on the max forums, somewhere, if you search for it. tells it like it is.

[pid]

oh! missed you last post.

this sounds about it then!!

[pid]

no the point of plist editing is the opposite: you are telling the standalone to always use the standalone and not interfere with other max full or runtime of m4l instances or other standalones. 'only do this one job please'.

maybe i have misunderstood something in this thread though.