discopatrick

I have a M4L device that, through a number of nested abstractions, contains a row of bpatcher objects each containing the same original patch.

This patch contains 4 live.numbox objects. I've used live.numbox because I know that it retains it's value between saving/closing a Live Set and then reopening that Set.

On loading this patch, a loadbang object sends a bang to each live.numbox, and then the 4 numbers are used to set the background colour of a panel object.

The problem is that only half of these panels end up having their colour set when I open the Live Set.

This is much easier to show than to explain - if anyone would like to try opening this live set and related patchers, I have attached them all in a zip.

When you open the Live Set, you will see a row of colour swatches - each one is settable by clicking on a tab (1 through 10) and then clicking a point on the colour spectrum on the left.

If you edit my patch the first thing you will notice is that there are a number of seemingly pointless layers of abstraction - this is only because I have removed all the other objects that filled up these layers in order to isolate the problem. Just take my word for it that there was a reason behind all these layers.

It is interesting to note that if I take one of the lower layers (swatch-select-store-debug.maxpat) and place that as a bpatcher directly into my M4L device, then all of the panels load to the correct colour. So I think it's safe to say that the problem is rooted in the large number of abstractions.

Any help would be much appreciated - thank you!

multiple instances of the same abstraction behaving differently