On Mon, Jun 24, 2013 at 7:04 PM, Frank Barknecht fbar@footils.org wrote:
On Mon, Jun 24, 2013 at 04:00:15PM +0200, András Murányi wrote:
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?)
sssad-objects created as [sssad something KEY] will send to KEY-SSSAD_ADMIN and KEY-SSSAD, all others will send to SSSAD_ADMIN and SSSAD. To receive from those semi-global [sssad]-objects, you'd need to replace the receivers next to the sssad-objects that use the second argument.
Maybe you can search for "sssad" objects in your patch and try to find some that use second args?
Also the semi-global/local receivers have been added at some time after s-abstractions where born. Although old already, maybe you have a mix of both versions installed now? The old one didn't have any $2-SSSAD senders/receivers inside.
Ciao
Frank Barknecht _ ______footils.org__
Shame on me, i did have two different sssad folders in my path. Now i've cleaned things up and there's only the one from s-abstractions - but that's not the solution yet. I've noticed that s-abstractions dropped [presetstore] and that may have a good reason. Is it possible that it's actually not compatible with current sssad? I've also noticed [saver] in s-abstrations/sssad which seems to be like [presetstore] (except that [presetstore] saved to subpatches while [saver] saves to textfiles). I've tried it and it doesn't work for me: "error: $1state-11.sssad: write failed". (It does create 0-byte files in s-abstrations/sssad though.)
[datastore] however, is still part of s-abstractions (it saves a single state to a subpatch), and it doesn't work here. I tried datastore-help.pd and it saves an empty state. What's interesting, is that if I try it while my other big patch is open, it consistently triggers a segfault.
András
Without seeing your patch this conversation is unfortunately entirely pointless. It could be that you're using a third-party external that somehow trips up and crashes when a pest I'd invoked, fails, and outputs bogus data that makes the external crash and that is something that I cannot even begin to backtrace without knowing exactly what crashed. It could be also that you are as you're suggesting mixing two different versions of preset abstractions which itself appears to be causing some of the problems you're encountering and the list goes on. To begin, you could provide a backtrace of the consistent crash so that we have some idea of what is going on. On Jul 3, 2013 2:36 PM, "András Murányi" muranyia@gmail.com wrote:
On Mon, Jun 24, 2013 at 7:04 PM, Frank Barknecht fbar@footils.org wrote:
On Mon, Jun 24, 2013 at 04:00:15PM +0200, András Murányi wrote:
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?)
sssad-objects created as [sssad something KEY] will send to KEY-SSSAD_ADMIN and KEY-SSSAD, all others will send to SSSAD_ADMIN and SSSAD. To receive from those semi-global [sssad]-objects, you'd need to replace the receivers next to the sssad-objects that use the second argument.
Maybe you can search for "sssad" objects in your patch and try to find some that use second args?
Also the semi-global/local receivers have been added at some time after s-abstractions where born. Although old already, maybe you have a mix of both versions installed now? The old one didn't have any $2-SSSAD senders/receivers inside.
Ciao
Frank Barknecht _ ______footils.org__
Shame on me, i did have two different sssad folders in my path. Now i've cleaned things up and there's only the one from s-abstractions - but that's not the solution yet. I've noticed that s-abstractions dropped [presetstore] and that may have a good reason. Is it possible that it's actually not compatible with current sssad? I've also noticed [saver] in s-abstrations/sssad which seems to be like [presetstore] (except that [presetstore] saved to subpatches while [saver] saves to textfiles). I've tried it and it doesn't work for me: "error: $1state-11.sssad: write failed". (It does create 0-byte files in s-abstrations/sssad though.)
[datastore] however, is still part of s-abstractions (it saves a single state to a subpatch), and it doesn't work here. I tried datastore-help.pd and it saves an empty state. What's interesting, is that if I try it while my other big patch is open, it consistently triggers a segfault.
András
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[...]
[datastore] however, is still part of s-abstractions (it saves a single state to a subpatch), and it doesn't work here. I tried datastore-help.pd and it saves an empty state. What's interesting, is that if I try it while my other big patch is open, it consistently triggers a segfault.
On Wed, Jul 3, 2013 at 9:46 PM, Ivica Bukvic ico@vt.edu wrote:
Without seeing your patch this conversation is unfortunately entirely pointless.
Sorry, the patch is so big I wouldn't dump it on you. Make no mistake, the problem is not happening IN the patch, but in the stock datastore-help.pd MEANWHILE the big patch is open. As soon as I can reproduce the crash synthetically, I'll send an example patch.
It could be that you're using a third-party external that somehow trips up and crashes when a pest I'd invoked, fails, and outputs bogus data that makes the external crash and that is something that I cannot even begin to backtrace without knowing exactly what crashed. It could be also that you are as you're suggesting mixing two different versions of preset abstractions which itself appears to be causing some of the problems you're encountering and the list goes on. To begin, you could provide a backtrace of the consistent crash so that we have some idea of what is going on.
I'm attaching a backtrace. Thanks for taking a look!
András
-
András Murányi -
Ivica Bukvic