background image

Shared components of Max and standalone applications


Tim Place has a lengthy discussion in his blog yesterday on problems concerning the sharing of components between Max and stand-alone applications made using Max. According to him the standalone application will look for externals in the Library/Application Support/Cycling’74 folder (if it exists) prior to looking within the standalone application bundle for the externals. As a consequence of this if Max/MSP/… is upgraded at a later stage and behavior of externals change or break the standalone application breaks as well.

I’ve seen this happening between Max and Pluggo a few times but I thought that it was due to Pluggo using the old standalone format. Still I’m surprised that this is also the case with the new bundle format. I thought that one of the options of the standalone external was supposed to avoid this assuming that all externals are included with the standalone (quoting Max45ReferenceManual.pdf):

If some of the supporting files used by Max/MSP objects in your patch will not be included in the collective itself check the Search for Files Not in the Application’s Collective option.

During the beta testing stage of Max 4.500 I more or less assumed that radiaL would be broken and didn’t try it much. However once I did to my surprise I had no problems keeping it running regardless of what happened to the Cycling’74 folder.

I’ve never paid much attention to this as I have not attempted to make standalones for a long while. however this will change with the development of CloudGenerator. On a general level I fully agree with Tim that it should be possible to create a separate Application Support folder for the standalone.


comments powered by Disqus


Creative Commons License Licensed under a Creative Commons Attribution 3.0 Norway License. Web site hosted by BEK.