Florent Ghys

I am wondering why the values of these two live.numbox and number objects are being saved in pattrstorage, while their parameter visibility in the inspector has been set to "Hidden".

autopattr

number

live.numbox

message

pattrstorage

Usually in the same situation, the storage window shows the parameters but no value is saved, like here:

Screen Shot 2019-09-27 at 11.54.03 AM.png

Is there a specific argument to tell pattrstorage not to save hidden values? 

Hello, 
I am wondering why the values of these two live.numbox and number objects are being saved in pattrstorage, while their parameter visibility in the inspector has been set to "Hidden".


Usually in the same situation, the storage window shows the parameters but no value is saved, like here:

Is there a specific argument to tell pattrstorage not to save hidden values?  
thanks
Florent


Hello, 
I am wondering why the values of these two live.numbox and number objects are being saved in pattrstorage, while their parameter vis

pattrstorage-please-don't-save-hidden-parameters

In my humble opinion, the parameter visibility refers only to the behavior in automation of Ableton Live.

In Max you have to explicitly exclude them (e.g. autopattr 2th out).

In my humble opinion, the parameter visibility refers only to the behavior in automation of Ableton Live.
In Max you have to explicitly exclude them (e.g. autopattr 2th out).

It's strange, I am looking into several patches right now that do exactly what's shown in the picture, and in which pattrstorage does not save hidden parameters. I just cannot tell the difference between these and the first example above. 

thanks for your answer. 
It's strange, I am looking into several patches right now that do exactly what's shown in the picture, and in which pattrstorage does not save hidden parameters. I just cannot tell the difference between these and the first example above. 


You are totally right. The reason why the screenshot above happened is because of newly created objects that hadn't been stored in the pattrstorage yet. 

Is unchecking the check box in the storage window a reliable way to hide data from pattrstorage? 

I am just trying to avoid patch chords all over the place

You are totally right. The reason why the screenshot above happened is because of newly created objects that hadn't been stored in the pattrstorage yet. 

Is unchecking the check box in the storage window a reliable way to hide data from pattrstorage? 

I am just trying to avoid patch chords all over the place


Unchecking does not really hide the parameters but simply makes them inactive.

The annoying thing – especially if the list is long – is that they are always present. For this reason I am used to excluding them by cable.

An option in the inspector would be fantastic…

Unchecking does not really hide the parameters but simply makes them inactive.
The annoying thing – especially if the list is long –  is that they are always present. For this reason I am used to excluding them by cable.
An option in the inspector would be fantastic…

how do you do when you have to deal with let say 50 parameters that either need to be included or excluded? Do you really use patch chords all over the place? 

Using individual pattr objects doesn't seem to be a better solution either.

An option such as "include/exclude in pattstorage" in the inspector would make sense. 

It would make even more sense if parameters with a "hidden" visibility were not saved at all.

how do you do when you have to deal with let say 50 parameters that either need to be included or excluded? Do you really use patch chords all over the place? 
Using individual pattr objects doesn't seem to be a better solution either.

An option such as "include/exclude in pattstorage" in the inspector would make sense. 
It would make even more sense if parameters with a "hidden" visibility were not saved at all.


Exactly. I haven't found better solutions.

Do you really use patch chords all over the place? 

if someone happens to read this and has found a better way to do this, please let us know! 

every single of my patches look like this now:

Screen Shot 2019-09-27 at 5.43.19 PM.png

For some reason I do not trust the storage window's check boxes...

oh well, thanks for your feedback. 
if someone happens to read this and has found a better way to do this, please let us know! 
every single of my patches look like this now: 

When autopattr is used with the @autoname set to 0 (the default) it saves the state of objects that have a scripting name. If you delete the scripting name in the object inspect it will not longer be seen by pattrstorage.

yes! but unfortunately it is impossible to remove the scripting name of a live.something object 

Removing the scripting name of live.something objects works here. Maybe you try to remove the long/short names, which is not possible. Scripting name can be empty.

I use [pattrstorage @subscribemode 1] where nothing gets stored by default. A [coll] driven by an [uzi] subscribes my objects. This way I can use named objects wherever I want but only store what I need.

Usually I have the subscription list in a text file, so I don't lose it if something goes wrong.

Removing the scripting name of live.something objects works here. Maybe you try to remove the long/short names, which is not possible. Scripting name can be empty.
—
But there is another way you may prefer:
I use [pattrstorage @subscribemode 1] where nothing gets stored by default. A [coll] driven by an [uzi] subscribes my objects. This way I can use named objects wherever I want but only store what I need.

Thanks Peter! the problem with removing the scripting names of live objects is that they reappear as soon as the patch is restarted. Check this out, first live.numbox's scripting name has been removed and when you restart the patch it is automatically called live.numbox:

It actually behave the same way in your patch. The live.numbox (no name) is actually called live.numbox when I start the patch on my computer:

Screen Shot 2019-09-28 at 11.11.48 AM.png

Your technique is very helpful, I'll give it a try. I didn't know about pattrstorage's subscribe mode. Thanks a lot!

Oh, thanks, I didn't know about the self-renaming live objects. Probably because I generally use subscribe mode in pattrstorage ;-)

Btw: You can also unsubscribe, if you want.

Hi Florent, for the checkboxes you mentioned, there is an attribute to enable storing them with the patch, something like activewritemode.

I didn't know about [activewritemode 1]. Indeed, it saves the list of inactive clients inside the json file, which is super useful.

Is there a way to change the active state of client objects without clicking in the storagewindow's checkboxes, or subscribing/unsubscribing like Peter above?

When working with huge, messy, and old patches, both solutions are kind of annoying, especially if scripting names are not properly labelled. 

Connecting autopattr's "include connection" and "exclude connection" to individual objects works better, but it makes the patches even messier. 

It would be really useful if one could just click on an client and select "include/exclude in pattstrorage"

thanks Ernest, this is very helpful! 
I didn't know about [activewritemode 1]. Indeed, it saves the list of inactive clients inside the json file, which is super useful. 

Is there a way to change the active state of client objects without clicking in the storagewindow's checkboxes, or subscribing/unsubscribing like Peter above? 

When working with huge, messy, and old patches, both solutions are kind of annoying, especially if scripting names are not properly labelled. 
Connecting autopattr's "include connection" and "exclude connection" to individual objects works better, but it makes the patches even messier. 
It would be really useful if one could just click on an client and select "include/exclude in pattstrorage"




Yes you can set the Active 1 or Active 0 message to most gui objects.

to my understanding, the active message of live objects enable/disable the object itself but not its ability to be stored inside pattrstorage

how? 
to my understanding, the active message of live objects enable/disable the object itself but not its ability to be stored inside pattrstorage


pattrstorage: please don't save hidden parameters