[PD] New sssad.pd now in SVN repository - please test! [was: sssad slowness]
enrique at netpd.org
Mon Jul 28 20:43:27 CEST 2008
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:
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
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:
|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?
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
More information about the Pd-list