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
Save as myBpatch.maxpat
On further thought, this seems to be a coll bug, rather than bpatcher, since all other instances (i.e. values, send/receives) are fine.
I would categorize this as a MRO bug.
2008/5/3 Chris Muir :
> I would categorize this as a MRO bug.
Sorry, but I've forgotten the acronym. That would be...?
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
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 https://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.
if you have steps to reproduce, feel free to post.
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).
Did this ever get explained? I'm glad you asked the question, because my bpatcher args field was indeed frozen. I have no clue how it happened.... maybe just carelessness on my part, but interesting that I'm not the first one.
I have been working in context, so the patches do come up read-only.
-e
edit: I actually had this happen with 5 instances in 5 different places, so I'm pretty sure it's not a mousing mistake! But maybe it is a feature whose importance I don't understand?