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