Forums > Max For Live

help with pattr storage within a bpatcher

May 15, 2010 | 3:15 am

I’m trying to use pattr in parameter mode in order to store the values in an itable into my live set. This seems to work fine if I just create a pattr & itable in the .amxd and bind the pattr to the itable.

However, if I create the same scenario in a bpatcher’s .maxpat file, the settings in the itable are not stored with my live set.

Here’s the subpatch where it isn’t saving the itable with the set:

– Pasted Max Patch, click to expand. –

May 15, 2010 | 8:59 am

I notice that the pattr object ‘Parameter Mode Enable’ is not checked..


May 15, 2010 | 3:33 pm

shoot you’re right, my mistake. Here’s the patch with "Parameter Mode Enabled" and it has the exact same problem.

The weird thing is that although the device in my Live set deosn’t remember the itable settings, if I click to edit the .amxd, THAT device loads with the itable settings remembered.

– Pasted Max Patch, click to expand. –

May 15, 2010 | 5:37 pm

In the bpatcher inspector, have you checked ‘Embed Patcher in Parent’?


May 15, 2010 | 8:07 pm

No that wasn’t checked. I’ve gone ahead and checked it on all bpatchers but the issue remains.

Now that all the patches are embedded, here is the entire amxd & sub-patches. You can see that there is 1 bpatcher being used with tabs, then 4 bpatchers inside that using the sub-patch that I pasted earlier. The pattr and itable objects are in those 4 sub-patches:

– Pasted Max Patch, click to expand. –

May 15, 2010 | 8:08 pm

I should also point out that embedding the sub-patches makes things really difficult. I had 1 sub-patch in 4 different bpatchers because I need 4 objects with identical functionality. Embedding all 4 means if I need to make a change, I have to change it in all 4. At least that’s my understanding.


May 15, 2010 | 10:20 pm

I don’t recommend embedding in general, but it’s useful for transmitting patches.

So I was able to load your device and could reproduce the behavior:
When the set is loaded, the itable settings are *not* recalled.
But they can be recalled by opening and closing the editor.

This seems to indicate that the problem has to do with initialization order of objects,
in particular the timing of loadbangs.

Here is a thread with related discussion and useful information (at the end).

http://cycling74.com/forums/topic.php?id=25322


May 16, 2010 | 11:30 am

I’ve just tested a minimal bpatcher containing only a numberbox.
It works fine with a single instance, but not with two instances.
Basically it shows the same problem as your patch:
the first numberbox is recalled only when opening the editor.

But my patch works perfectly in Max standalone!

So I think we need some clarification from the cycling experts..

– Pasted Max Patch, click to expand. –


pm
May 17, 2010 | 1:24 pm

Still, initialization seems to be the big issue in M4L…

The explanations from Jeremy Bernstein were satisfying, but there’s still some inconsistency there, which for me the last thing you want in a programming language.

Please solve that issue or give us a consistent way of bypassing the problem.

Thanks!


May 21, 2010 | 12:49 am

broc, I’m actually able to save/restore your number boxes. I also added itables to your bpatches and was able to save/restore them.

That’s all with emebedded patches which won’t work for me in the long run but it’s definitely encouraging.


May 21, 2010 | 11:32 am

So I wonder what happens if you de-embed the bpatchers in my example?


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