Hi,
There seems to be some bug in 0_38 devel. I get crash when using pvoc.pd form fft.examples directory. It occurs when I turn on dsp, and try to load soundfiles. This doesn't happen when pd is built without threaded soundfiler, but then pvoc.pd doesn't produce any sound (well actually there is some noise when I set MASTER LEVEL to around 160). Standard help patches for fft~, ifft~, rfft~ and rifft~ behave normal. Another thing. I've build pd with fftw support. I loaded pvoc.pd and didn't get any crash (even with threaded soundfiler), but the audio output was totally screwed (but in other way than with "standard" fft).
I'm on windows. Pd was built from the sources I've downloaded this weekend.
cheers, Bart
There seems to be some bug in 0_38 devel. I get crash when using pvoc.pd form fft.examples directory. It occurs when I turn on dsp, and try to load soundfiles. This doesn't happen when pd is built without threaded soundfiler, but then pvoc.pd doesn't produce any sound (well actually there is some noise when I set MASTER LEVEL to around 160). Standard help patches for fft~, ifft~, rfft~ and rifft~ behave normal. Another thing. I've build pd with fftw support. I loaded pvoc.pd and didn't get any crash (even with threaded soundfiler), but the audio output was totally screwed (but in other way than with "standard" fft).
last weekend i figured out, that something is wrong with the fftw ... i'll look into this again ... but possibly i won't have a lot of time for that in feb...
anyway, thanks for the bug report and i'll have a look at it, as soon as possible ...
cheers ... tim
Tim Blechmann :
There seems to be some bug in 0_38 devel. I get crash when using pvoc.pd form fft.examples directory. It occurs when I turn on dsp, and try to load soundfiles. This doesn't happen when pd is built without threaded soundfiler, but then pvoc.pd doesn't produce any sound (well actually there is some noise when I set MASTER LEVEL to around 160). Standard help patches for fft~, ifft~, rfft~ and rifft~ behave normal. Another thing. I've build pd with fftw support. I loaded pvoc.pd and didn't get any crash (even with threaded soundfiler), but the audio output was totally screwed (but in other way than with "standard" fft).
last weekend i figured out, that something is wrong with the fftw ... i'll look into this again ... but possibly i won't have a lot of time for that in feb...
Yeah ok. But what about "standard", mayer fft? Just to be sure I have described the problem clearly (because I think I haven't in the previous message):
pd_devel + threaded soundfiler + mayer fft = crash with pvoc.pd pd_devel + "standard" soundfiler + mayer fft = no sound (more less) in pvoc.pd, _no_crash_ pd_devel + threaded/"normal" soundfiler + fftw = _no_crash_ but weird sound in pvoc.pd
cheers, Bart
pd_devel + threaded soundfiler + mayer fft = crash with pvoc.pd pd_devel + "standard" soundfiler + mayer fft = no sound (more less) in
pvoc.pd, _no_crash_ pd_devel + threaded/"normal" soundfiler + fftw = _no_crash_ but weird sound in pvoc.pd
i just checked my mail archive ... thomas grill told me about this back in november ... i suppose, the dsp chain will be recompiled in the helper thread, thus the fftw setup routines will be run, which are not threadsafe (this is a guess)...
i'm about 99.99% sure, that this can be solved, if the arrays will be redesigned properly...
this wouldn't be a big problem, but i won't do it, since i would do it one way, miller would do it differently for 0.43 or so, which would result in 2 incompatible versions of pd.
at the moment devel_'s changes could still be merged with head ... but the more changes there are, the more difficult it gets. and at one point we have a fork :-(
this is something that really should be avoided.
on the wiki page for irc developer meeting, a threadsafe handling of arrays is one of the point, i've added...
cheers ... tim
Tim Blechmann :
pd_devel + threaded soundfiler + fftw
Correction. In this configuration I also get crash (don't know why it didn't happen yesterday - propably my mistake). Sorry for making confusion.
i just checked my mail archive ... thomas grill told me about this back in november ... i suppose, the dsp chain will be recompiled in the helper thread, thus the fftw setup routines will be run, which are not threadsafe (this is a guess)...
i'm about 99.99% sure, that this can be solved, if the arrays will be redesigned properly...
Ok. So this "crash thing" can be somewhat resolved. BTW. I don't know if it helps, but in 0_37 devel pvoc.pd works fine with threaded soundiler. As for the screwed sound in fft.examples patches it seems that it's not fft (at least not mayer fft) fault actually. I suspect that line~ might be causing problems, but I have to investigate it further.
cheers, Bart
Ok. So this "crash thing" can be somewhat resolved. BTW. I don't know if it helps, but in 0_37 devel pvoc.pd works fine with threaded soundiler.
the way the threaded soundfiler synchronizes with the main thread in devel_0_37 is not really clean...
As for the screwed sound in fft.examples patches it seems that it's not fft (at least not mayer fft) fault actually. I suspect that line~ might be causing problems, but I have to investigate it further.
i did some changes to line~, too ... but doing a short test, it seems to work fine on my machine ...
get back to you later ... tim
Tim Blechmann :
As for the screwed sound in fft.examples patches it seems that it's not fft (at least not mayer fft) fault actually. I suspect that line~ might be causing problems, but I have to investigate it further.
i did some changes to line~, too ... but doing a short test, it seems to work fine on my machine ...
I'm pretty sure there is something wrong with line~. Take a look at my test patch: http://www.ckmedia.pl/~fev/test2.zip
(test.pd is the "main" patch).
cheers, Bart
I'm pretty sure there is something wrong with line~. Take a look at my test patch: http://www.ckmedia.pl/~fev/test2.zip
sounds fine on my machine ... how did you ./configure pd?
cheers ... tim
Tim Blechmann :
I'm pretty sure there is something wrong with line~. Take a look at my test patch: http://www.ckmedia.pl/~fev/test2.zip
sounds fine on my machine ... how did you ./configure pd?
And that is how it sounds on my: http://www.ckmedia.pl/~fev/out.wav
First I thought that it may be some problem with tabread4~/tabread~, but when I use phasor~ instead of line~ to produce "indexing" signal, everything sounds fine. Anyway here are the C flags I've defined in my makefile.nt:
CFLAGS = /nologo /D "NDEBUG" /G7 /O2 /arch:SSE /W3 /DMSW /DNT /DPD \ /DPD_INTERNAL /DWIN32 /DWINDOWS \ /DPA_LITTLE_ENDIAN /DUSEAPI_ASIO /DUSEAPI_MMIO \ /DUSEAPI_PORTAUDIO $(WISHDEF) /DTHREADED_GUI /DTHREADED_SF /DGARRAY_THREAD_LOCK /D_GNU_SOURCE
cheers, Bart
First I thought that it may be some problem with tabread4~/tabread~, but when I use phasor~ instead of line~ to produce "indexing" signal, everything sounds fine.
ok ... the line~ problem is solved ugly hack, though ... but it should work even on windoze ...
cheers ... tim
Tim Blechmann :
First I thought that it may be some problem with tabread4~/tabread~, but when I use phasor~ instead of line~ to produce "indexing" signal, everything sounds fine.
ok ... the line~ problem is solved ugly hack, though ... but it should work even on windoze ...
Thanks! Unfortunately I can't access cvs right now, so I can't test it. Would You be so kind and mail me apropriate/fixed source files?
BTW. Am I the only one having problems with sourceforge's cvs? I can't access any project cvs repository. For instance after:
cvs -z3 d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data \ co -r devel_0_38 pd
I get the following response: cvs [checkout aborted]: unrecognized auth response from cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect (Connection refused)
And when trying to use web interface I'm getting a page that says:
Bad Gateway The proxy server received an invalid response from an upstream server.
Normally I wouldn't worry, but it's like two days since it started. Before I contact someone at sourceforge, can someone confirm that I'm the only, "lucky" one, or is this some major sourceforge outage?
cheers, Bart
Unfortunately I can't access cvs right now, so I can't test it. Would You be so kind and mail me apropriate/fixed source files?
diff -u -r1.3.4.11 -r1.3.4.12 --- d_ctl.c 26 Jan 2005 19:23:16 -0000 1.3.4.11 +++ d_ctl.c 10 Feb 2005 21:54:49 -0000 1.3.4.12 @@ -149,7 +149,7 @@ static void line_tilde_slope(t_float* out, t_int n, t_float* value, t_float* slopes, t_float* slopestep) { - t_float slope = slopes[0]; + t_float slope = slopes[1]; t_float f = *value; n>>=3; while (n--) @@ -185,11 +185,19 @@ if (x->x_retarget) { int nticks = x->x_inletwas * x->x_dspticktomsec; + int i; if (!nticks) nticks = 1; x->x_ticksleft = nticks; x->x_biginc = (x->x_target - x->x_value)/(float)nticks; x->x_inc = x->x_1overn * x->x_biginc; x->x_retarget = 0; + + /* tb: rethink!!! this us ugly */ + for (i = 0; i != 4; ++i) + { + x->x_slopes[i] = i*x->x_inc; + } + x->x_slopestep = 4 * x->x_inc; } if (x->x_ticksleft) {
BTW. Am I the only one having problems with sourceforge's cvs? I can't access any project cvs repository. For instance after:
cvs -z3 d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data \ co -r devel_0_38 pd
sourceforge seems to have problems with the anonymous cvs (i think since yesterday)...
cheers ... tim
Tim Blechmann :
Unfortunately I can't access cvs right now, so I can't test it. Would You be so kind and mail me apropriate/fixed source files?
diff -u -r1.3.4.11 -r1.3.4.12 --- d_ctl.c 26 Jan 2005 19:23:16 -0000 1.3.4.11 +++ d_ctl.c 10 Feb 2005 21:54:49 -0000 1.3.4.12
...
Great! It works! Thanks. Hope that those other issues mentioned in this thread, will be soon resolved with similar (or greater) easiness :-)
cheers, Bart
-
Bartlomiej Bazior -
Georg Holzmann -
Thomas Grill -
Tim Blechmann