Just an update with a happy ending: it turned out that rc-patches was still in the search path and it indirectly involved an incompatible version of sssad. Removing it from the path fixed the problem. Thanks for the tips, they definitely helped me understand what to look for.
András
On Mon, Jun 24, 2013 at 4:00 PM, András Murányi muranyia@gmail.com wrote:
Ciao Frank,
thanks for the tip. I'm using [presetstore] which writes to [pd presetstore0] (etc...) subpatches. (BTW, latest s-abstractions don't have [presetstore] any more?) I've set up the print on receivers, but I guess placing [r $2-SSSAD_ADMIN] and [r $2-SSSAD] inside the [presetstore] patch was not a good idea because they didn't receive anything (where to put them then?)
The output looks like this: SSSAD: list e5/envelope 4 0 79 68 80 69 47 140 46 SSSAD: list e3/envelope 3 0 80 44 80 140 70 SSSAD: list e2/envelope 4 0 38 61 80 94 40 140 80 SSSAD: list e4/envelope 7 0 80 36 65 55 39 76 70 96 38 113 69 140 80 SSSAD: list e1/envelope 2 0 0 140 80 presetstore saving: presetstore6 SSSAD_ADMIN: save
The other strange sting is that the output only shows the stuff to save for the envelopes which had sssad "built in" (they are based on an older version of [s-env] i think), and no data for the numerous objects for which I have set up sssad myself. They are all calling sssad from the same location however (no directory prefix, just [sssad]), which is, according to my search path, is the sssad in s-abstractions. I'm still lost...
András
On Mon, Jun 24, 2013 at 2:49 PM, Frank Barknecht fbar@footils.org wrote:
Hi,
On Sun, Jun 23, 2013 at 09:42:54PM +0200, András Murányi wrote:
I've been having a problem with SSSAD for a few weeks: it's able to load presets, but when it comes to saving, an empty state is written (i
mean, it
does write but it overwrites the previous content of the preset with nothingness). The example patches don't work either. There are no errors in the console and I have also overwritten the whole SSSAD folder with a newly downloaded one, still no joy. Tested in vanilla and it works.
sssad.pd itself doesn't write anything to disk, so there must be something else that's doing the writing. What sssad does is sending messages to receivers called SSSAD_ADMIN and SSSAD or to semi-global receivers called $2-SSSAD_ADMIN and $2-SSSAD for [sssad] objects with a second argument different from 0.
You can try to read and [print] these receivers to debug if no data is received.
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list