<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">

<div class="im">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>I just committed an update to the github that implements ability to use $1 args for hubs and nodes.<div><br></div><div>Cool and thanks! Haven't tested it yet, but will soon.<br></div><div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 The updated also helped identify a bug where embedded hub/node pairs 
failed to pair correctly and therefore any presets stored with such 
abstractions would fail to work. Hope that helps!</blockquote><div><br></div></div>Yes,
 I saw the problem but didn't want to report before the $1 issue is 
resolved. I'll test this thoroughly because what I need is that I can 
place nodes and their hubs virtually anywhere (inside/outside subpatches
 or abstractions, even rather "far" from each other).</div></div></div></div></blockquote></div></div></blockquote><div>Did some testing and we're almost where I wish to be (if ever possible). What doesn't work right now is a scenario where I have the hub in abstraction A and its nodes in abstraction B, and A and B are embedded on the same canvas (C). Both A and B get their scope symbol from the abstractions' arguments. Something like this:<br>

</div><div>[mysequencertrack track0 scope0]<br>[mysequencertrack track1 scope0]<br>[mysequencertrack track2 scope0]<br>[mypresetsaver scope0]<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div bgcolor="#FFFFFF" text="#000000"><div class="im"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
              <div>
                <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote>
              </div>
              I should also correct my previous statement in that having
              presets renumbered could potentially (likely) wreak havoc
              in respect to the rest of the patch as the preset model is
              number-dependent. Having said that, please convince me
              otherwise and I may consider implementing renumber
              feature, although it seems to me the coll solution should
              work just as well. Let me know.<br>
            </blockquote>
            <div><br>
            </div>
            <div>Well, coll is a swiss army knife that includes a
              machine gun and other handy tools :)<br>
            </div>
            <div>I'd rather keep my presets in sync with something more
              basic like a list.When an item from a list is deleted,
              indexes naturally shift. <br>
            </div>
            <div>(I guess there might be different use cases why someone
              wants to keep their presets in sync with something else;
              mine is keeping preset names, and to eventually feed them
              to a popup menu.)<br>
              Then, if presets get cleared but never deleted, one will
              either have to reuse existing preset slots (complicated
              task when you want to keep the whole thing in sync with
              something) or indexes will reach the sky (which doesn't
              necessarily impose a practical problem but architecturally
              it's something dangerous) and you still cannot spare
              keeping track of those cleared slots.<br>
            </div>
            <div>So, in order for preset_hub to be easily cooperate with
              list-based, list-behaving objects I suggest that beside
              the "clear" method there be a "delete" method which shifts
              the index numbers so they are always continuous.<br>
            </div>
            <div><br>
            </div>
            <div>Thanks a Lot,<br>
            </div>
            <div> </div>
          </div>
          András</div>
      </div>
    </blockquote></div>
    OK, you convinced me (not that it was that hard to do so :-).</div></blockquote><div><br></div><div>I'll take any future blame :o)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div bgcolor="#FFFFFF" text="#000000"> So,
    the updated git now has a new preset_hub and updated documentation,
    including aforesaid bug fix, some other minor fixes in terms of
    missing output from the preset_hub (e.g. when a store fails due to
    the fact that preset numbers must be >= 0), and most importantly
    new "sort n" message where n means the new starting number. All
    presets are therefore sorted according to this starting value and go
    up from there by one. If n is not given, sort defaults to 0.<br>
    </div></blockquote><div bgcolor="#FFFFFF" text="#000000"> <br></div><div bgcolor="#FFFFFF" text="#000000">Wonderful, and thanks a lot! Will test this soon...<br></div><div bgcolor="#FFFFFF" text="#000000"><br>András
</div></div></div></div>