Enrique Erne wrote:
Frank Barknecht wrote:
Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote:
i'm pretty sure it's the singleton it dynamically creates stuff onload.
The singleton is needed to filter out duplicate keys-value-pairs, which is necessary as sssad was designed to also work with sequential containers like textfile or message boxes, but only with hash-type containers like [pool].
So [sssad] cannot remove the [singleton].
Hi Frank
sorry i was not very specific. in fact i did replace the singleton with a little mechanism onload that checks if it is the first and opens up the spigot. all other instances with the same key, that load after the first, wont open the spigot.
i think it behaves the same. please check the sssad-help and see inside the toggle []<-first
my naming is probably bad but if there are no other problems and you approve it would be nice if you could include it into the main version.
i did some testing with sssad-help.pd and the modified sssad.
- inside the [sssad key] only the first (most top) instance of sssad
has the active toggle. i guess that's due to creation order.
- [pd SSAD-globals] set->SSSAD_ADMIN prints
@key_3: 7 @key_2: 7 @key_1: 7
- [pd SSAD-globals] activate SSSAD_ADMIN then save->SSSAD_ADMIN prints
SSSAD_ADMIN: save SSSAD_ADMIN: list persist key 7
i think that is the correct behavior. the only thing that bothers me is the naming. maybe it would be better to replace the mechanism with the original. value $1.SSSAD.req +1 sel 0 etc.
what do you think?
eni