[L2Ork-dev] preset_hub isues/questions

[András Murányi]

>
> I just committed an update to the github that implements ability to use $1
> args for hubs and nodes.
>
> Cool and thanks! Haven't tested it yet, but will soon.
>
>
>> 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!
>
>
> 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).
>
> 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:
[mysequencertrack track0 scope0]
[mysequencertrack track1 scope0]
[mysequencertrack track2 scope0]
[mypresetsaver scope0]

>
>    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.
>>
>
>  Well, coll is a swiss army knife that includes a machine gun and other
> handy tools :)
>  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.
>  (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.)
> 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.
>  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.
>
>  Thanks a Lot,
>
>  András
>
> OK, you convinced me (not that it was that hard to do so :-).
>

I'll take any future blame :o)


>  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.
>

Wonderful, and thanks a lot! Will test this soon...

András
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130815/5e0f4964/attachment.html>