Hi thomas, it is easy to build a loop which can crash dyn~, and I wonder if it would be possible to avoid a crash. I use objects, which play for a random anount of time and then they send their id when they're finished and so dyn knows that it is time to delete them. I understand wyy this is a problem, and I also found some sort of work around. but it would be easier if dyn would catch that recursion. any idea? marius.
#N canvas 310 87 250 256 10; #X obj 74 116 symbol $1; #X obj 74 66 loadbang; #X obj 74 89 delay $2; #X obj 74 140 s killme; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0;
#N canvas 639 186 681 434 10; #X obj 527 220 symbol $1; #X obj 527 170 loadbang; #X obj 527 193 delay $2; #X obj 527 244 s killme; #X text 416 126 that is the test abstraction; #X obj 223 194 cnv 15 100 60 empty empty empty 20 12 0 14 -258049 -66577 0; #X obj 86 271 dyn~ 0 0 0 0; #X obj 236 201 r killme; #X msg 236 230 del $1; #X msg 86 90 newobj . a1 test1 a1 2000; #X text 55 50 CAUTION!!! By clicking here , Pd might crash!; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 7 0 8 0; #X connect 8 0 6 0; #X connect 9 0 6 0;
Hi Marius,
it's a problem inherent in PD, which was discussed just a few days
ago. An object can't be deleted when messages sent by it are still
processed.
It's easy to circumvent in your case: Delay the closing just a
bit.... find the attached patch. I don't think this is something that
dyn~ should "fix".
By the way - with your patch attachment you exposed something that
might be considered a pd bug:
Two patches that are pasted into one file will open to canvases, but
pd will crash on every save attempt of it.
all the best, Thomas
Am 25.02.2007 um 21:22 schrieb marius schebella:
Hi thomas, it is easy to build a loop which can crash dyn~, and I wonder if it
would be possible to avoid a crash. I use objects, which play for a random anount of time and then they
send their id when they're finished and so dyn knows that it is
time to delete them. I understand wyy this is a problem, and I also found some sort of
work around. but it would be easier if dyn would catch that recursion. any idea? marius.#N canvas 310 87 250 256 10; #X obj 74 116 symbol $1; #X obj 74 66 loadbang; #X obj 74 89 delay $2; #X obj 74 140 s killme; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #N canvas 639 186 681 434 10; #X obj 527 220 symbol $1; #X obj 527 170 loadbang; #X obj 527 193 delay $2; #X obj 527 244 s killme; #X text 416 126 that is the test abstraction; #X obj 223 194 cnv 15 100 60 empty empty empty 20 12 0 14 -258049
-66577 0; #X obj 86 271 dyn~ 0 0 0 0; #X obj 236 201 r killme; #X msg 236 230 del $1; #X msg 86 90 newobj . a1 test1 a1 2000; #X text 55 50 CAUTION!!! By clicking here , Pd might crash!; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 7 0 8 0; #X connect 8 0 6 0; #X connect 9 0 6 0; _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Thomas Grill http://grrrr.org
Another thing that just came to my mind.... with larger abstractions
you'll probably find that it's not a good idea to allocate voices in
pd with means of scripting, since audio will click (maybe not at
home, but when you are performing).
It's better to pre-allocate a number of voices and do some voice
management, maybe even with switch~ to save CPU.
best greetings, Thomas
Am 25.02.2007 um 22:21 schrieb Thomas Grill:
Hi Marius, it's a problem inherent in PD, which was discussed just a few days
ago. An object can't be deleted when messages sent by it are still
processed. It's easy to circumvent in your case: Delay the closing just a
bit.... find the attached patch. I don't think this is something
that dyn~ should "fix".By the way - with your patch attachment you exposed something that
might be considered a pd bug: Two patches that are pasted into one file will open to canvases,
but pd will crash on every save attempt of it.all the best, Thomas
<crash-070225.pd>
Am 25.02.2007 um 21:22 schrieb marius schebella:
Hi thomas, it is easy to build a loop which can crash dyn~, and I wonder if
it would be possible to avoid a crash. I use objects, which play for a random anount of time and then
they send their id when they're finished and so dyn knows that it
is time to delete them. I understand wyy this is a problem, and I also found some sort of
work around. but it would be easier if dyn would catch that
recursion. any idea? marius.#N canvas 310 87 250 256 10; #X obj 74 116 symbol $1; #X obj 74 66 loadbang; #X obj 74 89 delay $2; #X obj 74 140 s killme; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #N canvas 639 186 681 434 10; #X obj 527 220 symbol $1; #X obj 527 170 loadbang; #X obj 527 193 delay $2; #X obj 527 244 s killme; #X text 416 126 that is the test abstraction; #X obj 223 194 cnv 15 100 60 empty empty empty 20 12 0 14 -258049
-66577 0; #X obj 86 271 dyn~ 0 0 0 0; #X obj 236 201 r killme; #X msg 236 230 del $1; #X msg 86 90 newobj . a1 test1 a1 2000; #X text 55 50 CAUTION!!! By clicking here , Pd might crash!; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 7 0 8 0; #X connect 8 0 6 0; #X connect 9 0 6 0; _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-listThomas Grill http://grrrr.org
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Thomas Grill http://grrrr.org
there are no larger abstractions, and they will all fade in and out softly, and there will be a feedback to the cpu time of the machine, that hopefully will slow down the process of creating new objects until enough of them have died again. thanks anyway! m.
Thomas Grill wrote:
Another thing that just came to my mind.... with larger abstractions you'll probably find that it's not a good idea to allocate voices in pd with means of scripting, since audio will click (maybe not at home, but when you are performing). It's better to pre-allocate a number of voices and do some voice management, maybe even with switch~ to save CPU.
best greetings, Thomas
Am 25.02.2007 um 22:21 schrieb Thomas Grill:
Hi Marius, it's a problem inherent in PD, which was discussed just a few days ago. An object can't be deleted when messages sent by it are still processed. It's easy to circumvent in your case: Delay the closing just a bit.... find the attached patch. I don't think this is something that dyn~ should "fix".
By the way - with your patch attachment you exposed something that might be considered a pd bug: Two patches that are pasted into one file will open to canvases, but pd will crash on every save attempt of it.
all the best, Thomas
<crash-070225.pd>
Am 25.02.2007 um 21:22 schrieb marius schebella:
Hi thomas, it is easy to build a loop which can crash dyn~, and I wonder if it would be possible to avoid a crash. I use objects, which play for a random anount of time and then they send their id when they're finished and so dyn knows that it is time to delete them. I understand wyy this is a problem, and I also found some sort of work around. but it would be easier if dyn would catch that recursion. any idea? marius.
#N canvas 310 87 250 256 10; #X obj 74 116 symbol $1; #X obj 74 66 loadbang; #X obj 74 89 delay $2; #X obj 74 140 s killme; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #N canvas 639 186 681 434 10; #X obj 527 220 symbol $1; #X obj 527 170 loadbang; #X obj 527 193 delay $2; #X obj 527 244 s killme; #X text 416 126 that is the test abstraction; #X obj 223 194 cnv 15 100 60 empty empty empty 20 12 0 14 -258049 -66577 0; #X obj 86 271 dyn~ 0 0 0 0; #X obj 236 201 r killme; #X msg 236 230 del $1; #X msg 86 90 newobj . a1 test1 a1 2000; #X text 55 50 CAUTION!!! By clicking here , Pd might crash!; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 7 0 8 0; #X connect 8 0 6 0; #X connect 9 0 6 0; _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thomas Grill http://grrrr.org
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thomas Grill http://grrrr.org
Am 25.02.2007 um 23:04 schrieb marius schebella:
there are no larger abstractions, and they will all fade in and out
softly, and there will be a feedback to the cpu time of the
machine, that hopefully will slow down the process of creating new
objects until enough of them have died again. thanks anyway!
Fading in and out will only help if there's only one object at a time.
The point is that creating or destroying PD objects or abstractions
cause the DSP chain to be reconstructed, which can cause clicks for
the whole DSP output, not just for the one abstraction loaded. The
larger the abstraction, the longer the loading will take.
T
thanks, I thought, maybe dyn has the power to "remember" that is has to finish the processing line for the particular object, then delete it and then return the ball back to pd without crashing. don't know what you mean with the canvas problem?? m.
Thomas Grill wrote:
Hi Marius, it's a problem inherent in PD, which was discussed just a few days ago. An object can't be deleted when messages sent by it are still processed. It's easy to circumvent in your case: Delay the closing just a bit.... find the attached patch. I don't think this is something that dyn~ should "fix".
By the way - with your patch attachment you exposed something that might be considered a pd bug: Two patches that are pasted into one file will open to canvases, but pd will crash on every save attempt of it.
all the best, Thomas
Am 25.02.2007 um 21:22 schrieb marius schebella:
Hi thomas, it is easy to build a loop which can crash dyn~, and I wonder if it would be possible to avoid a crash. I use objects, which play for a random anount of time and then they send their id when they're finished and so dyn knows that it is time to delete them. I understand wyy this is a problem, and I also found some sort of work around. but it would be easier if dyn would catch that recursion. any idea? marius.
#N canvas 310 87 250 256 10; #X obj 74 116 symbol $1; #X obj 74 66 loadbang; #X obj 74 89 delay $2; #X obj 74 140 s killme; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #N canvas 639 186 681 434 10; #X obj 527 220 symbol $1; #X obj 527 170 loadbang; #X obj 527 193 delay $2; #X obj 527 244 s killme; #X text 416 126 that is the test abstraction; #X obj 223 194 cnv 15 100 60 empty empty empty 20 12 0 14 -258049 -66577 0; #X obj 86 271 dyn~ 0 0 0 0; #X obj 236 201 r killme; #X msg 236 230 del $1; #X msg 86 90 newobj . a1 test1 a1 2000; #X text 55 50 CAUTION!!! By clicking here , Pd might crash!; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 7 0 8 0; #X connect 8 0 6 0; #X connect 9 0 6 0; _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thomas Grill http://grrrr.org
Am 25.02.2007 um 23:01 schrieb marius schebella:
thanks, I thought, maybe dyn has the power to "remember" that is
has to finish the processing line for the particular object, then
delete it and then return the ball back to pd without crashing.
No, it hasn't. dyn~ is just a wrapper around pd API functions.
don't know what you mean with the canvas problem??
try to paste your patch below into a (=one) pd file and open it. Note
that there's no separation line between your actually two patches.
T
m.
Thomas Grill wrote:
Hi Marius, it's a problem inherent in PD, which was discussed just a few days
ago. An object can't be deleted when messages sent by it are still
processed. It's easy to circumvent in your case: Delay the closing just a
bit.... find the attached patch. I don't think this is something
that dyn~ should "fix". By the way - with your patch attachment you exposed something that
might be considered a pd bug: Two patches that are pasted into one file will open to canvases,
but pd will crash on every save attempt of it. all the best, Thomas Am 25.02.2007 um 21:22 schrieb marius schebella:Hi thomas, it is easy to build a loop which can crash dyn~, and I wonder if
it would be possible to avoid a crash. I use objects, which play for a random anount of time and then
they send their id when they're finished and so dyn knows that it
is time to delete them. I understand wyy this is a problem, and I also found some sort of
work around. but it would be easier if dyn would catch that
recursion. any idea? marius.#N canvas 310 87 250 256 10; #X obj 74 116 symbol $1; #X obj 74 66 loadbang; #X obj 74 89 delay $2; #X obj 74 140 s killme; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #N canvas 639 186 681 434 10; #X obj 527 220 symbol $1; #X obj 527 170 loadbang; #X obj 527 193 delay $2; #X obj 527 244 s killme; #X text 416 126 that is the test abstraction; #X obj 223 194 cnv 15 100 60 empty empty empty 20 12 0 14 -258049
-66577 0; #X obj 86 271 dyn~ 0 0 0 0; #X obj 236 201 r killme; #X msg 236 230 del $1; #X msg 86 90 newobj . a1 test1 a1 2000; #X text 55 50 CAUTION!!! By clicking here , Pd might crash!; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 7 0 8 0; #X connect 8 0 6 0; #X connect 9 0 6 0; _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-listThomas Grill http://grrrr.org
Thomas Grill http://grrrr.org
-
marius schebella -
Thomas Grill