I just did a spotlight search to see if the file had been written somewhere else. Found this. Now I'm really confused.

Well let's see... I could just keep talking to myself...

2 quick notes:

1) it works fine as a patch but has the problems described above as an app.

2) In the first post several times I refer to "prefs" when I mean "presets" (sorry)

Anybody?

maybe closebang is working in a patch because max is still running when the window was closed. i think closebang doesn't work with the main patcher in a standalone because the runtime is closed with it. correct me...

I don't think so. When I close the app the timestamp on the presets file is updated indicating that it is being written. Plus, the app and the patch use the same preset file. If I add presets while running the app they show up the next time I run the patch - but not the next time I run the app (and because they're not there when I close the app and run the patch they're gone again - because the app rewrote the preset file without them.)

The state of the preset seems to be stuck at the state it was in when the app was created. Is the app reading a different file?

But thanks for responding. Anybody else?

have you tried to use the absolute path for writing and reading?

ok, closebang works as expected. i was able to reproduce what you describe. i'm using presets with auto read/write in standalones without problems but always with absolute path. i'll give it another try later. O.

Thanks for trying that out. I'm sure that an absolute path would work but it doesn't seem to be a viable solution for an app distributable to any machine. Or is it? Am I missing something?

I understand that Mac app guidelines specify where presets should be stored (although I can't seem to find that specific info) in order to be acceptable to the app store. This is discussed in the thread referenced in a previous post. In that thread it's also indicated that Max 6 now writes prefs to the proper directory. I can't find any definitive documentation on this.

The more I look at this the stranger it gets. When I create an app a copy of the presets file is written to

Applications/Max6/cycling74/interfaces/

this entire directory is copied into the app package at

appname.app/Contents/support/interfaces/

The preset file stays in the Applications subdirectory so that the next app I build contains its own preset file and the previous preset file as well... and the next app contains three then four and so on. Neither the preset file in the Applications subdirectory or the one in the app package is written to or read from. This can't be right.

the thread you're refering to is about the preferences files which has nothing to do with presets. i'm on windows, so i don't know much about mac app packages. i'm simply using the senndapppath message to max to get the absolute path of my application. and then i use it for my presets. O.

I really appreciate your taking the time to respond to this.

Sorry about the prefs/presets confusion. I guess I'm making an assumption that presets might be stored on a Mac in the same location as preferences which I believe (but do not know for certain) would typically be /Library/Preferences/appname/. This could be an error.

I do know that it is not common practice on a Mac to write any type of file into the /Applications directory which is where all apps typically reside. It would seem that a logical place to store such internal data would be in the copy of the presets file that is inside the package.

Your help is as I said greatly appreciated but it would be swell if someone with Mac experience could shed a little light on:

1) the correct way to handle this as a well-behaved Mac app.

2) why my app writes presets in one file but doesn't read from the same file as the documentation seems to indicate it should

3) this business about accumulating past presets files in the interfaces directory and subsequent apps.

The solution I found for my apps was to "include folder" containing the "preset" file when building the app. I hope it will work for you.

Thank you very much for your suggestion. I have a couple of questions.

Using the patch posted at the top of this thread - when I click the "write test.maxpresets" message, or close the patch and let the closebang send the message, the presets file is written into the current directory, i.e. the folder containing the patch/app. If I create a folder (let's say named "pre") inside the current folder, modify the message to read "write pre/test.maxpresets" and click the message no file is written (and no complaint is registered in the Max window).

If I create a folder and place both the patch and the presets file in it, and include that folder in the app build, then the presets file is written properly when the app is closed, but is still not read when the app is opened. There is no complaint in the Max window that the file is not being found - obviously some presets file is being read because the preset object shows the presets which were set when the app was built.

Can you show me, by modifying my patch or providing your own, how you did this.

As I mentioned in the first post, I include the presets file in the app build, not in a folder but as a file. How is including a folder containing the file different?

Again, thanks.

This has confused me in the past as well, especially as presets are saved with a patch...but in a standalone, they have to be stored in a separate file (you can't modify the app itself). Be sure to use the "sendapppath" command to create a full path to your app folder, otherwise presents (and other files) can get written into the C74 folder. I too have a number of old preset files drifting around in there which I keep re-discovering.

I do wish that by default, saying "write my_presets.maxpresets" (where you don't specify a path by browsing) it would go into the same folder as the patch, but this is not the case. The same would be great for a standalone. But if you use "sendapppath" or "path" to [thispatcher] (for a patch) it should read and write fine.

Thank you both for your help.

In case anyone else has had this problem here are a couple of patches that demonstrate a way to do it:

as a patch:

as an app:

Thanks again.