Saving Instances of a Standalone

    Sep 12 2011 | 8:30 pm
    I know that I can create a standalone in max msp that allows the user to create objects . But can the user then save the standalone to a file, so it can be reopened with the objects they created?
    Would this require building a custom max object that stores the state of a standalone? Or could this be done with Java script?
    Not sure if this is possible.

    • Sep 16 2011 | 5:05 am
      I am not sure what you mean: can the user save the standalone to file? Do you mean: can a user make a new standalone out of the standalone he is currently using? I heard that taptools has a more detailed build-app component. I am not sure if this is the right way, because this means you have to re-distribute the taptools object - and you have to pay for each license. Or do you mean: can a user save meta-data to a file? Here I suggest using the coll-object. You may get the application path from thispatcher-object or from the general max-messages (see help). Then you can read/write textfiles from/to the coll:
    • Sep 30 2011 | 5:10 am
      Thanks for the reply.
      I was not hoping to let the user build a new standalone out of a current standalone.
      I was hoping to find an easy way to let the user save the standalone to a file that they can load. In my standalone application the user will be able to create objects like buttons and boxes. I want the user to be able to save their created objects to a file, so that they will be able to load that file and have the objects they created.
      I looked into your example patcher, but it all it does is save a blank text file. I am not quite sure how to use it to save meta data as you described. ?
    • Oct 14 2011 | 6:29 pm
      Hi, you have to fill the coll with values, then save it (it'll be saved as textfile). If I understand you in the right way: you want that the user is able to create/connect max-object like in the developer version so they don't have to use the 'real' max environment? well... good luck with that. I suggest you offer a bundle of abstractions which will be loadable by the user. You may use bpatcher to load the abstractions into the bpatchers. The communications of the bpatchers have to be by send/receive busses which must have a clear name-rule. All these info you can finally save in a coll/textfile. So you need a 'project-generator' with a abstraction-selector and a intelligent management for the position of the created objects in the User-Patcher. Then the information about the loaded abstractions and their position is saved into the coll. If the user is loading his project, the project-generator will create all the object on initialization. Also useful for this abstraction-data is the pattrstorage-object, which I used once in my laptop-ensemble ( ), to save and re-create projects and their abstractions. Another way: see Timothy Place's Project 'Jamoma' Have fun!