Re: [PD] sssad slowness
Frank Barknecht wrote: Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote: additionally i created a new [sssad key] on the fly. this one has now thanks to the original method (of singleton) no initial first setting. ...but if created on the fly it does not have the correct content. --but the original sssad has the same problem afaik. Yes, that's true, but IMO it's not a big problem: Just press set twice. ;) surely no problem for me. (The known bigger problem is that deleting the first [sssad key] will break all other [sssad key] until you reload the patch. i had an idea about that. in the last version every sssad instance stores the content. this was not on purpose but it could be used to do a check on the event of saving. the loadband event is now exchanged and the check is when the user does the save. one disadvantage is that there is more sssad communication everytime a user saves. not sure if you want to go that way. please check the attached version. eni #N canvas 267 25 801 443 10; #X obj 133 24 inlet; #X obj 133 387 outlet; #X obj 133 315 list; #X obj 156 131 r SSSAD; #X obj 198 96 s SSSAD; #X obj 198 64 list prepend \$1; #X obj 156 159 list trim; #X obj 198 24 inlet; #X obj 36 218 r SSSAD_ADMIN; #X obj 36 276 b; #X obj 36 248 route set; #X obj 133 51 b; #X obj 156 222 route \$1; #X obj 286 311 list; #X obj 286 382 s SSSAD_ADMIN; #X obj 286 131 r SSSAD_ADMIN; #X obj 286 239 spigot; #X obj 619 226 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 600 77 value \$1.SSSAD.req; #X obj 600 137 select 0; #X obj 600 167 f 1; #X obj 286 341 list prepend persist \$1; #X obj 286 169 route save; #X obj 286 199 t b b; #X msg 509 303 0; #X obj 482 357 s \$1.SSSAD.ask; #X obj 600 107 t a b; #X obj 509 328 value \$1.SSSAD.req; #X obj 599 46 r \$1.SSSAD.ask; #X obj 482 279 t b b; #X obj 685 101 + 1; #X obj 600 191 t a; #X text 642 225 - boss?; #X connect 0 0 11 0; #X connect 2 0 1 0; #X connect 3 0 6 0; #X connect 5 0 4 0; #X connect 6 0 12 0; #X connect 7 0 5 0; #X connect 8 0 10 0; #X connect 9 0 2 0; #X connect 10 0 9 0; #X connect 11 0 2 0; #X connect 12 0 2 1; #X connect 12 0 13 1; #X connect 13 0 21 0; #X connect 15 0 22 0; #X connect 16 0 13 0; #X connect 18 0 26 0; #X connect 19 0 20 0; #X connect 20 0 31 0; #X connect 21 0 14 0; #X connect 22 0 23 0; #X connect 23 0 16 0; #X connect 23 1 29 0; #X connect 24 0 27 0; #X connect 24 0 31 0; #X connect 26 0 19 0; #X connect 26 1 30 0; #X connect 28 0 18 0; #X connect 29 0 25 0; #X connect 29 1 24 0; #X connect 30 0 18 0; #X connect 31 0 16 1; #X connect 31 0 17 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
Hallo, thanks for your effort. Enrique Erne hat gesagt: // Enrique Erne wrote: i had an idea about that. in the last version every sssad instance stores the content. this was not on purpose but it could be used to do a check on the event of saving. the loadband event is now exchanged and the check is when the user does the save. one disadvantage is that there is more sssad communication everytime a user saves. not sure if you want to go that way. That's an interesting idea. I don't think, the added communication overhead would be that bad, but in my quick tests I found another problem (which may be possible to solve): Say you have a [sssad A] watching a numberbox, then you change it, so that e.g. A = 100. If you then add another [sssad A] by duplicating the first, it is initialised to A = 0. This second A = 0 will overwrite the A = 100 if you press [set( See attachement. With the older [sssad], the 100 will be kept and on set will initialize the new A = 0 with A = 100. I think, that's the better behaviour. Hm, tricky ... ;) Ciao -- Frank Barknecht _ __footils.org__ reset-test.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
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]. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote: Shouldn't you and sssad's author (Chris?) get together and merge these improvements into sssad? See my other mail. It's not an improvement but a feature removal. Btw.: You can store other things than numbers in sssad. Try storing a list, then you don't need that many sssad objects. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
On Wed, Jul 23, 2008 at 07:45:38AM +0200, Atte André Jensen wrote: Wow. Loads in no time (1 sec), and works perfectly. I had problems with somethings not being restored, but I was relying on $0 as unique identifier in those areas, so maybe that's what bid me. Shouldn't you and sssad's author (Chris?) get together and merge these That's Frank, not me. sssad does not cause any loading slowdowns on my system (Vanilla Pd, not pd-extended - if that makes any difference). Best, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
Chris McCormick wrote: That's Frank, not me. Oops... sssad does not cause any loading slowdowns on my system (Vanilla Pd, not pd-extended - if that makes any difference). It might. I'm leaving for hollidays in a few hours, but when I get back, I might try a regular PD install. -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
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. please check. eni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
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
Re: [PD] sssad slowness
Enrique Erne wrote: 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. one thing i noticed is that your version does not work on the fly, everything works fine wwhen you open a new patch containing 2 instances of [sssad key]. however, it doesn't always work so like this. e.g.: if i create a new [sssad key] object it will be first (toggle on) if i create another [sssad key] object, it will be first again! (toggle on). i haven't done any functional tests. fmg,af IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
IOhannes m zmoelnig wrote: Enrique Erne wrote: 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. one thing i noticed is that your version does not work on the fly, everything works fine wwhen you open a new patch containing 2 instances of [sssad key]. however, it doesn't always work so like this. e.g.: if i create a new [sssad key] object it will be first (toggle on) if i create another [sssad key] object, it will be first again! (toggle on). good to know. i now removed my system (with r and s) and replaced it with the singleton's method with [value]. good thing it now has the same name as before ($1.SSSAD.req). i repeated my test 1 - 3 from before. it seems all correct. additionally i created a new [sssad key] on the fly. this one has now thanks to the original method (of singleton) no initial first setting. ...but if created on the fly it does not have the correct content. --but the original sssad has the same problem afaik. attached is the the latest sssad, please test. eni #N canvas 267 25 773 461 10; #X obj 153 54 inlet; #X obj 153 417 outlet; #X obj 153 395 list; #X obj 176 161 r SSSAD; #X obj 218 134 s SSSAD; #X obj 218 112 list prepend \$1; #X obj 176 189 list trim; #X obj 218 54 inlet; #X obj 56 308 r SSSAD_ADMIN; #X obj 56 356 b; #X obj 56 334 route set; #X obj 153 81 b; #X obj 176 252 route \$1; #X obj 191 282 s \$0-sssad-data; #X obj 372 302 list; #X obj 372 362 list prepend \$1; #X obj 372 389 list prepend persist; #X obj 372 412 s SSSAD_ADMIN; #X obj 372 190 r SSSAD_ADMIN; #X obj 372 236 route save; #X obj 372 258 b; #X obj 395 279 r \$0-sssad-data; #X obj 372 212 spigot; #X obj 550 98 loadbang; #X obj 549 281 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X text 572 280 - first?; #X obj 550 121 value \$1.SSSAD.req; #X obj 550 220 select 0; #X obj 582 167 + 1; #X obj 582 190 value \$1.SSSAD.req; #X obj 550 146 t a a; #X obj 550 242 f 1; #X connect 0 0 11 0; #X connect 2 0 1 0; #X connect 3 0 6 0; #X connect 5 0 4 0; #X connect 6 0 12 0; #X connect 7 0 5 0; #X connect 8 0 10 0; #X connect 9 0 2 0; #X connect 10 0 9 0; #X connect 11 0 2 0; #X connect 12 0 2 1; #X connect 12 0 13 0; #X connect 14 0 15 0; #X connect 15 0 16 0; #X connect 16 0 17 0; #X connect 18 0 22 0; #X connect 19 0 20 0; #X connect 20 0 14 0; #X connect 21 0 14 1; #X connect 22 0 19 0; #X connect 23 0 26 0; #X connect 26 0 30 0; #X connect 27 0 31 0; #X connect 28 0 29 0; #X connect 30 0 27 0; #X connect 30 1 28 0; #X connect 31 0 22 1; #X connect 31 0 24 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote: i now removed my system (with r and s) and replaced it with the singleton's method with [value]. good thing it now has the same name as before ($1.SSSAD.req). i repeated my test 1 - 3 from before. it seems all correct. additionally i created a new [sssad key] on the fly. this one has now thanks to the original method (of singleton) no initial first setting. ...but if created on the fly it does not have the correct content. --but the original sssad has the same problem afaik. attached is the the latest sssad, please test. Thanks a lot. This looks good in my quick test and also more simple and elegant than the dynamic patching (which I wasn't too happy with anyway). I'll do some more tests after work, but it seems now all is as with singleton and if it indeed is, I'd like to include your change. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote: additionally i created a new [sssad key] on the fly. this one has now thanks to the original method (of singleton) no initial first setting. ...but if created on the fly it does not have the correct content. --but the original sssad has the same problem afaik. Yes, that's true, but IMO it's not a big problem: Just press set twice. ;) (The known bigger problem is that deleting the first [sssad key] will break all other [sssad key] until you reload the patch. It will be fixed as soon as Pd gets a closebang.) Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
Frank Barknecht wrote: I'll do some more tests after work, but it seems now all is as with singleton and if it indeed is, I'd like to include your change. that would be very nice. i suppose we could make it also a tiny bit lighter (reducing objects) on cost of readability. but maybe only 1 or 2 connections would cross. eni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] sssad slowness
Hi Ok, so I'm playing with sssad, and it's really easy to work with. I saved some of the settings in my environment (a sssad save is here: http://atte.dk/download/test_alive.txt). Loading/saving the state itself is snappy, but loading the main patch is really slow (hogs the machine for 15 seconds, before the load is complete). With plans to add more things to the state, I figure something else must be done. So: 1) Is this normal behaviour of sssad? 2) Should I change something in my setup (backend, ramdisk)? I guess this is not is the part of the problem since loading a state is fast but regular load of the sssad-enabled patch is sloow, but what do I know... 3) Is something broken in my sssad install? I had problems, that I solved by moving sssad* to /usr/lib/pd/extra/ (from /usr/lib/pd/extra/sssad/), but that might have left some badness behind. BTW: sssad-example, (from which I copied stuff) also loads quite slow, maybe 2-3 seconds. -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
hi Atte i'm pretty sure it's the singleton it dynamically creates stuff onload. i hacked together a ad (slim super simple state saving system) uhm what was the a and the d in the abbreviation for? Atte would you mind and test my version? please test for functionality and loading time. i might have overseen something. good luck eni (i removed the singleton and included persistence) Atte André Jensen wrote: Hi Ok, so I'm playing with sssad, and it's really easy to work with. I saved some of the settings in my environment (a sssad save is here: http://atte.dk/download/test_alive.txt). Loading/saving the state itself is snappy, but loading the main patch is really slow (hogs the machine for 15 seconds, before the load is complete). With plans to add more things to the state, I figure something else must be done. So: 1) Is this normal behaviour of sssad? 2) Should I change something in my setup (backend, ramdisk)? I guess this is not is the part of the problem since loading a state is fast but regular load of the sssad-enabled patch is sloow, but what do I know... 3) Is something broken in my sssad install? I had problems, that I solved by moving sssad* to /usr/lib/pd/extra/ (from /usr/lib/pd/extra/sssad/), but that might have left some badness behind. BTW: sssad-example, (from which I copied stuff) also loads quite slow, maybe 2-3 seconds. #N canvas 267 25 728 505 10; #X obj 153 54 inlet; #X obj 153 417 outlet; #X obj 153 395 list; #X obj 176 161 r SSSAD; #X obj 218 134 s SSSAD; #X obj 218 112 list prepend \$1; #X obj 176 189 list trim; #X obj 218 54 inlet; #X obj 56 308 r SSSAD_ADMIN; #X obj 56 356 b; #X obj 56 334 route set; #X obj 153 81 b; #X obj 176 252 route \$1; #X obj 191 282 s \$0-sssad-data; #X obj 372 302 list; #X obj 372 362 list prepend \$1; #X obj 372 389 list prepend persist; #X obj 372 412 s SSSAD_ADMIN; #X obj 372 190 r SSSAD_ADMIN; #X obj 372 236 route save; #X obj 372 258 b; #X obj 395 279 r \$0-sssad-data; #X obj 372 212 spigot; #X obj 508 154 loadbang; #X obj 508 208 f 1; #X obj 540 258 sel 1; #X obj 525 182 r SSSAD_\$1.test; #X obj 540 303 s SSSAD_\$1.test; #X obj 540 279 f 0; #X obj 508 234 t a a; #X obj 526 338 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X text 549 337 - first?; #X connect 0 0 11 0; #X connect 2 0 1 0; #X connect 3 0 6 0; #X connect 5 0 4 0; #X connect 6 0 12 0; #X connect 7 0 5 0; #X connect 8 0 10 0; #X connect 9 0 2 0; #X connect 10 0 9 0; #X connect 11 0 2 0; #X connect 12 0 2 1; #X connect 12 0 13 0; #X connect 14 0 15 0; #X connect 15 0 16 0; #X connect 16 0 17 0; #X connect 18 0 22 0; #X connect 19 0 20 0; #X connect 20 0 14 0; #X connect 21 0 14 1; #X connect 22 0 19 0; #X connect 23 0 24 0; #X connect 24 0 29 0; #X connect 25 0 28 0; #X connect 26 0 24 1; #X connect 28 0 27 0; #X connect 29 0 22 1; #X connect 29 0 30 0; #X connect 29 1 25 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sssad slowness
Enrique Erne wrote: i hacked together a ad (slim super simple state saving system) uhm what was the a and the d in the abbreviation for? Hmmm. Hacked... Atte would you mind and test my version? please test for functionality and loading time. i might have overseen something. Wow. Loads in no time (1 sec), and works perfectly. I had problems with somethings not being restored, but I was relying on $0 as unique identifier in those areas, so maybe that's what bid me. Shouldn't you and sssad's author (Chris?) get together and merge these improvements into sssad? I mean, I have no idea how much tape and chewinggum you used in your code, but it sure works :-) -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
