[PD] dyn~ crash

marius schebella marius.schebella at gmail.com
Sun Feb 25 23:04:05 CET 2007


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 at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> http://lists.puredata.info/listinfo/pd-list
>>
>> Thomas Grill
>> http://grrrr.org
>>
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list
> 
> Thomas Grill
> http://grrrr.org
> 
> 
> 





More information about the Pd-list mailing list