[L2Ork-dev] preset_hub isues/questions

[Ivica Ico Bukvic]

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 just committed an update to the github that implements ability to use 
$1 args for hubs and nodes. 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!

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

Best wishes,

Ico