Re: [PD] limit in number of sssad abstraction
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 BarknechtDo You RjDj.me? _ __footils.org__ manyssad-2.tgz Description: GNU Unix tar archive ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] limit in number of sssad abstraction
Quoting Frank Barknecht f...@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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] limit in number of sssad abstraction
Hallo, zmoel...@iem.at hat gesagt: // zmoel...@iem.at wrote: Quoting Frank Barknecht f...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] limit in number of sssad abstraction
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 f...@footils.org wrote: From: Frank Barknecht f...@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 BarknechtDo You RjDj.me? _ __footils.org__ manyssad.tgz Description: GNU Unix tar archive ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] limit in number of sssad abstraction
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 f...@footils.org wrote: From: Frank Barknecht f...@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 f...@footils.org wrote: From: Frank Barknecht f...@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 BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] limit in number of sssad abstraction
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] limit in number of sssad abstraction
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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] limit in number of sssad abstraction
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
Re: [PD] limit in number of sssad abstraction
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 f...@footils.org wrote: From: Frank Barknecht f...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
