hello list, is there is a limit in the number of sssad abstractions that can be used in a patch, im using 50 sssad abstractions in a patch and when i save to a text file my pd crashes(but it still save fine the file), and then when i try to load the textfile- preset it loads fine but i get stack overflow messages, when my patch had 20 sssad abstractions it used to work fine.
why is that? Is the problem the number of sssad abstractions im using?
is there anyway of fixing this? Do anybody have any idea? im using pd extended 0.40.3
many thanks
pun.
Hallo, punchik punchik hat gesagt: // punchik punchik wrote:
hello list, is there is a limit in the number of sssad abstractions that can be used in a patch, im using 50 sssad abstractions in a patch and when i save to a text file my pd crashes(but it still save fine the file), and then when i try to load the textfile- preset it loads fine but i get stack overflow messages, when my patch had 20 sssad abstractions it used to work fine.
why is that? Is the problem the number of sssad abstractions im using?
Could you send an example patch that demonstrates the problem? Generally using 50 sssad's should be fine. For example the s_fm4 from the RjDj library uses 40 sssad's in one object without problems - and I usually use more sssad-enabled objects in paralell to that.
Ciao
Frank
Hi Frank, i discovered that the problem is not something specific in my patch , it also happenes in your sssad-example's patch: if you first load a preset and then you try to save another one it always crashes. So if you first save a preset and then load it , it works fine, but if you want to save a new preset without closing and reopening pd, it crashes, any idea of how to fix this?
thanks
Pun.
--- On Sat, 2/7/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] limit in number of sssad abstraction To: pd-list@iem.at Date: Saturday, February 7, 2009, 8:40 AM Hallo, punchik punchik hat gesagt: // punchik punchik wrote:
hello list, is there is a limit in the number of sssad
abstractions that can be used in a patch, im using 50 sssad abstractions in a patch and when i save to a text file my pd crashes(but it still save fine the file), and then when i try to load the textfile- preset it loads fine but i get stack overflow messages, when my patch had 20 sssad abstractions it used to work fine.
why is that? Is the problem the number of sssad
abstractions im using?
Could you send an example patch that demonstrates the problem? Generally using 50 sssad's should be fine. For example the s_fm4 from the RjDj library uses 40 sssad's in one object without problems
- and I usually
use more sssad-enabled objects in paralell to that.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo Pun,
I really cannot make that patch crash. Maybe you are using some old version of sssad or there is an imcompatibility with sssad and Pd-extended (which I don't use). Anyway I patched a little test patch in the attachement that you just tests saving and loading of many sssad-presets. Can you try this? I can manage many abstractions without crashes.
Ciao
Frnak
punchik punchik hat gesagt: // punchik punchik wrote:
Hi Frank, i discovered that the problem is not something specific in my patch , it also happenes in your sssad-example's patch: if you first load a preset and then you try to save another one it always crashes. So if you first save a preset and then load it , it works fine, but if you want to save a new preset without closing and reopening pd, it crashes, any idea of how to fix this?
thanks
Pun.
--- On Sat, 2/7/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] limit in number of sssad abstraction To: pd-list@iem.at Date: Saturday, February 7, 2009, 8:40 AM Hallo, punchik punchik hat gesagt: // punchik punchik wrote:
hello list, is there is a limit in the number of sssad
abstractions that can be used in a patch, im using 50 sssad abstractions in a patch and when i save to a text file my pd crashes(but it still save fine the file), and then when i try to load the textfile- preset it loads fine but i get stack overflow messages, when my patch had 20 sssad abstractions it used to work fine.
why is that? Is the problem the number of sssad
abstractions im using?
Could you send an example patch that demonstrates the problem? Generally using 50 sssad's should be fine. For example the s_fm4 from the RjDj library uses 40 sssad's in one object without problems
- and I usually
use more sssad-enabled objects in paralell to that.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Frank i was using sssad 0.1 , i updated to the last version from svn and now it works fine without crashes, but im still getting those stack overflow messages, Is there anyway to know where does they come from in pd? how can i know what is causing this?
I was thinking maybe is because im printing all mesages from each sssad at the same time, do you think this can causes this? Other thing i was thinking is that sometimes im using one saddd abstraction for hold 3 variables as in the case of "colorglobal_background: 1 0 0.305085" Is this a good practice ? or is it better to use one sssad object for each variable?
thanksss pun.
here is an example of what im getting:
presetcolortexto: 1 colortextoonofftres: 0 colortextoonoffdos: 1 colortextoonoff: 1 colortextouno: 864.567 iteraciontres: 21 iteraciondos: 20 iteracionuno: 12 colorglobal_background: 1 0 0.305085 coloruno: 0 0 1 colortres: 0.661017 0 1 colordos: 0 0.118644 0.118644 translateuno: 3 3 15 error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow error: stack overflow rotateglobal: -5 138 0 translateglobal: 0 0 -5 translateuno_uno: 10 -11 -16 rotateuno: -12 -70 -72 translatetres_uno: -107 -29 -116 translatetres: -19 51 10 rotatedos_uno: 0 116 0 translatedos_uno: -265 -104 70 rotatedos: 11 -24 0 translatedos: 40 0 0
--- On Sun, 2/8/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] limit in number of sssad abstraction To: pd-list@iem.at Date: Sunday, February 8, 2009, 6:53 AM Hallo Pun,
I really cannot make that patch crash. Maybe you are using some old version of sssad or there is an imcompatibility with sssad and Pd-extended (which I don't use). Anyway I patched a little test patch in the attachement that you just tests saving and loading of many sssad-presets. Can you try this? I can manage many abstractions without crashes.
Ciao
Frnak
punchik punchik hat gesagt: // punchik punchik wrote:
Hi Frank, i discovered that the problem is not
something specific in my patch , it also happenes in your sssad-example's patch: if you first load a preset and then you try to save another one it always crashes. So if you first save a preset and then load it , it works fine, but if you want to save a new preset without closing and reopening pd, it crashes, any idea of how to fix this?
thanks
Pun.
--- On Sat, 2/7/09, Frank Barknecht
fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] limit in number of sssad
abstraction
To: pd-list@iem.at Date: Saturday, February 7, 2009, 8:40 AM Hallo, punchik punchik hat gesagt: // punchik punchik
wrote:
hello list, is there is a limit in the
number of sssad
abstractions that can be used in a patch, im
using 50 sssad
abstractions in a patch and when i save to a
text file my
pd crashes(but it still save fine the file), and
then when i
try to load the textfile- preset it loads fine
but i get
stack overflow messages, when my patch had 20
sssad
abstractions it used to work fine.
why is that? Is the problem the number of
sssad
abstractions im using?
Could you send an example patch that demonstrates
the
problem? Generally using 50 sssad's should be fine. For example
the s_fm4
from the RjDj library uses 40 sssad's in one object without
problems
- and I usually
use more sssad-enabled objects in paralell to
that.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Frank Barknecht Do You RjDj.me? _ ______footils.org__ _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo Pun, punchik punchik hat gesagt: // punchik punchik wrote:
Hi Frank i was using sssad 0.1 , i updated to the last version from svn and now it works fine without crashes, but im still getting those stack overflow messages, Is there anyway to know where does they come from in pd? how can i know what is causing this?
I would guess that these come from message loops somewhere in your patch. With loop I mean some directly connected sends and receives feeding each other like this:
[r LOOP] | | [something( |/ [s LOOP]
Now you would of course never patch something like this directly, but it may be that hidden sends inside of GUI objects are used like this.
You can also easily create a loop with [sssad] if you do the cross-connection to the first inlet of the [sssad] object. It has to go to the *second* inlet to avoid loops. So maybe check all your [sssad] objects if they are connected correctly.
"Find -> Last Error" can give valuable information sometimes. It is able to detect the source of the loop I painted above.
Other thing i was thinking is that sometimes im using one saddd abstraction for hold 3 variables as in the case of "colorglobal_background: 1 0 0.305085" Is this a good practice ? or is it better to use one sssad object for each variable?
No, that's fine in general - I also do it for related settings. Again you have to be careful with loops here - maybe making a [pack 0 0 0] "all hot" with some [t b a] objects is triggering an endless loop here.
Ciao
Frank
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Other thing i was thinking is that sometimes im using one saddd abstraction for hold 3 variables as in the case of "colorglobal_background: 1 0 0.305085" Is this a good practice ? or is it better to use one sssad object for each variable?
No, that's fine in general - I also do it for related settings. Again you have to be careful with loops here - maybe making a [pack 0 0 0] "all hot" with some [t b a] objects is triggering an endless loop here.
Attached is a variation of the previous test patch, now made to save a list: manyssad/test-three.pd
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Quoting "Frank Barknecht" fbar@footils.org:
Hallo Pun, punchik punchik hat gesagt: // punchik punchik wrote:
Now you would of course never patch something like this directly, but it may be that hidden sends inside of GUI objects are used like this.
the iemguis are usually protected internally against such loops.
(that is: if you assign the same send/receive name in e.g. a fader,
this fader will not send (nor iirc, output) the values it receives)
this protectio is turned of, if the send/receive names are different.
fgmasr IOhannes
This message was sent using IMP, the Internet Messaging Program.
Hallo, zmoelnig@iem.at hat gesagt: // zmoelnig@iem.at wrote:
Quoting "Frank Barknecht" fbar@footils.org:
Hallo Pun, punchik punchik hat gesagt: // punchik punchik wrote:
Now you would of course never patch something like this directly, but it may be that hidden sends inside of GUI objects are used like this.
the iemguis are usually protected internally against such loops. (that is: if you assign the same send/receive name in e.g. a fader,
this fader will not send (nor iirc, output) the values it receives)
Yeah, and that's very useful. I'd suggest to make the atoms for numbers and symbols behave the save.
Still because GUI receivers are "hidden" it's still easy to patch something with a loop when using explicit receivers, and it's even easier with sssad because that also includes hidden receivers.
Ciao
Frank
-
Frank Barknecht -
punchik punchik -
zmoelnig＠iem.at