<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 12, 2013 at 2:48 AM, Ivica Ico Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 08/11/2013 01:52 PM, Ivica Ico Bukvic wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/11/2013 08:53 AM, András Murányi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A couple of things concerning preset_hub:<br>
<br>
- It seems to me that sending "clear n" to preset_hub actually clears two presets, the nth and the n+1st.<br>
</blockquote>
I just tested on the help file and tried hub's clear (which erases the preset as expected), node's clearall (which is synonymous to hub's clear), as well as node's clear (which only erases that node's data at preset n), and they all worked as expected--if you can construct a scenario where this fails without the assumption that preset renumbers presets (which it currently doesn't support), please send it to me so that I can investigate further.<br>

</blockquote></div></blockquote><div><br></div><div>I'm attaching a test patch.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
I just committed an update to the github that implements ability to use $1 args for hubs and nodes.</blockquote><div><br></div><div>Cool and thanks! Haven't tested it yet, but will soon.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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).<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Is it possible (and could you please make it possible) to delete a preset in way that the preset numbers shift accordingly? What I mean is:<br>
preset 0: dog<br>
preset 1: cat<br>
preset 2: bee<br>
preset 3: cow<br>
  upon "delete 1" would become:<br>
preset 0: dog<br>
preset 1: bee<br>
preset 2: cow<br>
(I need this because I name the presets and then feed the names to a popup, so when I delete a preset I need the according element to disappear from the popup, with indexes staying in sync.)<br>
</blockquote>
<br>
I think you are expecting preset to renumber presets (akin to coll object) but I think that is a bad idea as that could wreak havoc in other places where specific value is associated with specific settings (e.g. presets can be connected to [sel n] kinds of scenarios). It seems to me that what you may need is to keep preset numbers associated with names inside coll object, so that way even if you lose order of your presets, coll will keep their names associated with proper values. So, for instance, coll could have a structure:<br>


</blockquote>
<br></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>