Are settings in an external bpatcher saved in the pattrstorage root patch ?

I highly recommend downloading my new Touch Objects package. It solves all your problems. Download from GitHub and drop in /Packages folder.

Just drop touch.staus in any patch. Name it and connect to [pattrstorage @savemode 0]--you dont even have to name the [pattrstorage] && (get rid of the obnoxious #0 in your scripting name). Add an autopattr and any object with a scripting name will be found (or use [pattr name] Everything else is built in. It will create a unique json file for each uniquely names [status] in a bpatcher, and automatically store/save and recall when you load. (I think you should ACTUALLY save before closing to be safe)

below is your bpatcher

you can also rename [touch.status] from outside bpatcher.

Then, open a [touch.statusmanager] and your newly named batcher status show up instantly. you can control either on of them in "Palette" menu OR create "Palette Banks" -- have fun!

***look at the [touch.status] help patch - it shows how to rename slots

Sorry, I don't want a package. I want to understand how it work

If there is a package it is possible to do that. How ?

for your current situation , [preset] object woks great. You already have #0_names which make each bpatcher unique.

You can use exacltly this and ADD pattrstorage. Pattrstorage have the same name as [preset] , then use 'read' and 'write' make a .json file.

If you want to understand - then get behind a very long line who have struggled with this over the years. Basic difference is {preset] is just local in one patch, like your bpatcher, while pattrstorage manages large amounts of data, stored in json, and can be pointed to look inside bpatchers and specific objects more easily. Best to start with the help file, but even that will be very confusing, also search on forums for specific answers , or continue to ask questions here.

Here are 2 bpatchers using your patch with [preset]

***the very difficult part about pattrstorage (beside stuff like bindto:) is the savemode, read ,and write messages. Those are a literal horror story. Thats why I made an external to eliminate all of it.

Thank you @WIL I will look. Indeed I read all the documentation I could find and I am not still sure to understand. I tried to add pattstorage in the subpatch and the root patch. I can see the state of each grid in the pattrstorage of the root patch so I guess this part work. This is the load that seems does not work. Do you mean I need on json by instance and trigger the load for each instance from the root patch ?

No need to add #0 prefix to your objects scripting names since the bpatcher scripting name already helps differentiating them from the pattrstorage perspective. It is even a source of troubles since the #0 changes each time you open the patch, resulting in presets not working across sessions (you would save a state for 1234-note-grid, but then when you re-open the patch it gets called 4321-note-grid, for which you have no data stored).

So remove the #0 from your scripting names (but keep it on your buffer names/references).

Once you do that, you will be able to properly store presets in [pattrstorage].

The behavior you expect isn't clear. I assume you want your grid and other pattr-exposed objects to be restored at the same state they were when you saved the patch. This is indeed easy with all objects in the patch (or embedded bpatchers in the patch), but not when you use abstractions. That's where presets become handy. Here is a small example showing how you could automatically save a preset when you save the patch, and recall that preset when the patch loads:

Note that this requires to save the presets in a separate file from your patcher (unless you are making a M4L device).

Another, more portable way, to achieve a similar result is to use snapshots, which allows to store/recall the state of objects with Parameter mode enabled (which is the case for all live. objects) and embed them into the patcher. Last saved snapshot is automatically recalled when the patch opens. In your case, it's just a matter of adding those 3 objects to the main patch:

It will save a snapshot in slot 0 every time you save the patch, and make that snapshot embedded into the patch (so no extra file). No need for any [autopattr] or [pattrstorage].

EDIT: I would argue against the suggestion of using [preset] to store data here. [preset] is fine for objects at the same patcher level, but breaks as soon as you use multiple instances of the same abstraction. In WIL's example, each bpatcher has its own [preset], but saved preset won't survive after closing the patch. The only way to edit those bpatcher presets would be to save the abstraction itself with its new presets. But then all instances of bpatcher will share the same presets.

for the past 100,00 or so years, I have been using 'read' and 'write' messages to save and recall json in pattrstorage. IF IF IF your json file is stored in a very "narrow" discrete location, any max patch can find it using just the file name 'write patch_name.json' and 'read patch_name.json instead of the long file path.

You can see my 2 'global' storage folders are different - the one that says /misc/honey_chicken.json is a Max file/folder path that all Max's can see. The one called /states/honey_chicken is a folder I created a tried to automate max to find. But the ONLY way max can find it is if I define its path in the Options/File Prefences window - So I decided this was a bad idea and directed my touch.status object to use /misc folder to automatically read and write files.

And finally like all max , files can be easily created in various ways, put inside a folder, like RNBO are created on a cloud and put in RNBO folder, and I can autocreate and store audio and video recordings with exact date and time, and these json, but it becomes VERY difficult to scan and remove files when test files start piling up. I literally have 100's of 'test RNBO files I have no Idea what they do and have to open each one to decide keep it or trash it --- So it is IMPORTANT how to name and store these files .

since I am currently in testing mode with touch.status, I will put together a small helpful explainer patch for pattrstorage- it will help me with my work as well.

Ah I see TFL explained things before I finished

In WIL's example, each bpatcher has its own [preset], but saved preset won't survive after closing the patch.

It did work after closing using #0. Thats why I posted. Now it does not work. Thats why I try to build a new 'child proof' system :) Good luck Wil!

Thank you TFL

I assume you want your grid and other pattr-exposed objects to be restored at the same state they were when you saved the patch.

Yes...

Another, more portable way, to achieve a similar result is to use snapshots, which allows to store/recall the state of objects with Parameter mode enabled (which is the case for all live. objects) and embed them into the patcher. Last saved snapshot is automatically recalled when the patch opens. In your case, it's just a matter of adding those 3 objects to the main patch

Did not see that in the documentation where is this documented ? What is Parameter mode and snapshots ?