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. 1) inside the [sssad key] only the first (most top) instance of sssad has the active toggle. i guess that's due to creation order. 2) [pd SSAD-globals] set->SSSAD_ADMIN prints @key_3: 7 @key_2: 7 @key_1: 7 3) [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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list