[L2Ork-dev] preset_hub isues/questions

[Ivica Ico Bukvic]

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

dog, 0;
cat, 1;
bee, 2;
cow, 3;

and later

dog, 0;
bee, 2;
cow, 3;

Therefore, feeding "bee" into coll will always yield the right value 
when invoked from coll.
> - When I add [preset_hub $1] to an abstraction, save it, close it, and 
> reopen it, "$1" gets replaced by the value, and becomes something like 
> [preset_hub foo]. (It's also visible in the raw source of the 
> abstraction.) I hope this is not by design because I need to reuse the 
> abstraction... :-o
This may be a bug, or more specifically current limitation--thanks for 
reporting it. That said, You can simply give all your abstractions the 
same scope (e.g. [preset_node] without any arguments or with a custom 
one that you plan on using across the entire ecosystem of all your 
patches), and have a preset_hub with the same scope on a parent patch 
that hosts all these abstractions will catch them all, including 
multiple instances of the same abstraction (see K12 mode for examples). 
This allows reusing that is arguably even simpler than what you're 
thinking of, although it does have some limitations (e.g. limits you to 
one scope).

HTH

>
> Thanks,
>
> András
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev


-- 
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20130811/54edd303/attachment.html>