Michael Sperone

I have a patch with a preset object and it's not saving the presets when I close the patch... I have done this before, in fact I have a patch where my presets are saved from several months ago and they still work as expected... this has wasted my last hour of working and I'm getting frustrated!!

As far as I've used it in the past, I just include preset, hook it up to the objects I want it to remember and shift click and it's all set. But that's not working now. The help files didn't help and led me to believe that I'm using it as it should be. So I don't get why this isn't working now.

I know you're going to tell me to use pattr instead... as I have seen in previous posts, but I haven't learned the pattr system yet and I just want a quick easy way to save a few presets without having to waste anymore time.

I'm guessing I'm just forgetting something stupid, but I can't figure out what it might be.

As far as I've used it in the past, I just include preset, hook it up to the objects I want it to remember and shift click and it's all set.  But that's not working now.  The help files didn't help and led me to believe that I'm using it as it should be.  So I don't get why this isn't working now.

why-is-my-preset-not-saving-my-presets

Have you made sure that "save present in patcher" is checked in the object inspector? It should be checked by default so I don't imagine that is the cause of your problems. If you decide to look in to pattr, and it's not as scary as you might imagine, then I recommend looking at Chris Muir's PattrKitty example which you can find here:

the pattr family of objects really is like a fluffly little kitten!

It's a pretty big patch and I made a smaller test version to post here, but it worked fine there... is there a limit to how many objects it can store? I thought it was 1024, I don't have that many objects in the original patch...

I have to go teach now, but I'll look into this and perhaps post the whole patch later.

It's a pretty big patch and I made a smaller test version to post here, but it worked fine there... is there a limit to how many objects it can store?  I thought it was 1024, I don't have that many objects in the original patch...

so I deleted the preset object I had and put in a new one and now it works.... Oh well. At least it works now. Thanks for the help!

so I deleted the preset object I had and put in a new one and now it works.... Oh well.  At least it works now.    Thanks for the help!


so now it seems that everytime I fix something involving my preset object, it causes it to lose the ability to save presets.

I added a few objects to the "exclude" output and it stopped saving. Then I deleted my preset object and put a new one in and it worked. Then I made a few more changes to some excluded objects and now my presets won't save again...

I added a few objects to the "exclude" output and it stopped saving.  Then I deleted my preset object and put a new one in and it worked.  Then I made a few more changes to some excluded objects and now my presets won't save again...

I can't seem to isolate the problem in another patch... so I'll post the one where I'm having the trouble.

Michael, you should just start using pattr instead of messing around with the preset object. It's not rocket science - in

1. Open the Inspector for each and every UI object you want to save as part of a preset, and enter a unique name for the Inspector’s Scripting Name setting (functional names are the smart way to go).

2. Add a pattrstorage object to the patch and gave it a name (e.g., mypattrstorage).

3. Add an autopattr object to the patch (which has the effect of adding all the objects with scripting names to the pattr registry automatically).

4. Add a preset object to the patch, open its Inspector, and enter the name you gave your pattrstorage object to the Value column for the pattrstorage attribute. Once you do this, you can use the preset object to load and store presets for the patch.

Michael, you should just start using pattr instead of messing around with the preset object. It's not rocket science - in
fact, it's done in 4 steps:

True that's simple enough, and that's probably what I'll do...

but shouldn't preset work by simply adding it to the patch? that's how it's worked for me in the past... and it was working like that until I reconnected some objects to it.

but shouldn't preset work by simply adding it to the patch?  that's how it's worked for me in the past... and it was working like that until I reconnected some objects to it.


On Dec 18, 2008, at 9:38 AM, Michael wrote:

The pattr world is much more robust than preset. I would use autopattr.

Might be. Without seeing the patch, it's pretty hard to tell.

Chris Muir
cbm@well.com	
http://www.xfade.com

my guess is that when you store new presets, you also need to resave the parent patch so that the new presets actually get written to the max patch file. so you have to dirty the patch after storing or changing presets, then save.

my guess is that when you store new presets, you also need to resave the parent patch so that the new presets actually get written to the max patch file.  so you have to dirty the patch after storing or changing presets, then save.

> so now it seems that everytime I fix something involving my preset object, it causes it to lose the ability to save presets.

> I added a few objects to the "exclude" output and it stopped saving. Then I deleted my preset object and put a new one in and it worked. Then I made a few more changes to some excluded objects and now my presets won't save again...

Not sure if this is the same thing, but I've had some weirdness with preset in max 4 and 5---sometimes the saved presets aren't quite what you would imagine, if you've changed the objects it's saving or excluding. If you think about it, it kind of makes sense, since if you save a few presets, then add some objects, then save a few more, the first presets don't (appear to) automatically create "data slots" for the newly-added objects. So you'd need to resave those.

I know it can be a pain, but the best luck I've had if things change with the preset is to "clearall" and resave them. Also, duplicating a preset-with-objects doesn't have the effect imagined---the new one still references the objects connected to the old one (until you resave the presets), instead of referencing the new objects. So I always wait on saving my "final" presets until the patch is essentially done.

As said, look into pattr---if you recall your slots using integers, it functions basically the same as preset (on the surface anyway). This is great for things like "on/off" toggles or anything where you want to jump to the new values. Of course, the beauty is the built-in interpolation between presets, which is great for all kinds of other data values---freq, amp, brightness, gl object size, etc. And as Gregory mentioned, you can use the preset UI to store/recall pattr slots (which I was unaware of---thanks!) It definitely makes pattr more intuitive to use.

> so now it seems that everytime I fix something involving my preset object, it causes it to lose the ability to save presets.
>
> I added a few objects to the "exclude" output and it stopped saving.  Then I deleted my preset object and put a new one in and it worked.  Then I made a few more changes to some excluded objects and now my presets won't save again...
>

max5 crashes when pressing shift+o in an empty patcher.

in the maxinterface.json the O is defined two times:

is it ok to have two definitions like that in maxinterface.json?

what is the difference between "jopen" and "customopen"?

a moment before the crash i see a jamoma module for a few milliseconds ...

Path: /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP

__ZN13TTAudioObject10setProcessEMS_F5TTErrR13TTAudioSignalS2_E

Support/TTBlue/Extensions/TTFunctionLib.ttdylib

Expected in: /Library/Frameworks/TTBlue.framework/Versions/A/TTBlue

max5 crashes when pressing shift+o in an empty patcher.
in the maxinterface.json the O is defined two times:

    {
            "message" : "jopen",
            "label" : "Open...",
            "navkey" : "O",
            "target" : "max",
            "shortcut" : "O"
        },
        {
            "message" : "customopen",
            "label" : "Open...",
            "navkey" : "O",
            "target" : "menubar",
            "shortcut" : "O"
        },

is it ok to have two definitions like that in maxinterface.json?
what is the difference between "jopen" and "customopen"?

i have installed jamoma via svn.
a moment before the crash i see a jamoma module for a few milliseconds ...
is jamoma using this key, too?

Date/Time:      2008-12-20 00:40:43.939 +0100
OS Version:     10.4.11 (Build 8S2167)
Report Version: 4

Command: MaxMSP
Path:    /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP
Parent:  WindowServer [59]

Symbol not found: 
__ZN13TTAudioObject10setProcessEMS_F5TTErrR13TTAudioSignalS2_E
  Referenced from: /Library/Application 
Support/TTBlue/Extensions/TTFunctionLib.ttdylib
  Expected in: /Library/Frameworks/TTBlue.framework/Versions/A/TTBlue

A little frustration is easy to hit with pattr stuff--indeed it might not be rocket science but in my experience things can suddenly stop working and nothing you do seems to make it work again. The only thing you can do in that case is delete all the pattr stuff and rebuild from scratch, probably with new args to the pattr objects, to be on the safe side.

This just bit me again and an hour later (I shouldn't have even tried) I rebuilt and it works again. pattr is not yet optimal by any means.

A little frustration is easy to hit with pattr stuff--indeed it might not be rocket science but in my experience things can suddenly stop working and nothing you do seems to make it work again.  The only thing you can do in that case is delete all the pattr stuff and rebuild from scratch, probably with new args to the pattr objects, to be on the safe side.

This just bit me again and an hour later (I shouldn't have even tried) I rebuilt and it works again.  pattr is not yet optimal by any means.

I think in the past if you deleted or added objects to pattrstorage, your presets would get lost. I just tried again and all was well. Not sure what's happening in your case, but using [autopattr] speeds the rebuilding tremendously. Of course, if you want non-standard scripting names for the objects, you have to do that part by hand...

It's sad but I experience the same problems with version 8.5.6 or 8.5.7 using pattr or not. I can't use the new versions of Max with the Mac I'm using now. 

Plus I couldn't exclude some interger or message box that were suprisingly keeping data which created a  problem in my programming.

I have tried everything and the only way was to scrap the whole thing , change the pattrstorage name, a new preset object. 

Would be very usefull to be able to save the preset json manually like any another file.

Why is my preset not saving my presets?