Bpatcher BUG

May 3, 2008 at 9:34pm

Bpatcher BUG

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. –
#37517
May 3, 2008 at 9:37pm

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

#129691
May 3, 2008 at 10:05pm

I would categorize this as a MRO bug.

#129692
May 3, 2008 at 10:24pm

2008/5/3 Chris Muir :

> I would categorize this as a MRO bug.

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

#129693
May 3, 2008 at 10:53pm

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
abstraction.

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

-C

Chris Muir
cbm@well.com

http://www.xfade.com

#129694
Oct 21, 2009 at 9:02am

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 http://www.cycling74.com/products/maxup25d 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.

#129695
Oct 25, 2009 at 2:56pm

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

#129696
Oct 29, 2009 at 9:46am

sure:

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).

#129697

You must be logged in to reply to this topic.