Forums > Max For Live

pattrstorage presets not recalled properly

September 29, 2013 | 8:44 am

I’m working on a device in which I need to save two different presets. It works well in a session, but when I save the Live set, open a new set and then open the saved set again, the presets are messed up (Live 9.0.6/M4L 6.1.3). It looks to me like a bug, but I’m still not sure if I’m just doing something wrong. I was able to reproduce the behavior with this stripped down version:

<code>

– Pasted Max Patch, click to expand. –

</code>

To reproduce:

- save patch as m4l audio effect device
- set some buttons to off and click "Save 1"
- set some other buttons to off and click "Save 2"
- switch between "Load 1" and "Load 2" –> presets are recalled as they should
- save the Live set with the device
- open a new Live set
- open the set with the device again
- switch between "Load 1" and "Load 2" –> presets are messed up

Is this a bug or am I doing something wrong?


September 29, 2013 | 3:20 pm

Because your pattrstorage is set to "savemode 1", it should ask you if you want to save upon close. But…I prefer to use "savemode 0", and save it manually.

Check this out, (notice "writejson AllPresets" is connected to the preset object, so when you save a preset, it automatically saves the pattrstorage. Also, make sure the preset object’s pattrstorage attribute is set to "AllPresets")

<code>

– Pasted Max Patch, click to expand. –

</code>


September 30, 2013 | 3:51 am

Hey Mike, thank you so much for taking the time! I will check if I’ll get more reliable results with you method, but for now I’m still confused. I went through this tutorial:

http://cycling74.com/2011/05/19/max-for-live-tutorial-adding-pattr-presets-to-your-live-session/

There it is mentioned:

"We can enable the saving of pattr preset data in your Live set rather than writing and reading preset data from an external data file by setting a single attribute.

If you’re a regular user of Max accustomed to using the pattr family of objects, you’re no doubt accustomed to saving pattr presets as a part of your patch by setting the autorestore and savemode parameters. Many users include those attributes as arguments to the pattrstorage object using the standard at-sign syntax (e.g.pattrstorage my-presets @savemode 0 @autorestore 0).

In Max for Live, you can achieve the same result by enabling the Parameter Mode Enable attribute.

Select the pattrstorage object and open its Inspector. Locate the Parameter Mode Enable attribute and click in its checkbox to enable the parameter. When you do, you’ll see a new group of attributes appear in your Inspector. These new attributes are all unique to the use of the pattr objects with Max for Live.

Note: You’ll notice that when you click on the checkbox to set Parameter Mode Enable, the savemode and autorestore attributes will be greyed out when displayed. You may also notice that the values for the greyed out parameters are set to values of 1 rather than 0. The displayed values represent the default value of the attribute before it was disabled – the behavior of the pattrstorage object will be precisely as though you had set both attribute values to 0."

In addition to that, if you open the pattrstorage Help, go to the Max for Live tab and check the settings of the pattrstorage object it’s just like my settings. It really looks like there is something broken with Parameter Mode, at least in my setup (Windows 8, Live 9.0.6, Max 6.1.3, everything 64bit). Can someone confirm this?

PS: Below you find my test patch to make testing easier. It has to be noted that something IS saved with the set, but what is reloaded is a mess.

Edit: I just realised that there was a silent update after I installed Max (I was on "Version 6.1.3 (c65b953)") and in another desparate try I uninstalled Max, downloaded Max61_x64_130708_ac9dafd.exe and installed it: it’s still a mess. I also tried to set all the buttons to Hidden instead of Automated and Stored, because I thought there might be a conflict between the button storage and the pattrstorage: but the mess when reloading a set goes on…


September 30, 2013 | 9:00 am

Does it make any difference if you use plain toggles as opposed to live.toggles which are bound to the live set as parameters? Or perhaps if you make the parameter state of the live.toggles hidden? There may be some kind of grinding of the gears there

Cheers


September 30, 2013 | 11:56 am

Thanks for joining in Andrew! Setting Parameter Visibility of the live.toggles to Hidden doesn’t make a difference. I tested that before but I tried it again just after your post and the crazy thing is it worked the first time I saved/reloaded the set with the device, but the second time all was messed up again?!?!

Then I deleted the live.toggles and putted in some plain toggles, enabled Parameter Mode, set Parameter Visibility to Hidden and tested it again. 1st test, a mess, 2nd test, presets reloaded properly!, 3rd and 4th test, again a mess.

I also tested if it would make a difference if I close Live instead of open a new set and then the saved set again: nope, still a mess.

I also tested if it would make a difference if I used a MIDI device instead of an audio device: nope..

I’m really stumped.


September 30, 2013 | 12:14 pm

Ok I just tried this with the device kindly uploaded by because789 and it works fine for me.

Mac 10.8.5 Live 9.0.6 and Live 9.1b17, Max 6.1.4beta , x64

Quitting live then reopening, after loading other sets or right after restart.

-A


September 30, 2013 | 1:24 pm

Thanks so much for testing this Andrew! At least I know now that it has to do with my setup. Therefore once again my system specs:

Windows 8, Live 9.0.6 and Live 9.1b17, Max 6.1.3 (Max61_x64_130708_ac9dafd.exe), x64

I want to emphasise again that it doesn’t happen all the time, I’d say I got 3 out of 4 times a mess.

Since I wasn’t able to find it, is Max 6.1.4beta public? I’d love to try there if my problem persists.


September 30, 2013 | 4:00 pm

OK it’s working for me in Windows 8 x64 as well

Max 6.1.4 will be out in a few days, but we’ll try some regression testing just to be sure

Cheers


October 1, 2013 | 1:02 am

I just sent an email to support with a video which shows some tests with the unexpected results I get on my system. I used the patch I uploaded here which worked for Andrew. Just to give you a proove that I’m not crazy :-)

I made a further test by replacing the toggles with live.text objects set to Hidden. The problem persists…


Viewing 9 posts - 1 through 9 (of 9 total)