Enrique Erne wrote:

i hacked together a ssssad (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 :-)

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.

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__

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

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;

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

HI Frank,

So in a nutshell, what is different about this? I got a bit lost
following this thread :)

best wishes

ps. Hans - will this be included in the release of 0.40.3?

On 27 Jul 2008, at 11:54, Frank Barknecht wrote:

Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:

...

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.

Okay, I commited this now with a bit of cosmetics and to include the fix reported by hard off regarding empty lists. New version also is attached for your convenience. Anyone using sssad.pd: Please test!

Ciao

Frank Barknecht _
______footils.org__ <sssad.pd>_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Frank Barknecht wrote:

It should behave just as before except for one thing: Sending a "set" to SSSAD_ADMIN or sending a "bang" into the first inlet of a [sssad] object will never output a single bang on the [sssad]'s outlet. So uninitialized [sssad] objects where just an empty list is stored will stay silent until they receive some valid data.

just a small remark about uninitialized [sssad] instances:

scenario:

[sssad vol] [sssad freq]

change freq and save a preset XYZ SSSAD_ADMIN: list persist freq 21 SSSAD_ADMIN: list persist vol (note vol has no value!)

a week later in a live session.. the vol now has been changed and doesn't have its default value. let's say it's 0.

now load preset XYZ loading meaning something like the following: |; / |SSSAD vol, freq 64; | |SSSAD_ADMIN set \

now vol will output nothing and [sssad vol] will be empty. but the object that gets the value from vol remains on 0, which was the last value set. the problem is that the preset doesn't sound the same as one week before.

thus) i think sssad behaves correct. i think this problem is the usage of uninitialized [sssad] objects. IMO a patch developer should care to always store key _with_ values. therefore i suggest to always initialize all sssad keys in your abstraction or patch. maybe like that:

[loadbang] | |; / |SSSAD vol 73, freq 64; | |SSSAD_ADMIN set \

a different approach could be an empty symbol, but i don't like that. also one could check all values when loading a preset and checking for empty values but that's really ugly too.

now the point why i write this email: it would be nice to have a little note in sssad-help that says "initializing is strongly recommended" or similar.

what do you think?

eni

frank: it's very nice that you mention me thanks, but i am also fine without, it was more a rearrangement of existing code. if you have a changelog it'd be happy there. otherwise you can remove it whenever you want.

thanks

Hi Frank Barknecht wrote:

Enrique Erne hat gesagt: // Enrique Erne wrote:

...

now the point why i write this email: it would be nice to have a little note in sssad-help that says "initializing is strongly recommended" or similar.

Hm, probably [sssad] should get a [route bang] after the [route save] as well to prohibit saving parameters that haven't been initialized - similar to the protection of the outlet. I attached a version which has this with a little demo patch.

That looks great. Still, personally I will initialize all keys, this guarantees to always have complete presets.

[loadbang] | [; SSSAD vol 20, freq 42, other 1.2345(

An other minor issue:

In my post before I wrote to do [SSSAD_ADMIN set( on load, but on a second thought this is not good practice. It would force all SSSAD to output their value, even other already existing patches.

Basically i would like it if there was a possibility to let some SSSAD instances in a new patch output the value. Attached SSSAD has a possible solution.

case 1) ___________________________________

  [sssad vol]
   |

[*~ 0.5]

Here SSSAD would not be initialized.

case 2) ___________________________________

[loadbang] | [; SSSAD vol 0.5(

  [sssad vol]
   |

[*~ 0.5]

Here all is good except i don't want to write the value twice.

case 3) ___________________________________

[loadbang] | [; SSSAD vol 0.5(

  [sssad vol]
 /

[*~]

*~ is missing the init value. It would work with [SSSAD_ADMIN set( but then all SSSAD's will output their value. That seems wrong.

case 4) ___________________________________

[loadbang] | [; SSSAD vol 0.5, vol bang(

  [sssad vol]
 /

[*~]

How about something like that? [SSSAD vol bang( could be used to specify one key to output it's value. One more [route bang] would be required.

One could argue [SSSAD vol bang( should delete the value, but i can't think of a use of having a key without value.

In attached SSSAD i have 2 minor changes.

A [route bang] to

• output a specific key

(i like that change a lot and see no problem)

$1 in [route save $1] to

• save a specific key

(this is not a clean solution and doesn't work when with [sssad save] instance, but it would allow to collect specific data)

wow pretty long email for such a minor thing. thanks for having a look at it :)

eni

#N canvas 282 224 783 400 10; #X floatatom 130 69 5 0 0 0 - - -; #X floatatom 138 102 5 0 0 0 - - -; #X obj 594 192 list prepend add; #X obj 594 218 list trim; #X obj 438 267 s SSSAD_ADMIN; #X obj 594 124 r SSSAD_ADMIN; #X obj 594 168 route persist; #X obj 594 146 list trim; #X msg 438 201 save; #X msg 452 240 set; #X obj 438 63 bng 24 250 50 0 empty empty save_all 0 -6 0 8 -262144 -1 -1; #X msg 594 258 other-patch 8 ; freq 12 ; vol 11 ;; #X obj 438 134 t b b; #X msg 470 167 set; #X obj 57 66 sssad vol; #X obj 56 157 loadbang; #X floatatom 192 289 5 0 0 0 - - -; #X msg 57 180 ; SSSAD vol 11 , vol bang ; SSSAD freq 12 , freq bang; #X obj 290 59 bng 24 250 50 0 empty empty save_this_patch 0 -6 0 8 -262144 -1 -1; #X obj 285 104 t b b; #X msg 319 128 set; #X obj 58 101 sssad freq; #X obj 72 288 sssad other-patch; #X msg 281 156 ; SSSAD_ADMIN vol , freq; #X connect 0 0 14 1; #X connect 1 0 21 1; #X connect 2 0 3 0; #X connect 3 0 11 0; #X connect 5 0 7 0; #X connect 6 0 2 0; #X connect 7 0 6 0; #X connect 8 0 4 0; #X connect 9 0 4 0; #X connect 10 0 12 0; #X connect 12 0 8 0; #X connect 12 1 13 0; #X connect 13 0 11 0; #X connect 14 0 0 0; #X connect 15 0 17 0; #X connect 16 0 22 1; #X connect 18 0 19 0; #X connect 19 0 23 0; #X connect 19 1 20 0; #X connect 20 0 11 0; #X connect 21 0 1 0; #X connect 22 0 16 0;

#N canvas 58 42 1019 539 10; #X obj 123 24 inlet; #X obj 197 130 r SSSAD; #X obj 197 87 s SSSAD; #X obj 197 53 list prepend $1; #X obj 197 158 list trim; #X obj 197 23 inlet; #X obj 16 258 r SSSAD_ADMIN; #X obj 16 306 b; #X obj 16 284 route set; #X obj 123 51 b; #X obj 197 221 route $1; #X obj 574 442 s SSSAD_ADMIN; #X obj 507 156 r SSSAD_ADMIN; #X obj 507 304 b; #X obj 507 248 spigot; #X obj 633 70 loadbang; #X obj 633 248 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 633 93 value $1.SSSAD.req; #X obj 633 192 select 0; #X obj 665 139 + 1; #X obj 665 162 value $1.SSSAD.req; #X obj 633 118 t a a; #X obj 633 214 f 1; #X obj 190 420 outlet; #X obj 123 394 route bang; #X text 207 393 filter out empty lists; #X obj 574 412 list prepend persist $1; #X obj 123 365 list append; #X text 195 108 on SSSAD we eavesdrop the communication; #X text 656 247 <- only the first instance responds to "save"; #X text 129 498 2007/2008 fbar; #X text 780 93 Enhancement by Enrique Erne; #X obj 507 363 list append; #X obj 507 386 route bang; #X text 591 385 filter out empty lists here , too.; #X obj 196 249 route bang; #X obj 507 275 route save $1; #X text 266 240 to output a specific key; #X text 539 297 dol1 to save a specific key; #X connect 0 0 9 0; #X connect 1 0 4 0; #X connect 3 0 2 0; #X connect 4 0 10 0; #X connect 5 0 3 0; #X connect 6 0 8 0; #X connect 7 0 27 0; #X connect 8 0 7 0; #X connect 9 0 27 0; #X connect 10 0 35 0; #X connect 12 0 14 0; #X connect 13 0 32 0; #X connect 14 0 36 0; #X connect 15 0 17 0; #X connect 17 0 21 0; #X connect 18 0 22 0; #X connect 19 0 20 0; #X connect 21 0 18 0; #X connect 21 1 19 0; #X connect 22 0 14 1; #X connect 22 0 16 0; #X connect 24 1 23 0; #X connect 26 0 11 0; #X connect 27 0 24 0; #X connect 32 0 33 0; #X connect 33 1 26 0; #X connect 35 0 27 0; #X connect 35 1 27 1; #X connect 35 1 32 1; #X connect 36 0 13 0; #X connect 36 1 13 0;

Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:

In the near future there will be some more SSSAD_ADMIN messages I'd like to support: "setlocal" and "savelocal" to save to receivers called "$2-SSSAD_ADMIN" where $2 will usually be the parent's $0, to allow saving of all/some [sssad]s with canvas-local scope.

Okay, the future is here: I took a different approach after looking though my old notes to make it possible to use [sssad] for local parameter saving and loading

Attached [sssad-l] is compatible to normal [sssad] (but requires at a Pd with $1-$2 expansion). What's new: It also accepts a second argument which should be a number (designed for $0). If this number is 0 or missing, everything is as before.

If $2 is different from 0, the global senders and receivers SSSAD and SSSAD_ADMIN are *deactivated* completely and replaced by $2-SSSAD and $2-SSSAD_ADMIN.

sssad-l-test.pd includes some tests for this and also an example, how this change can be used for local parameter handling. Comments welcome.

Ciao

Frank Barknecht _ ______footils.org__

Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:

Is there any reason specifically to only accept numbers?

Actually no. ;)

I replaced [f $2] with [list append $2] in my copy as well now and committed the new patches to the SVN with an extended help-file. Note to all SSSAD-users: The new version (revision 10231 on SF-SVN) now requires pd 0.40 and up.

This seems to be a major release and people can call it SSSAD 2.0, if they like. I don't plan any new features for now (unless Pd suddenly gets a closebang).

I'm looking forward to patches built surrounding sssad.pd, which as you know deliberatly leaves out the actual state saving. It shouldn't be too hard for example to write a commun.pd wrapper now so that Memento-patches can be converted to sssad without too much trouble or to decorate sssad.pd with OSC-like pattern matching.

Ciao

Frank Barknecht _ ______footils.org__

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;

On Fri, 2008-07-25 at 10:16 +0200, Ico Doornekamp wrote:

Hello,

I'm looking for an object that sends outs a ramp and starts over from zero every audio block; is such a thing available or can it be constructed using other objects ? I'm not able to get this tight timing mixing messages and audio, especially on larger block sizes.

Thanks

[bang~] | [0, <endvalue> <blocksize_in_ms>( | [vline~]

roman

___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

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__