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:
    max v2;

    • 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