Forums > MaxMSP

Bpatcher BUG

May 3, 2008 | 9:34 pm

I have isolated a bug when editing bpatchers in different instances. Example patch included.

Steps to reproduce:

1. Open myMain

2. Click the button to "fill randomly". Each bpatchers will fill their colls randomly, displayed in the referred jit.cellblock.

3. Open any one of the bpatchers to edit. (Contextual menu Object > New View of "myBpatch.maxpat".

4. Allow it to be edited by selecting "Modify Read-Only" in the Edit menu.

5. Edit the bpatchers (even just move something), then save. All bpatch instances should be updated.

6. Click the button to "fill randomly" in any of the other bpatchers. An error message appears in Max window, and it no longer works.

Note that when you now open the original bpatcher, the coll object will still read "#1_myColl", but if you open the coll, it will display "One_myColl" (or whatever instance you saved).

What I think happened:
By saving the edited bpatcher, it saved it as the instance (i.e. One_myColl) instead of the variable (#1_myColl). This becomes clear when you double click on the colls in the non-edited bpatchers, which now have the same name as the edited one (i.e. One_myColl, when it should be Two_myColl).

This makes sense, but what is the point of having "Modify Read-Only" if it makes that instance the default instance?

I’ve copied the compressed files here, but also attached a zip archive.

Max 5.0.1
Mac OS 10.5.2
MacBook Pro Intel 2.4 Ghz

Save as myMain.maxpat

– Pasted Max Patch, click to expand. –

Save as myBpatch.maxpat

– Pasted Max Patch, click to expand. –
May 3, 2008 | 9:37 pm

On further thought, this seems to be a coll bug, rather than bpatcher, since all other instances (i.e. values, send/receives) are fine.

May 3, 2008 | 10:05 pm

I would categorize this as a MRO bug.

May 3, 2008 | 10:24 pm

2008/5/3 Chris Muir :

> I would categorize this as a MRO bug.

Sorry, but I’ve forgotten the acronym. That would be…?

May 3, 2008 | 10:53 pm

On May 3, 2008, at 3:24 PM, Arne Eigenfeldt wrote:
> 2008/5/3 Chris Muir :
>> I would categorize this as a MRO bug.
> Sorry, but I’ve forgotten the acronym. That would be…?

Modify Read Only.

It happens when you instantiate your myBpatch.maxpat as a normal

To reset the behavior, you have to open myBpatch.maxpat, and retype
the coll name so that it gets rebuilt from scratch


Chris Muir

October 21, 2009 | 9:02 am

Hi, sorry to revive such an old thread, but I found a solution for this bpatcher problem with Modify Read Only (frozen attributes) and couldn’t find it mentioned yet.
(Which might also be due to the very bad search function in the forums.)

I had the same problem of bpatcher-inside-abstraction arguments becoming stuck to the instantiated values after editing the abstraction with "Modify Read Only" until I noticed in the inspector that the bpatcher argument became frozen (the colour was blue-ish). I don’t know if this is a bug or a feature, but I can’t imagine an explication for it. The introduction at doesn’t go that deep.

There was no way of editing the bpatcher argument to become variable again (it looked like being edited, but snapped back in the instanciated abstraction), and not knowing about the new possibility of freeze/thaw, it created some hassles for me.

Attached is a zip of three patches to illustrate the problem.

Hope this helps.

October 25, 2009 | 2:56 pm

if you have steps to reproduce, feel free to post.

October 29, 2009 | 9:46 am


1. open the main patch, double-click abstraction, MRO the abstraction containing the bpatchers, note the #0 instance numbers in the receives are still the same, save the abstractions.
2. re-open the patch and the abstraction, note that the instance number in the bpatcher has been frozen

But I can also just come up to your office and show you =-)
(or you can explain the sense of "freeze attributes" to me and why the above might be a feature and not a bug).

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

Forums > MaxMSP