Hiding from [pattrstorage]?

Charles Turner's icon

OK, here's another one:

I have an M4L patch that includes Emmnuel Jourdain's [ej.function] to provide some parameter envelopes. I have [pattrstorage] set up to store this parameter data to a JSON file.

I also have some [pattr] combinations set up to provide combinations of automation and storage:

2 [slider][pattr] combinations that are automated and stored
2 [number][pattr] combinations that are automated and stored
2 [textedit][pattr] combination that are stored

What I find is that if I check the "hide from pattrstorage" attribute on these six parameters, they're "unchecked" sometime between the time I saved the M4L patch and it gets loaded again as part of a clip. [pattrstorage] is busily storing all of these parameters, and doesn't seem able to be stopped.

So are the "automated," "stored" attributes independent of "hidden from pattrstorage"? Or do parameters have to be "hidden" (what's the point?) to be "hidden from pattrstorage"?

Best, Charles

Charles Turner's icon

Hi raja-

Thanks for the tips. I'll go back a re-read all the material on [pattr]/[pattrstorage].

You'd think that setting up parameter modulation in M4L would be easy, but given that clip modulation seems broken for the [live. ] objects, it isn't.

Best, Charles

Charles Turner's icon

It also appears that M4L will unilaterally fill in the Scripting Name based on what the Long Name and Short Name of the [pattr] object is.

So:

Erase Scripting Name of [pattr] object.
Send "purge" message to [pattrstorage].
Send [getclientlist] message to [pattrstorage]. [pattr] object not on list.
Quit Live.
Launch Live, run M4L device.
Scripting Name has been restored from Long or Short Name in [pattr] object.