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.
Mac OS 10.5.2
MacBook Pro Intel 2.4 Ghz
Save as myMain.maxpat
----------begin_max5_patcher---------- 202.3oc0QEqCCBBDcF9JHLaaDaaLsi8GnKcqwz.JQsQfFDSsw3+dQDMcqt3P W33d28tGOtNH.yTs7ZL5D5FB.5f.fCZ..3yAXAsMshV6ZCydRMoEbMNXrHSo yrY1RDOBUm6mH9ZglywnDeEG0RY9cMO0L1x9CaCCPQwgtvw3g.gXCyjJyb5p XO1raRTYinTVwMNcBm.oBtqUw6yNk1Ze31KeQR0XlYM.1CgCGAqh2eoVfyI9 Ofe37n+ImeQtnc9hV4jUx3nDXO7CU6.rpC -----------end_max5_patcher-----------
Save as myBpatch.maxpat
----------begin_max5_patcher---------- 779.3ocwXt0bhBCEG+Y7SQF59HsCgKUX2m1Yee+BzYGm.DaSKj3.wdc528MW PLpfBnk9ffDvC+O+NW3feLyxNg8JtxF7Svc.KqOlYYoVRtfU8wV1EnWSyQUp KyNkUTfobaG8433W4p0KwKwk3LviD9Mo377jbV5SatpkLJmhJvpq72kDT9ly rpDWILGhSXzEk3TtVKdt235.TafP0N4Jf+YXuJx6J6A8Dmt1XHd5CD58FFBF pMRjdW3g1hjoTEK4wqgv1jk5lTuNccAgli4U6sHaMeyptxE+b1L4FmyDpKI4 4fRDMiUj+1ngILNT40psyCOCZ5skesZICVd62DJKvUUn6wGfxzbLp7zHTe24 usBq8Xa6FmqK5NWQCMY7mqy1FGcCzIo21koLSU8FDe8ZkuvQvWJ9Ew8+.7tB k9DvE3dVDd.nJxDUQAGsptQTSKRz0s.n6XfBQzMXDbwOPUTB86QEZ72CV3.B HYjDwAXmfn2eNYLt5LF+aB6lLQ18uGk2HHSxZNWTr1kmtqKd71NdgaaHui6z c26ft9IFDX9En68ELmY86DP3HxYTjzY69QVUUCNMwChOF3BGPQk+kCPoLwfB WAWT71eDeaLMgcL9zybOc6kn3yYfh5pxX2NLkAZCt.4jA0qVgddime0ek9bp Ba.6erkg.6eskDxeP1BgLDReAhyKIhhX8jyVMgJKabQBNqYzEcv8RMAiZB6y KHOlmnXzs.55erYR7+hefx.e0BQHcGAb.NxIU71y6etJsThXYf7DkBl3wWgm XOC77vgVpC1WxdQI2vSEK1LC91csN0ynlOTzfDW9LRoWwiJOZMzCxXg.xrxZ Tz7JaZZH0kQTVIRAyo6+9lJGUt9tg9J15xzMgp5Vq.uFWMCWwIzFu5tlmbCL fOIKCSMYeAIaES3j0RXGA5LXEEuycqcEIm9D.mLIE0WI4NoRBdBIEOoJZdOf T3jpH+9D1lTEE1inl+vTj27.4T20+aDA2pZVZdPjZ9J0EEsW2ig6.6kk2tGD LoLU9R6eoRRbvmy9OrvnShN -----------end_max5_patcher-----------
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
To reset the behavior, you have to open myBpatch.maxpat, and retype
the coll name so that it gets rebuilt from scratch
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.
if you have steps to reproduce, feel free to post.
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.
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?
Forums > MaxMSP