Bug Report [Web] : Pattrstorage patcher name update bug?


    Feb 02 2006 | 12:05 am
    userEmail :: ------------------ lists@lowfrequency.org
    bugHeader :: ------------------ Pattrstorage patcher name update bug?
    bugSummary :: ------------------ Pattrstorage's [storagewindow] and [clientwindow] commands show a list of the attached pattr objects, grouped by the subpatches they reside in (1 level down). When you rename those subpatches in the max patch, the patcher names in the pattrstorage client and storage windows do not update.
    bugStepsReproduce :: ------------------ Take the included patch - see that the names listed in the pattrstorage client/storage windows do not match the subpatcher names (p coloring, p subpatch01, p render-params). Change the subpatcher names and note that pattrstorage does not update these names in the client/storage window. Also, select the pattrstorage object and subpatches, copy them, and paste them into a new patch - the incorrect names still won't change.
    bugExpectedResults :: ------------------ I expected the names listed in the client/storage window to update when I change the names of subpatchers containing pattr objects linked to a pattrstorage object.
    bugActualResults :: ------------------ The names do not even update.
    bugRegression :: ------------------ None.
    bugNotes :: ------------------ Example patch:

    • Feb 04 2006 | 11:53 am
      If you change the >>patcher name<< of the subpatcher (e.g. Object- >Name...), the name properly updates. However, there is no law that says that the argument or typed-in name of a subpatcher, patcher, poly~ or bpatcher has to be the same as the patchername, especially if the developer explicitly changes it, like you are (I think) doing here.
      The first time a pattr object is created in a subpatcher, it "bubbles up" through the patcher hierarchy, naming any patchers along the way *if they don't already have names*. If they do, they are left alone. This will likely never change, so you just need to be vigilant when retyping boxes, that you rename them, too.
      jb
    • Feb 07 2006 | 12:00 am
      On Feb 4, 2006, at 6:53 AM, Jeremy Bernstein wrote:
      > However, there is no law that says that the argument or typed-in name > of a subpatcher, patcher, poly~ or bpatcher has to be the same as the > patchername, especially if the developer explicitly changes it, like > you are (I think) doing here. >
      Interesting - I have to say that I never realized that the patcher name and it's 1st argument were different.
      Why isn't there such a law? It's the only way that makes sense, to me. Or is there something that I'm missing about the proper use of subpatchers? I was under the impression that typeing [p NAME] was a way to organize your patch. So I have to explicitly re-name my subpatchers with the name message every time I change their 1st argument? I'm a little confused.
      -evan
    • Feb 07 2006 | 12:48 am
      You're not missing anything. It just doesn't work like you think it ought to, which is something that reasonable people can disagree about. It was decided that explicit developer intentions (giving a name, or keeping a name that has been auto-awarded) trumped automatic behavior of objects behind the scenes. If you explicitly change the argument to a subpatcher, you will need to explicitly change its patcher name, too.
      jb
    • Feb 07 2006 | 3:44 am
      I see - thanks for the explanation.
      I can see why it is the way it is, but I can't say that I find it intuitive. FWIW, I vote for a change in this behavior, just for subpatcher objects, so that changing the argument also changes the name. But that's just my 2 cents. The only time its noticeable is with pattrstorage, as far as I've seen, but knowing that i have to explicitly name patchers solves my problem!
      best, evan
    • Feb 14 2006 | 11:03 pm
      Actually, there still is a slight problem. When I change the name of the subpatchers, it deletes all of the stored presets for the pattrs inside them. Is there a way to make it so that pattrstorage can keep the preset data when the patcher name changes?
    • Feb 14 2006 | 11:24 pm
      Not at this time. You can likely edit the XML file directly to deal with this, though.
      jb
    • Feb 15 2006 | 4:25 pm
      ah, ok. i figured it might be a tricky code fix. it's not hard to find/replace in the XML file, though, which is good.
      thanks, evan