Pd-dev June 2010

pd-dev@lists.iem.at

16 participants
113 discussions

[ pure-data-Bugs-2939290 ] pd pegs process after suspend on Ubuntu/Karmic/64-bit
by SourceForge.net 06 Jun '10

06 Jun '10

Bugs item #2939290, was opened at 2010-01-25 12:51 Message generated for change (Comment added) made by katjav You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2939290&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pd pegs process after suspend on Ubuntu/Karmic/64-bit Initial Comment: yes, its like that. pd eats all aviable processor resources after suspend until i close it. i have compiled version 0.42.5 without any errors on my ubuntu karmic (x64), using AMD Turion MK-36 ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2010-06-06 19:54 Message: I should better include the patch which I used to check these things. #N canvas 628 67 463 505 10; #X obj 98 198 metro 1000; #X obj 98 250 +; #X msg 98 223 1; #X floatatom 98 278 5 0 0 0 - - -; #X obj 98 173 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 51 223 0; #X text 11 222 reset; #X msg 10 111 \; pd dsp 1; #X obj 10 52 loadbang; #X obj 77 87 delay 1000; #X msg 77 111 \; pd dsp 0; #X text 10 12 patch for testing sleep behaviour of [metro]; #X text 148 119 1: make sure DSP is turned on and then off.; #X text 132 172 2: activate metro.; #X text 135 279 3: watch seconds being counted in normal conditions ; #X text 13 320 4: put your computer to sleep for a couple of minutes. ; #X text 13 349 5: wake up your computer and watch the seconds-counting box. Metro will probably execute all the ticks which it missed while sleeping. This can cause considerable CPU load \, up to 100%. After a couple of hours of sleep and with a faster metro speed \, CPU overload may last for minutes.; #X text 14 430 6: reset counter \, turn DSP on and do sleep - wake up again. Probably you will find that the abovementioned behaviour does not happen now.; #X connect 0 0 2 0; #X connect 1 0 3 0; #X connect 2 0 1 0; #X connect 3 0 1 1; #X connect 4 0 0 0; #X connect 5 0 1 1; #X connect 5 0 1 0; #X connect 8 0 7 0; #X connect 8 0 9 0; #X connect 9 0 10 0; ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2010-06-06 17:20 Message: It took me a while to find out under what exact conditions the phenomenon happens. But for me on OSX 10.5 it is like this: when dsp is turned on, then off again, and the computer is put to sleep mode and waked up again, metro will instantaneously count all it's lost ticks. However, it does not happen with dsp on while going in sleep mode, and also it does not happen when dsp is still "off" after Pd startup. (Is DSP really off at startup?). I tried these things with Pd extended 0.41 but also with the latest build of 0.42.5-extended-rc1. The behaviour is the same for both versions, as far as I can see. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-06-01 23:09 Message: katjav, could you try a nightly build on Mac OS X? I am guessing this is related to the 'audio stuck' code, which has been disabled on Mac OS X builds of Pd-extended. ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2010-02-09 00:14 Message: With Pd 0.41.4 extended on OSX 10.5 the same behaviour happens. More specific I have noticed this: a switched-on metro object will send all it's suspended messages at wake up after sleep. This makes Pd using 99% cpu during some time, depending on the length of sleep period. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-27 00:33 Message: An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-27 00:33 Message: Cannot reproduce using Pd version 0.42.5-extended-20100120 on Mac OS X 10.5.8. ---------------------------------------------------------------------- Comment By: kubriel (kubriel) Date: 2010-01-25 17:45 Message: ok, i logged in. yes, but it is curious, why pd have to compute everything what had to be done during sleep? it sounds useless. i tried suspend my computer (for 5sec) with opened pd, but without opened patch, it happens again - eats all aviable cpu (until i kill the proces), but no patch opened. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2010-01-25 13:32 Message: i can't reproduce this : pd 42.5 ubuntu karmic i386 however, after suspend, pd have to compute everything that as not been computed during suspend. so it can eat all cpu for some time, until it sync again with real time. this is only if a patch that use cpu is open during suspend. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2939290&group_…

1 0

[ pure-data-Bugs-2939290 ] pd pegs process after suspend on Ubuntu/Karmic/64-bit
by SourceForge.net 06 Jun '10

06 Jun '10

Bugs item #2939290, was opened at 2010-01-25 12:51 Message generated for change (Comment added) made by katjav You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2939290&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pd pegs process after suspend on Ubuntu/Karmic/64-bit Initial Comment: yes, its like that. pd eats all aviable processor resources after suspend until i close it. i have compiled version 0.42.5 without any errors on my ubuntu karmic (x64), using AMD Turion MK-36 ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2010-06-06 17:20 Message: It took me a while to find out under what exact conditions the phenomenon happens. But for me on OSX 10.5 it is like this: when dsp is turned on, then off again, and the computer is put to sleep mode and waked up again, metro will instantaneously count all it's lost ticks. However, it does not happen with dsp on while going in sleep mode, and also it does not happen when dsp is still "off" after Pd startup. (Is DSP really off at startup?). I tried these things with Pd extended 0.41 but also with the latest build of 0.42.5-extended-rc1. The behaviour is the same for both versions, as far as I can see. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-06-01 23:09 Message: katjav, could you try a nightly build on Mac OS X? I am guessing this is related to the 'audio stuck' code, which has been disabled on Mac OS X builds of Pd-extended. ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2010-02-09 00:14 Message: With Pd 0.41.4 extended on OSX 10.5 the same behaviour happens. More specific I have noticed this: a switched-on metro object will send all it's suspended messages at wake up after sleep. This makes Pd using 99% cpu during some time, depending on the length of sleep period. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-27 00:33 Message: Cannot reproduce using Pd version 0.42.5-extended-20100120 on Mac OS X 10.5.8. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-27 00:33 Message: An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else. ---------------------------------------------------------------------- Comment By: kubriel (kubriel) Date: 2010-01-25 17:45 Message: ok, i logged in. yes, but it is curious, why pd have to compute everything what had to be done during sleep? it sounds useless. i tried suspend my computer (for 5sec) with opened pd, but without opened patch, it happens again - eats all aviable cpu (until i kill the proces), but no patch opened. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2010-01-25 13:32 Message: i can't reproduce this : pd 42.5 ubuntu karmic i386 however, after suspend, pd have to compute everything that as not been computed during suspend. so it can eat all cpu for some time, until it sync again with real time. this is only if a patch that use cpu is open during suspend. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2939290&group_…

1 0

[ pure-data-Bugs-3011925 ] trouble on pd extended 041.4
by SourceForge.net 06 Jun '10

06 Jun '10

Bugs item #3011925, was opened at 2010-06-06 02:40 Message generated for change (Tracker Item Submitted) made by baudry You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3011925&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.41 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BAUDRY Olivier (baudry) Assigned to: Hans-Christoph Steiner (eighthave) Summary: trouble on pd extended 041.4 Initial Comment: I have trouble on Mac intel tiger here the rapport crash log of puredata ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3011925&group_…

1 0

Re: [PD-dev] [PD] [PD-announce] Pd-extended 0.42.5 release candidate 1 released!
by Hans-Christoph Steiner 06 Jun '10

06 Jun '10

On Jun 5, 2010, at 12:41 PM, ydegoyon(a)gmail.com wrote: > >> >> >>> On Lucid, it will not install because of the dependency on >>> libraw1394-8 (Lucid has libraw1394-11) >> >> I'll check it out. >> > do you know you can put :: libc6 (>= 2.4), > instead of specific versions > for each system? > > ciao, > sevy The list of dependencies is automatically generated by the Debian tools. So I am not sure where the problem is. Once I get back online, I'll check it out. It might be a matter of just apt-get upgrading the Lucid build server. .hc ---------------------------------------------------------------------------- "Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman

1 0

[ pure-data-Bugs-3011815 ] Path editor cannot edit bad paths
by SourceForge.net 05 Jun '10

05 Jun '10

Bugs item #3011815, was opened at 2010-06-05 10:15 Message generated for change (Comment added) made by danomatika You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3011815&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dan Wilcox (danomatika) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Path editor cannot edit bad paths Initial Comment: Running Pd-Extended 0.42.5 rc1 on Mac OSX 10.6.3 I moved some local lib folders and tried to update them in the Path editor. Selecting one of these paths and hitting Edit... results in a TK error dialog with the following message: Error: Bad directory "/Users/path/to/old/folder...". I cannot edit the path within PD, which is annoying. ---------------------------------------------------------------------- >Comment By: Dan Wilcox (danomatika) Date: 2010-06-05 11:06 Message: I added PathEditor.patch for pd-tk which adds a check on existing paths before editing them. If they don't exist, an error message is printed to ::pdwindow::error and the dialog path is set to the home dir. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3011815&group_…

1 0

[ pure-data-Bugs-3011815 ] Path editor cannot edit bad paths
by SourceForge.net 05 Jun '10

05 Jun '10

Bugs item #3011815, was opened at 2010-06-05 10:15 Message generated for change (Settings changed) made by danomatika You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3011815&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dan Wilcox (danomatika) Assigned to: Hans-Christoph Steiner (eighthave) >Summary: Path editor cannot edit bad paths Initial Comment: Running Pd-Extended 0.42.5 rc1 on Mac OSX 10.6.3 I moved some local lib folders and tried to update them in the Path editor. Selecting one of these paths and hitting Edit... results in a TK error dialog with the following message: Error: Bad directory "/Users/path/to/old/folder...". I cannot edit the path within PD, which is annoying. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3011815&group_…

1 0

[ pure-data-Bugs-3011815 ] Path editor cannot edit pad paths
by SourceForge.net 05 Jun '10

05 Jun '10

Bugs item #3011815, was opened at 2010-06-05 10:15 Message generated for change (Tracker Item Submitted) made by danomatika You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3011815&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dan Wilcox (danomatika) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Path editor cannot edit pad paths Initial Comment: Running Pd-Extended 0.42.5 rc1 on Mac OSX 10.6.3 I moved some local lib folders and tried to update them in the Path editor. Selecting one of these paths and hitting Edit... results in a TK error dialog with the following message: Error: Bad directory "/Users/path/to/old/folder...". I cannot edit the path within PD, which is annoying. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3011815&group_…

1 0

[ pure-data-Bugs-2978457 ] -nogui audio initialization problems under Debian
by SourceForge.net 05 Jun '10

05 Jun '10

Bugs item #2978457, was opened at 2010-03-29 10:01 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2978457&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: -nogui audio initialization problems under Debian Initial Comment: The [delread~] in the attached patch fails to initialize to the correct samplerate when started with -nogui under Debian and Pd 0.41.4 or 0.42-5. It seems to initialize to a samplerate of 0 instead. This problem persists independently from the audio driver used (ALS vs OSS). The patch works fine under Windows XP, however. The patch contains a workaround which has been suggested on the Pd-list, i.e. to loadbang a [switch~] object to 0 and then set it to 1 when neded. However, this did not help in the current situation. The patch also delays the loadbanged [;pd dsp 1( message by a [del 1000. This is a workaround addressing another manifestation of the audio initialisation problems with -nogui under Debian. If the [del 1000] is removed, the patch fails to load under -nogui with a "dev/dsp (read/write): Device or resource busy" message. IOhannes has suggested on the list to set the samplerate explicitely at startup, i.e. by pd -nogui -r 44100 However, I cannot confirm this workaround to work with the attached patch. Please note that the attached patch works fine under Windows XP and with -nogui enabled; also if the [del 1000] and [switch~] objects are omitted. best, flo.H ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-06-05 15:15 Message: this diff ought to be included in pd-extended 0.42 test builds ASAP. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-06-05 15:13 Message: the diff is in the patchtracker. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-17 23:00 Message: move sigdelwrite_updatesr(delwriter, sp[0]->s_sr); inside if (delwriter) or else you will get crashes due to null-pointer error. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 21:56 Message: --- d_delay.c (révision 13558) +++ d_delay.c (copie de travail) @@ -24,6 +24,7 @@ { t_object x_obj; t_symbol *x_sym; + t_float x_deltime; /* delay in msec */ t_delwritectl x_cspace; int x_sortno; /* DSP sort number at which this was last put on chain */ int x_rsortno; /* DSP sort # for first delread or write in chain */ @@ -34,6 +35,21 @@ #define XTRASAMPS 4 #define SAMPBLK 4 +static void sigdelwrite_updatesr (t_sigdelwrite *x, t_float sr) +{ + int nsamps = x->x_deltime * sr * (t_float)(0.001f); + if (nsamps < 1) nsamps = 1; + nsamps += ((- nsamps) & (SAMPBLK - 1)); + nsamps += DEFDELVS; + if (x->x_cspace.c_n != nsamps) { + x->x_cspace.c_vec = (t_sample *)resizebytes(x->x_cspace.c_vec, + (x->x_cspace.c_n + XTRASAMPS) * sizeof(t_sample), + ( nsamps + XTRASAMPS) * sizeof(t_sample)); + x->x_cspace.c_n = nsamps; + x->x_cspace.c_phase = XTRASAMPS; + } +} + /* routine to check that all delwrites/delreads/vds have same vecsize */ static void sigdelwrite_checkvecsize(t_sigdelwrite *x, int vecsize) { @@ -54,19 +70,13 @@ static void *sigdelwrite_new(t_symbol *s, t_floatarg msec) { - int nsamps; t_sigdelwrite *x = (t_sigdelwrite *)pd_new(sigdelwrite_class); if (!*s->s_name) s = gensym("delwrite~"); pd_bind(&x->x_obj.ob_pd, s); x->x_sym = s; - nsamps = msec * sys_getsr() * (t_float)(0.001f); - if (nsamps < 1) nsamps = 1; - nsamps += ((- nsamps) & (SAMPBLK - 1)); - nsamps += DEFDELVS; - x->x_cspace.c_n = nsamps; - x->x_cspace.c_vec = - (t_sample *)getbytes((nsamps + XTRASAMPS) * sizeof(t_sample)); - x->x_cspace.c_phase = XTRASAMPS; + x->x_deltime = msec; + x->x_cspace.c_n = 0; + x->x_cspace.c_vec = getbytes(XTRASAMPS * sizeof(t_sample)); x->x_sortno = 0; x->x_vecsize = 0; x->x_f = 0; @@ -109,6 +119,7 @@ dsp_add(sigdelwrite_perform, 3, sp[0]->s_vec, &x->x_cspace, sp[0]->s_n); x->x_sortno = ugen_getsortno(); sigdelwrite_checkvecsize(x, sp[0]->s_n); + sigdelwrite_updatesr(x, sp[0]->s_sr); } static void sigdelwrite_free(t_sigdelwrite *x) @@ -180,6 +191,7 @@ int delsamps = *(int *)(w[3]); int n = (int)(w[4]); int phase = c->c_phase - delsamps, nsamps = c->c_n; + t_sample *vp = c->c_vec, *bp, *ep = vp + (c->c_n + XTRASAMPS); if (phase < 0) phase += nsamps; bp = vp + phase; @@ -197,6 +209,7 @@ t_sigdelwrite *delwriter = (t_sigdelwrite *)pd_findbyclass(x->x_sym, sigdelwrite_class); x->x_sr = sp[0]->s_sr * 0.001; + sigdelwrite_updatesr(delwriter, sp[0]->s_sr); x->x_n = sp[0]->s_n; if (delwriter) { @@ -206,8 +219,7 @@ sigdelread_float(x, x->x_deltime); dsp_add(sigdelread_perform, 4, sp[0]->s_vec, &delwriter->x_cspace, &x->x_delsamps, sp[0]->s_n); - } - else if (*x->x_sym->s_name) + } else if (*x->x_sym->s_name) error("delread~: %s: no such delwrite~",x->x_sym->s_name); } ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 18:03 Message: the bug is actually deeper than that, as delread does a bunch of "Invalid read of size 4" according to valgrind, after this fix. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:48 Message: the previous fix is leaking memory. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:45 Message: --- d_delay.c (révision 13539) +++ d_delay.c (copie de travail) @@ -24,6 +24,7 @@ { t_object x_obj; t_symbol *x_sym; + t_float x_deltime; /* delay in msec */ t_delwritectl x_cspace; int x_sortno; /* DSP sort number at which this was last put on chain */ int x_rsortno; /* DSP sort # for first delread or write in chain */ @@ -54,19 +55,13 @@ static void *sigdelwrite_new(t_symbol *s, t_floatarg msec) { - int nsamps; t_sigdelwrite *x = (t_sigdelwrite *)pd_new(sigdelwrite_class); if (!*s->s_name) s = gensym("delwrite~"); pd_bind(&x->x_obj.ob_pd, s); x->x_sym = s; - nsamps = msec * sys_getsr() * (t_float)(0.001f); - if (nsamps < 1) nsamps = 1; - nsamps += ((- nsamps) & (SAMPBLK - 1)); - nsamps += DEFDELVS; - x->x_cspace.c_n = nsamps; - x->x_cspace.c_vec = - (t_sample *)getbytes((nsamps + XTRASAMPS) * sizeof(t_sample)); - x->x_cspace.c_phase = XTRASAMPS; + x->x_deltime = msec; + x->x_cspace.c_n = 0; + x->x_cspace.c_vec = 0; x->x_sortno = 0; x->x_vecsize = 0; x->x_f = 0; @@ -106,6 +101,18 @@ static void sigdelwrite_dsp(t_sigdelwrite *x, t_signal **sp) { + int nsamps = x->x_deltime * sp[0]->s_sr * (t_float)(0.001f); + post("sigdelwrite_dsp: %f ms, with sr=%f",x->x_deltime,sys_getsr()); + if (nsamps < 1) nsamps = 1; + nsamps += ((- nsamps) & (SAMPBLK - 1)); + nsamps += DEFDELVS; + if (x->x_cspace.c_n != nsamps) { + x->x_cspace.c_n = nsamps; + x->x_cspace.c_vec = + (t_sample *)getbytes((nsamps + XTRASAMPS) * sizeof(t_sample)); + x->x_cspace.c_phase = XTRASAMPS; + } + dsp_add(sigdelwrite_perform, 3, sp[0]->s_vec, &x->x_cspace, sp[0]->s_n); x->x_sortno = ugen_getsortno(); sigdelwrite_checkvecsize(x, sp[0]->s_n); ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:40 Message: this also goes with another bug : [delwrite~] doesn't honour the sampling rate set by [block~] ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:20 Message: this goes with another bug : [delwrite~] doesn't honour any change of sampling rate (e.g. 44100 to 22050). those bugs are related because the reason [delwrite~] doesn't work with this, is that [delwrite~] is created while sys_getsr() still reports sampling rate to be "0", because sys_dacsr has not been assigned to. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:00 Message: if you load your patch using a «; pd open $1 .» message from a [delay]ed [loadbang], the patch runs correctly. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 16:53 Message: you can replace the [delay 1000] by just [delay], that is, [delay 0]. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2978457&group_…

1 0

[ pure-data-Bugs-2978457 ] -nogui audio initialization problems under Debian
by SourceForge.net 05 Jun '10

05 Jun '10

Bugs item #2978457, was opened at 2010-03-29 10:01 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2978457&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: -nogui audio initialization problems under Debian Initial Comment: The [delread~] in the attached patch fails to initialize to the correct samplerate when started with -nogui under Debian and Pd 0.41.4 or 0.42-5. It seems to initialize to a samplerate of 0 instead. This problem persists independently from the audio driver used (ALS vs OSS). The patch works fine under Windows XP, however. The patch contains a workaround which has been suggested on the Pd-list, i.e. to loadbang a [switch~] object to 0 and then set it to 1 when neded. However, this did not help in the current situation. The patch also delays the loadbanged [;pd dsp 1( message by a [del 1000. This is a workaround addressing another manifestation of the audio initialisation problems with -nogui under Debian. If the [del 1000] is removed, the patch fails to load under -nogui with a "dev/dsp (read/write): Device or resource busy" message. IOhannes has suggested on the list to set the samplerate explicitely at startup, i.e. by pd -nogui -r 44100 However, I cannot confirm this workaround to work with the attached patch. Please note that the attached patch works fine under Windows XP and with -nogui enabled; also if the [del 1000] and [switch~] objects are omitted. best, flo.H ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-06-05 15:13 Message: the diff is in the patchtracker. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-17 23:00 Message: move sigdelwrite_updatesr(delwriter, sp[0]->s_sr); inside if (delwriter) or else you will get crashes due to null-pointer error. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 21:56 Message: --- d_delay.c (révision 13558) +++ d_delay.c (copie de travail) @@ -24,6 +24,7 @@ { t_object x_obj; t_symbol *x_sym; + t_float x_deltime; /* delay in msec */ t_delwritectl x_cspace; int x_sortno; /* DSP sort number at which this was last put on chain */ int x_rsortno; /* DSP sort # for first delread or write in chain */ @@ -34,6 +35,21 @@ #define XTRASAMPS 4 #define SAMPBLK 4 +static void sigdelwrite_updatesr (t_sigdelwrite *x, t_float sr) +{ + int nsamps = x->x_deltime * sr * (t_float)(0.001f); + if (nsamps < 1) nsamps = 1; + nsamps += ((- nsamps) & (SAMPBLK - 1)); + nsamps += DEFDELVS; + if (x->x_cspace.c_n != nsamps) { + x->x_cspace.c_vec = (t_sample *)resizebytes(x->x_cspace.c_vec, + (x->x_cspace.c_n + XTRASAMPS) * sizeof(t_sample), + ( nsamps + XTRASAMPS) * sizeof(t_sample)); + x->x_cspace.c_n = nsamps; + x->x_cspace.c_phase = XTRASAMPS; + } +} + /* routine to check that all delwrites/delreads/vds have same vecsize */ static void sigdelwrite_checkvecsize(t_sigdelwrite *x, int vecsize) { @@ -54,19 +70,13 @@ static void *sigdelwrite_new(t_symbol *s, t_floatarg msec) { - int nsamps; t_sigdelwrite *x = (t_sigdelwrite *)pd_new(sigdelwrite_class); if (!*s->s_name) s = gensym("delwrite~"); pd_bind(&x->x_obj.ob_pd, s); x->x_sym = s; - nsamps = msec * sys_getsr() * (t_float)(0.001f); - if (nsamps < 1) nsamps = 1; - nsamps += ((- nsamps) & (SAMPBLK - 1)); - nsamps += DEFDELVS; - x->x_cspace.c_n = nsamps; - x->x_cspace.c_vec = - (t_sample *)getbytes((nsamps + XTRASAMPS) * sizeof(t_sample)); - x->x_cspace.c_phase = XTRASAMPS; + x->x_deltime = msec; + x->x_cspace.c_n = 0; + x->x_cspace.c_vec = getbytes(XTRASAMPS * sizeof(t_sample)); x->x_sortno = 0; x->x_vecsize = 0; x->x_f = 0; @@ -109,6 +119,7 @@ dsp_add(sigdelwrite_perform, 3, sp[0]->s_vec, &x->x_cspace, sp[0]->s_n); x->x_sortno = ugen_getsortno(); sigdelwrite_checkvecsize(x, sp[0]->s_n); + sigdelwrite_updatesr(x, sp[0]->s_sr); } static void sigdelwrite_free(t_sigdelwrite *x) @@ -180,6 +191,7 @@ int delsamps = *(int *)(w[3]); int n = (int)(w[4]); int phase = c->c_phase - delsamps, nsamps = c->c_n; + t_sample *vp = c->c_vec, *bp, *ep = vp + (c->c_n + XTRASAMPS); if (phase < 0) phase += nsamps; bp = vp + phase; @@ -197,6 +209,7 @@ t_sigdelwrite *delwriter = (t_sigdelwrite *)pd_findbyclass(x->x_sym, sigdelwrite_class); x->x_sr = sp[0]->s_sr * 0.001; + sigdelwrite_updatesr(delwriter, sp[0]->s_sr); x->x_n = sp[0]->s_n; if (delwriter) { @@ -206,8 +219,7 @@ sigdelread_float(x, x->x_deltime); dsp_add(sigdelread_perform, 4, sp[0]->s_vec, &delwriter->x_cspace, &x->x_delsamps, sp[0]->s_n); - } - else if (*x->x_sym->s_name) + } else if (*x->x_sym->s_name) error("delread~: %s: no such delwrite~",x->x_sym->s_name); } ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 18:03 Message: the bug is actually deeper than that, as delread does a bunch of "Invalid read of size 4" according to valgrind, after this fix. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:48 Message: the previous fix is leaking memory. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:45 Message: --- d_delay.c (révision 13539) +++ d_delay.c (copie de travail) @@ -24,6 +24,7 @@ { t_object x_obj; t_symbol *x_sym; + t_float x_deltime; /* delay in msec */ t_delwritectl x_cspace; int x_sortno; /* DSP sort number at which this was last put on chain */ int x_rsortno; /* DSP sort # for first delread or write in chain */ @@ -54,19 +55,13 @@ static void *sigdelwrite_new(t_symbol *s, t_floatarg msec) { - int nsamps; t_sigdelwrite *x = (t_sigdelwrite *)pd_new(sigdelwrite_class); if (!*s->s_name) s = gensym("delwrite~"); pd_bind(&x->x_obj.ob_pd, s); x->x_sym = s; - nsamps = msec * sys_getsr() * (t_float)(0.001f); - if (nsamps < 1) nsamps = 1; - nsamps += ((- nsamps) & (SAMPBLK - 1)); - nsamps += DEFDELVS; - x->x_cspace.c_n = nsamps; - x->x_cspace.c_vec = - (t_sample *)getbytes((nsamps + XTRASAMPS) * sizeof(t_sample)); - x->x_cspace.c_phase = XTRASAMPS; + x->x_deltime = msec; + x->x_cspace.c_n = 0; + x->x_cspace.c_vec = 0; x->x_sortno = 0; x->x_vecsize = 0; x->x_f = 0; @@ -106,6 +101,18 @@ static void sigdelwrite_dsp(t_sigdelwrite *x, t_signal **sp) { + int nsamps = x->x_deltime * sp[0]->s_sr * (t_float)(0.001f); + post("sigdelwrite_dsp: %f ms, with sr=%f",x->x_deltime,sys_getsr()); + if (nsamps < 1) nsamps = 1; + nsamps += ((- nsamps) & (SAMPBLK - 1)); + nsamps += DEFDELVS; + if (x->x_cspace.c_n != nsamps) { + x->x_cspace.c_n = nsamps; + x->x_cspace.c_vec = + (t_sample *)getbytes((nsamps + XTRASAMPS) * sizeof(t_sample)); + x->x_cspace.c_phase = XTRASAMPS; + } + dsp_add(sigdelwrite_perform, 3, sp[0]->s_vec, &x->x_cspace, sp[0]->s_n); x->x_sortno = ugen_getsortno(); sigdelwrite_checkvecsize(x, sp[0]->s_n); ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:40 Message: this also goes with another bug : [delwrite~] doesn't honour the sampling rate set by [block~] ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:20 Message: this goes with another bug : [delwrite~] doesn't honour any change of sampling rate (e.g. 44100 to 22050). those bugs are related because the reason [delwrite~] doesn't work with this, is that [delwrite~] is created while sys_getsr() still reports sampling rate to be "0", because sys_dacsr has not been assigned to. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 17:00 Message: if you load your patch using a «; pd open $1 .» message from a [delay]ed [loadbang], the patch runs correctly. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-05-16 16:53 Message: you can replace the [delay 1000] by just [delay], that is, [delay 0]. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2978457&group_…

1 0

[ pure-data-Patches-2984142 ] canvasdelete-help.pd
by SourceForge.net 05 Jun '10

05 Jun '10

Patches item #2984142, was opened at 2010-04-08 21:01 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2984142&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: documentation >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: canvasdelete-help.pd Initial Comment: Attached is a help patch for [canvasdelete] from iemguts. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-06-05 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-21 17:34 Message: you patch only documents a side-feature of [canvasdelete]. the real power of [canvasdelete] lies in deleting itself (and its parents) without crashing Pd. btw, you don't have to put a [canvasdelete] instance into a canvas that you want to listen to "delete" messages. once you have loaded canvasdelete (e.g. with "-lib canvasdelete") this method is added to Pd's canvas-methods and can be used just like any other dynamic patching message. anyhow, i committed a help-patch based on yours with rev13567 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2984142&group_…

1 0

← Newer
1
...
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev June 2010