sebastianmorsch

What is the easiest way to save the state of a max standalone patch under OSX? My standalone patch application has a couple of user settings (like MIDI key ranges, max velocity, ...) that I would like to keep when the app is closed and reopened.

So far I managed to create an autopattr object to manage the content of the relevant number boxes and flip menus. But I'm fairly new to this and I can't find information about how to save this to disk, preferably to a file in the OSX preference system.

Any hints and pointers are greatly appreciated, thanks.

Any hints and pointers are greatly appreciated, thanks.
Sebastian


saving-state-in-a-preference-file-of-a-standalone-patch

You will (also) need a pattrstorage object to store autopattr's data. Save settings to a pattrstorage slot before or 'while' quitting (check example) . If you name the pattrstorage and set it to @savemode 3, it will (attempt to) write the preset file. Note: the first time, it may bring up a save dialog as the the settings file does not yet exist, so if you don't want users to deal with that you'll need to include that file along with your standalone.

There is also/alternately @fileusagemode meant for standalones but I have not (yet) looked at or tried that feature so not really sure about it - it may well keep the pattrstorage settings file in the app bundle which could be perfect for you). As for saving to the preferences file to the OS X preference system I'll leave that to you (or someone else) to work out...

You will (also) need a pattrstorage object to store autopattr's data.  Save settings to a pattrstorage slot before or 'while' quitting (check example) . If you name the pattrstorage and set it to @savemode 3, it will (attempt to) write the preset file. Note: the first time, it may bring up a save dialog as the the settings file does not yet exist, so if you don't want users to deal with that you'll need to include that file along with your standalone.

There is also/alternately @fileusagemode meant for standalones but I have not (yet) looked at or tried that feature so not really sure about it -  it may well keep the pattrstorage settings file in the app bundle which could be perfect for you). As for saving to the preferences file to the OS X preference system I'll leave that to you (or someone else) to work out...

Thanks spectro, it worked very well! I created a pattrstorage with @savemode 3 which stores preset one on quit and recalls it on start (with 500ms delay). After closing the standalone for the first time, it prompted for a file to save the preset. I moved that file into the app package (next to the .mxf) and from then on it worked without the save prompt. Nice one!

thanks. this is working for me in version 7

just tried a few times to 'hide' a settings file into the standalone app, with no success...

I tested @fileusagemode in pattrstorage, which by default is 0 and means the json/xml file is included into the standalone when building the app.

However, there's no way of 'write'/'writeagain' onto the same file (console gives a -1 error), so basically I assume the xml file is not accessible in real-time by the app user (?)

If confirmed, don't you think that's a wrong behaviour? (the only usage I can find of @fileusagemode is exactly the one I tried to achieve, i.e. 'hide' the settings file inside the app).

The only way I can make this work is to explicitly create the xml file after the first run of the standalone app (which is exactly what you guys discussed here above).

hey guys,
just tried a few times to 'hide' a settings file into the standalone app, with no success...
I tested @fileusagemode in pattrstorage, which by default is 0 and means the json/xml file is included into the standalone when building the app.
However, there's no way of 'write'/'writeagain' onto the same file (console gives a -1 error), so basically I assume the xml file is not accessible in real-time by the app user (?)
If confirmed, don't you think that's a wrong behaviour? (the only usage I can find of @fileusagemode is exactly the one I tried to achieve, i.e. 'hide' the settings file inside the app).
The only way I can make this work is to explicitly create the xml file after the first run of the standalone app (which is exactly what you guys discussed here above).
Any thoughts?
Thank you
L

I had this problem, I created an absolute path to the file (in the app package contents) and read from that, then used the 'writeagain' message to save the changes to the same file...

Stumbling upon this thread a few years later...

I'm relatively new to max and the pattr object. I'm trying to make it so my patch, when built as a stand alone app, will save the current state of numerical values and message boxes between quits/launches. I tried to adopt a patch from above in my pasted patch below, to no avail. Any help is greatly appreciated!

I'm relatively new to max and the pattr object. I'm trying to make it so my patch, when built as a stand alone app, will save the current state of numerical values and message boxes between quits/launches. I tried to adopt a patch from above in my pasted patch below, to no avail.  Any help is greatly appreciated!

for older system versions, storing into application bundle can work,

but all systems with SIP and gatekeeper won't let you

even store something in Applications folder.

So maybe rethink it and use some safe place to store ?

There was a thread about this not long ago

https://cycling74.com/forums/how-can-i-restore-data-after-quit-and-reopen-standalone

If you still want to use patch or Standalone path for that

sendapppath outputs Max.app path if one is editing a patch,

for older system versions, storing into application bundle can work,
but all systems with SIP and gatekeeper won't let you
even store something in Applications folder.
So maybe rethink it and use some safe place to store ?
There was a thread about this not long ago
https://cycling74.com/forums/how-can-i-restore-data-after-quit-and-reopen-standalone
-
If you still want to use patch or Standalone path for that
you can try this

sendapppath  outputs Max.app  path if one is editing a patch,
and so can't be used while programming.


Thanks Source Audio, but i didn't quite get you solution, maybe a bit over my head.

I found a solution by adding "message" to the pattr object, as seen in patch below. Also when building the application, I had to be careful to not let the max patch first save a preference file, otherwise the App would pull its settings from there and not save a new preference file for the app specifically.

Preferences of the standalone app have nothing to do with what you are trying to do.

Preferences get stored according to set preferences name in standalone object inspector.

You can't do much about it, it is auto set so.

Storage of other files depends on different factors,

either full controlable by creating absolute path to some directory,

In any case, you have to know that everything behaves differently in Max, or in Standalone app.

Using absolute path is a safe approach, and will work on any computer.

Also message store or autostore will not work in Standalone same as in editable patch.

Only write to disk can store anything in standalone, because it is sealed, non changeable file.

any auto store, embed in patch and similar things are non functional, once one compiles standalone.

Preferences of the standalone app have nothing to do with what you are trying to do.
Preferences get stored  according to set preferences name in standalone object inspector.
You can't do much about it, it is auto set so.
Storage of other files depends on different factors,
either full controlable by creating absolute path to some directory,
or maybe by creating search paths.
In any case, you have to know that everything behaves differently in Max, or in Standalone app.
Using absolute path is a safe approach, and will work on any computer.
Also message store or autostore will not work in Standalone same as in editable patch.
Only write to disk can store anything in standalone, because it is sealed, non changeable file.
any auto store, embed in patch and similar things are non functional, once one compiles standalone.


Saving state in a preference file of a standalone patch