[L2Ork-dev] preset_hub isues/questions

[András Murányi]

On Mon, Aug 12, 2013 at 2:48 AM, Ivica Ico Bukvic <ico at vt.edu> wrote:

> On 08/11/2013 01:52 PM, Ivica Ico Bukvic wrote:
>
>> On 08/11/2013 08:53 AM, András Murányi wrote:
>>
>>> A couple of things concerning preset_hub:
>>>
>>> - It seems to me that sending "clear n" to preset_hub actually clears
>>> two presets, the nth and the n+1st.
>>>
>> 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.
>>
>
I'm attaching a test patch.


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


>
>
>  - 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:
>>> preset 0: dog
>>> preset 1: cat
>>> preset 2: bee
>>> preset 3: cow
>>>   upon "delete 1" would become:
>>> preset 0: dog
>>> preset 1: bee
>>> preset 2: cow
>>> (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.)
>>>
>>
>> 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:
>>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130812/3cb3ad34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: presethub-delete-test.pd
Type: application/octet-stream
Size: 1008 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130812/3cb3ad34/attachment-0001.obj>