Saving Instances of a Standalone

    Sep 12 2011 | 8:32 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 12 2011 | 9:36 pm
      In saying "allows the user to create objects" I'm assuming you mean it is possible to have a standalone script objects into existence? You'd have to create a way of cataloging and storing the changes the user made. So if, during their session, they did stuff that instantiated objects x,y, and z, you'd have to store that information in a file. That file could be a text file, created with coll, text, or a javascript, or a json file, generated with the help of pattrstorage, or a json file saved from a javascript, really depends on the patch, but yes, it's probably possible.
    • Sep 12 2011 | 9:37 pm
      Then, of course, when the standalone started again, you'd have to recall your file and use it to script out all the things that were done before.
    • Sep 12 2011 | 10:03 pm
      Thanks! I will look into different ways of cataloging newly created objects. I'm sure it could work, but I think it would take a fair amount of time to come up with a way of storing. But I like the ideas you presented. Thank you
    • Sep 12 2011 | 10:27 pm
      The complexity of recall depends on how you allow the user to create objects, and if the timing of those things are important. If you are using javascript to script objects into existence, you may want to look into an earlier post I have about JSON in javascript:
    • May 18 2013 | 3:21 am
      I have build this solution...maybe she's not elegant, but it works... any suggestion is appreciated...but please without javascripts..I don't understand them...:-)
    • May 18 2013 | 3:35 am
      With this patch you can create 10 obj instances (depending how much objs you need to create in each instance...using the scripts to "thispatcher"). If you need more instances, change the attributes to the "gate", "route" and "pak" objects (they should have the same number of in/outlets). The storeable presets are can add some others to have more presets (copy all the related objs for the store and recall function)...and you have to change the maximum attribute to the object number too (near the "create new object" button). To see all the created objects (if more than one), switch in edit mode and move the created objects...and see the varnames of them. I don't have send them the x-y coordinates yet, but that's easy to do and to save in the pattstorage. The created file is a .xml, so you can check what you have saved.
    • Feb 27 2014 | 5:27 pm
      Hi KeepSound, This is exactly what I'm looking for! Except, I don't immediately get the process behind it. Could you post a reduced version of this and briefly explain the steps that you are using? i.e. no need for presets:
      I only need a way to recall the most recent state (e.g. instances, patch cords, and values) of all scripted-into-existence objects each time someone closes and re-opens a patcher in runtime. I am very much obliged for your help!! Chet
    • Feb 28 2014 | 11:38 pm
      Hi Chet, thanks for your interest in this patch... all what you need is to understand the use of the scripts that you could found in the thispatcher.maxhelp. (see making new objects) What I've do is to create objects using the script command with name variables. In my example, I don't have inserted the x/y positions on any new created group of objects, but this is easy done by adding the right variables in the presentation_rect values (so you can add different positions at every new group of objects created). Important is to give at every created objet, a unique scripting name, so that you can connect them with the others you want, same for deleting them. This way to create and connect objects is useful also in complex audio patches, a good abstraction solves problems where is otherway the necessity to use a lot of selectors that usesa a lot of cpu. By closing a patch, you can use the script delete "yourobj" message, connected to a closebang or freebang obj, same for creating a default patch connection whit a loadbang connected to a script newobject "yourobj" message. The sprintf is used to combine the names of the desired obj to a number, so you can represent a unique scripting name.
    • Mar 01 2014 | 1:20 am
      Hi KeepSound, Yes, Thanks! I understand the scripting of objects and patching them together. What I'd like to understand is basically, step-by-step, what you are doing to 'save' the objects you scripted for recalling later - you do this in presets, but I don't understand. Thanks! Chet
    • Mar 01 2014 | 5:17 am
      Oh, if I remember it right, i save only the numbers that creates the objects. Recalling them in the right order, you can recreate the same objects. Tomorrow I'll reopen my patch and give you more infos about it. Another way to save instances is to write the entire script messages to a text object, save them on a file and later recall them in the order you want. Remember to delete the older object in the last preset, before you load a new one.