Martin Martin

There are many threads regarding this topic and I think I read them all but still haven't found a proper overview of whats possible, what might still be a bug and what not.

So: Big project, a lot of DSP and UI Data, each stored in separate dict's. There is a preset system with stored JSON files which works. But I also want to store the current state (of the Dicts, which store all UI and DSP Presets) inside a liveset without the need of creating a new JSON file for each liveSet.

What I have now is a pattrstorage to store and recall the dicts. This works if i store the current state of the dicts "Store 1" before closing the device inside. Not always though. 

(My current logic is: store the dicts via parameter_mode 1 automatically inside the pattrstorage)

I could go on forever about combinations of pattrstorage and dicts, and different @atributes for each.

But can just somebody explain me how these logically depend on each other inside the given settings, and how to set up a working system?

Dict @embed 1 and recalls stores things, but when and what?

pattrstorage @parameter_enable vs @savemode vs @autorestore 

do I need to actively store a preset into pattrstorage or is there a "safestate"?

How do all these attributes depend on each other?

Thank you so much - i lost already to many hairs about this one..

Hej my dear peoples of max. 
There are many threads regarding this topic and I think I read them all but still haven't found a proper overview of whats possible, what might still be a bug and what not. 

What I have now is a pattrstorage to store and recall the dicts. This works if i store the current state of the dicts "Store 1" before closing the device inside. Not always though. 
(My current logic is: store the dicts via parameter_mode 1 automatically inside the pattrstorage)
I could go on forever about combinations of pattrstorage and dicts, and different @atributes for each.
But can just somebody explain me how these logically depend on each other inside the given settings, and how to set up a working system?

-------more specific questions:
Dict @embed 1 and recalls stores things, but when and what?
Dict @parameter_enable 1  

pattrstorage @parameter_enable vs @savemode vs @autorestore 
do I need to actively store a preset into pattrstorage or is there a "safestate"?

How do all these attributes depend on each other? 

Hej my dear peoples of max. 
There are many threads regarding this topic and I think I read them all but still haven't found a proper overvi

automatically-storing-dict's-inside-a-ableton-session-inside-a-max-for-live-device-again

It works. But only if the live set is being stored first and reopened. (it doesn't matter if the device was inside the live set in the first place)

Any ideas on why and how to make this work from the beginning?

Ok - I found the inconsistency: 
It works. But only if the live set is being stored first and reopened.  (it doesn't matter if the device was inside the live set in the first place)
Any ideas on why and how to make this work from the beginning?

Dict @embed 1 : the dict data is written into the patcher when you save the patcher. On patcher load it will always recall the same data. Has nothing to do with saving a Liveset.

Dict @parameter_enable 1 : if you save the Liveset the current data of the dict is saved with the Liveset and recalled when you load the Liveset.

pattrstorage @parameter_enable 1: all stored presets are saved and loaded with the Liveset. A preset can include a dict, but you have to actively recall the preset to bring the data back to the dict.

Dict @embed 1 : the dict data is written into the patcher when you save the patcher. On patcher load it will always recall the same data. Has nothing to do with saving a Liveset.

Dict @parameter_enable 1 : if you save the Liveset the current data of the dict is saved with the Liveset and recalled when you load the Liveset.

pattrstorage @parameter_enable 1: all stored presets are saved and loaded with the Liveset. A preset can include a dict, but you have to actively recall the preset to bring the data back to the dict.

So where does your confusion come from?   

I agree - I did some more testing and finally got it to work, I will just write down everything in case somebody stumbles upon the same problem

@embed 1 doesn't store the values inside a live set. //ok - expected. has nothing to do with a live set.

@parameter_enable 1: here again. the content of a dict isn't recalled. //in comparison to that. A live.dial with parameter_enable 1 is recalled correctly

now let's add the pattrstorage: connect the dict over a pattr (connecting a dict over the pattr and not autopattr seems to work better) object to it and a live.dial for reference:

first: if in the pattrstorage object initial enable is set to 0 - live crashes after saving. (???)

ok: pattrstorage in parameter_mode 1, initial enable 1. 

I can store a preset in pattrstorage and after opening the live set recall it. 

In my case I automated that process - after storing something in a dict the device automatically (over trigger b b) stored the current state in pattrstorage as preset 1. Opening the live set leads to recalling that preset 1 again. Here the whole thing only worked after storing and reopening the liveset once in advance. 

The strange thing was that it influenced also the behavior of a dict (different name) in another test-device with a manual storing of the preset (which worked from the beginning).

Storing the pattrstorage preset 1 over a onebang connected to the plugsync~ at the beginning of a session solved that problem. 

I agree - I did some more testing and finally got it to work, I will just write down everything in case somebody stumbles upon the same problem
--------
with a single dict inside a M4L device.
@embed 1 doesn't store the values inside a live set. //ok - expected. has nothing to do with a live set.
---------
@parameter_enable 1: here again. the content of a dict isn't recalled. //in comparison to that. A live.dial with parameter_enable 1 is recalled correctly
-------
now let's add the pattrstorage: connect the dict over a pattr (connecting a dict over the pattr and not autopattr seems to work better) object to it and a live.dial for reference:

ok: pattrstorage in parameter_mode 1, initial enable 1. 
I can store a preset in pattrstorage and after opening the live set recall it. 
-------
In my case I automated that process - after storing something in a dict the device automatically (over trigger b b)  stored the current state in pattrstorage as preset 1. Opening the live set leads to recalling that preset 1 again. Here the whole thing only worked after storing and reopening the liveset once in advance. 
The strange thing was that it influenced also the behavior of a dict (different name) in another test-device with a manual storing of the preset (which worked from the beginning).
Storing the pattrstorage preset 1 over a onebang connected to the plugsync~ at the beginning of a session solved that problem. 


test.dict_parameter_mode.amxd

 @parameter_enable 1: here again. the content of a dict isn't recalled.  

Hmm I think I found possible origins of failure.

if you name the dict like you did it will be a global dict for the whole live set. 

So if you have more than one device this corrupts the whole system.

if you name the dict like that ---test it will be a different one everytime you load the session and nothing will be recalled (like I tested it previously - and that was the difference)

If you then add a pattrstorage (without ---) to store these dicts live keeps crashing.

Hmm I think I found possible origins of failure. 

if you name the dict like you did it will be a global dict for the whole live set. 
So if you have more than one device this corrupts the whole system.

If you then add a pattrstorage (without ---) to store these dicts live keeps crashing. 

If you change the dict name with a random one on startup (that is what happens when you use --- ), you can't save their content - or rather Live won't be able to find the previously saved data because the parameter had a different name in the previous session. pattrstorage may be crashing for the same reason (because it does not find the object with the reandom name that had been given the last time).

If you don't name your dict and you do @parameter_enable 1 and don't use pattrstorage ; Live should be able to manage that.

You should also set @embed to 0 (if you want values to be remembered inside a live set, and not by the m4l device itself).

If you change the dict name with a random one on startup (that is what happens when you use --- ), you can't save their content - or rather Live won't be able to find the previously saved data because the parameter had a different name in the previous session. pattrstorage may be crashing for the same reason (because it does not find the object with the reandom name that had been given the last time).
If you don't name your dict and you do @parameter_enable 1 and don't use pattrstorage ; Live should be able to manage that.
You should also set @embed to 0 (if you want values to be remembered inside a live set, and not by the m4l device itself).


I tried to give the dicts unique names by using the device ID [path this_device]which stays constant for a device on reload of a session. 

The problem: the dict must be renamed on reload because it gets a new generic name every reload.

I tried putting the dicts inside a bpatcher and using the #0 for unique naming - but that changes also every reload.

---I just can't believe I am the only one trying to store unique dict's inside a M4L patch?

Pattrstorage seems to have huge problems handling dicts with unique names - so it would be actually the solution to the problem but leads to crashes quite often.

I tried to give the dicts unique names by using the device ID [path this_device]which stays constant for a device on reload of a session. 
The problem: the dict must be renamed on reload because it gets a new generic name every reload. 

I tried putting the dicts inside a bpatcher and using the #0 for unique naming - but that changes also every reload. 

Pattrstorage seems to have huge problems handling dicts with unique names - so it would be actually the solution to the problem but leads to crashes quite often. 

Sorry @vichung - did not refresh the page and haven't seen your reply.

just don't do anything and live handles everything. 

(I also had no change the scripting names to something without a ---) 

I think I will write a M4l developing guide when this is over - there are just too many holes in the official documentation...

and F*CK ME!! yes! 
I am a victim of my trust issues. 
-----
just don't do anything and live handles everything.  
(I also had no change the scripting names to something without a ---) 
-----
I think I will write a M4l developing guide when this is over - there are just too many holes in the official documentation...

Sorry @Martin Martin. I hadn't thought that you might be using the --- prefixes for the dict names. You're right with the holes in documentation.

Automatically storing Dict's inside a Ableton Session inside a Max for Live Device.... again..