Pd-dev October 2008

pd-dev@lists.iem.at

9 participants
29 discussions

[ pure-data-Feature Requests-2148501 ] [mapping/iir] should ignore -inf and inf
by SourceForge.net 06 Oct '08

06 Oct '08

Feature Requests item #2148501, was opened at 2008-10-05 19:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2148501&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: None Status: Open Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Cyrille Henry (nusmuk) Summary: [mapping/iir] should ignore -inf and inf Initial Comment: Since the IIR object can overload, it makes sense that it should ignore -inf and inf on its inputs. Those values just cause the IIR to permanently overload. Perhaps a reset from overload would be useful too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2148501&group_…

1 0

[ pure-data-Bugs-2122705 ] auto-build system: add link to the full logfile in emails
by SourceForge.net 06 Oct '08

06 Oct '08

Bugs item #2122705, was opened at 2008-09-22 13:28 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2122705&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: None Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: auto-build system: add link to the full logfile in emails Initial Comment: in the current auto-build process, the system sends an email if the build-process fails. since it doesn't send the full logfile (for good reasons), one often has to go to auto-build.puredata.info in order to get the full failure report. it would be very helpful, if the email sent could contain a link to the corresponding full logfile, so one wouldn't have to search for it. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-10-06 00:41 Message: well, what's wrong with it? the log says that it was unable to upload via rsync, so naturally there are no logfiles either (since they are uploaded via the same method): rsync error: error in file IO (code 11) at receiver.c(259) [receiver=2.6.9] rsync error: error in rsync protocol data stream (code 12) at io.c(454) [sender=2.6.9] i could change line from "the full logfile can be viewed at:" to "the full logfile (if it has been successfully uploaded) can be viewed at:" :-) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-10-06 00:15 Message: In the email from 2008-10-04, the links don't work. They seem to have the wrong timestamps: atom_alphabet.c:99: error: for each function it appears in.) atom_alphabet.c:100: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:106: error: expected declaration specifiers or ... before GString atom_alphabet.c:108: error: gfsmPdAtomAlphabet has no member named aa_strbuf atom_alphabet.c:109: error: gstr undeclared (first use in this function) atom_alphabet.c:109: error: gfsmPdAtomAlphabet has no member named aa_strbuf atom_alphabet.c:121: error: expected expression before gfsmPdAtomAlphabet atom_alphabet.c:122: error: gfsmAlphabet undeclared (first use in this function) atom_alphabet.c:122: error: expected expression before ) token atom_alphabet.c:122: error: gfsmATUser undeclared (first use in this function) atom_alphabet.c:123: error: gfsmUserAlphabet undeclared (first use in this function) atom_alphabet.c:123: error: expected expression before ) token atom_alphabet.c:130: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:137: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:137: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:138: error: gfsmAlphabet undeclared (first use in this function) atom_alphabet.c:138: error: expected expression before ) token allhammers.c:84: error: expected identifier or ( before - token rsync error: error in file IO (code 11) at receiver.c(259) [receiver=2.6.9] rsync error: error in rsync protocol data stream (code 12) at io.c(454) [sender=2.6.9] the full logfile can be viewed at http://autobuild.puredata.info/auto-build/2008-10-04/logs/2008-10-04_07.55.… ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-09-26 12:56 Message: i have implemented this feature and added it to the "run-automated-builder" script (but not to the "mail-mingw-log-hack.sh") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2122705&group_…

1 0

[ pure-data-Bugs-2122705 ] auto-build system: add link to the full logfile in emails
by SourceForge.net 06 Oct '08

06 Oct '08

Bugs item #2122705, was opened at 2008-09-22 07:28 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2122705&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: None Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) >Assigned to: IOhannes m zmlnig (zmoelnig) Summary: auto-build system: add link to the full logfile in emails Initial Comment: in the current auto-build process, the system sends an email if the build-process fails. since it doesn't send the full logfile (for good reasons), one often has to go to auto-build.puredata.info in order to get the full failure report. it would be very helpful, if the email sent could contain a link to the corresponding full logfile, so one wouldn't have to search for it. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-10-05 18:15 Message: In the email from 2008-10-04, the links don't work. They seem to have the wrong timestamps: atom_alphabet.c:99: error: for each function it appears in.) atom_alphabet.c:100: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:106: error: expected declaration specifiers or ... before GString atom_alphabet.c:108: error: gfsmPdAtomAlphabet has no member named aa_strbuf atom_alphabet.c:109: error: gstr undeclared (first use in this function) atom_alphabet.c:109: error: gfsmPdAtomAlphabet has no member named aa_strbuf atom_alphabet.c:121: error: expected expression before gfsmPdAtomAlphabet atom_alphabet.c:122: error: gfsmAlphabet undeclared (first use in this function) atom_alphabet.c:122: error: expected expression before ) token atom_alphabet.c:122: error: gfsmATUser undeclared (first use in this function) atom_alphabet.c:123: error: gfsmUserAlphabet undeclared (first use in this function) atom_alphabet.c:123: error: expected expression before ) token atom_alphabet.c:130: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:137: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:137: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:138: error: gfsmAlphabet undeclared (first use in this function) atom_alphabet.c:138: error: expected expression before ) token allhammers.c:84: error: expected identifier or ( before - token rsync error: error in file IO (code 11) at receiver.c(259) [receiver=2.6.9] rsync error: error in rsync protocol data stream (code 12) at io.c(454) [sender=2.6.9] the full logfile can be viewed at http://autobuild.puredata.info/auto-build/2008-10-04/logs/2008-10-04_07.55.… ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-09-26 06:56 Message: i have implemented this feature and added it to the "run-automated-builder" script (but not to the "mail-mingw-log-hack.sh") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2122705&group_…

1 0

[ pure-data-Bugs-2122705 ] auto-build system: add link to the full logfile in emails
by SourceForge.net 06 Oct '08

06 Oct '08

Bugs item #2122705, was opened at 2008-09-22 07:28 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2122705&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: None Group: None >Status: Open Resolution: None Priority: 3 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Hans-Christoph Steiner (eighthave) Summary: auto-build system: add link to the full logfile in emails Initial Comment: in the current auto-build process, the system sends an email if the build-process fails. since it doesn't send the full logfile (for good reasons), one often has to go to auto-build.puredata.info in order to get the full failure report. it would be very helpful, if the email sent could contain a link to the corresponding full logfile, so one wouldn't have to search for it. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-10-05 18:15 Message: In the email from 2008-10-04, the links don't work. They seem to have the wrong timestamps: atom_alphabet.c:99: error: for each function it appears in.) atom_alphabet.c:100: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:106: error: expected declaration specifiers or ... before GString atom_alphabet.c:108: error: gfsmPdAtomAlphabet has no member named aa_strbuf atom_alphabet.c:109: error: gstr undeclared (first use in this function) atom_alphabet.c:109: error: gfsmPdAtomAlphabet has no member named aa_strbuf atom_alphabet.c:121: error: expected expression before gfsmPdAtomAlphabet atom_alphabet.c:122: error: gfsmAlphabet undeclared (first use in this function) atom_alphabet.c:122: error: expected expression before ) token atom_alphabet.c:122: error: gfsmATUser undeclared (first use in this function) atom_alphabet.c:123: error: gfsmUserAlphabet undeclared (first use in this function) atom_alphabet.c:123: error: expected expression before ) token atom_alphabet.c:130: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:137: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:137: error: gfsmPdAtomAlphabet has no member named aa_binbuf atom_alphabet.c:138: error: gfsmAlphabet undeclared (first use in this function) atom_alphabet.c:138: error: expected expression before ) token allhammers.c:84: error: expected identifier or ( before - token rsync error: error in file IO (code 11) at receiver.c(259) [receiver=2.6.9] rsync error: error in rsync protocol data stream (code 12) at io.c(454) [sender=2.6.9] the full logfile can be viewed at http://autobuild.puredata.info/auto-build/2008-10-04/logs/2008-10-04_07.55.… ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-09-26 06:56 Message: i have implemented this feature and added it to the "run-automated-builder" script (but not to the "mail-mingw-log-hack.sh") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2122705&group_…

1 0

abstraction caching
by Claude Heiland-Allen 03 Oct '08

03 Oct '08

Benchmarking an Abstraction Cache for Pd ======================================== I implemented a rudimentary abstraction caching mechanism for Miller Puckette's pd-0.41-4, which stores the parsed text ("binbuf") associated with the class name instead of looking for files to load every time it is instantiated. Benchmark Mechanism ------------------- Run 4 times, discarding first report: $ time pd -open layer_2.pd -send "; pd quit" &>/dev/null layer_2.pd contains 99 layer_1.pd contains 99 layer_0.pd, total 9901 = 9801 layer 0 + 99 layer 1 + 1 layer 0 Results: Without Cache ---------------------- real 0m0.524s user 0m0.260s sys 0m0.256s real 0m0.530s user 0m0.224s sys 0m0.276s real 0m0.527s user 0m0.224s sys 0m0.296s Results: With Cache ------------------- real 0m0.082s user 0m0.068s sys 0m0.004s real 0m0.148s user 0m0.120s sys 0m0.008s real 0m0.085s user 0m0.052s sys 0m0.012s Conclusion ---------- Abstraction cache gives a speed boost of more than 500% when loading patches containing a large number of abstractions. Further Work ------------ The main drawback (and the easiest issue to resolve) of the current implementation is that once an abstraction is in the cache, it stays there forever, no matter if the file is modified within or without Pd. This could be fixed by flushing the cache immediately after the patch is loaded (perhaps using Pd's scheduler). Another drawback are that abstractions in different directories with the same file name can clobber each other - the first one loaded is the "one true abstraction" with that name, resolving this issue will be more difficult. #N canvas 0 0 450 300 10; #X obj 28 24 inlet; #X obj 33 262 outlet; #N canvas 0 0 450 300 10; #X obj 8 9 layer_0; #X obj 8 29 layer_0; #X obj 8 49 layer_0; #X obj 8 69 layer_0; #X obj 8 89 layer_0; #X obj 8 109 layer_0; #X obj 8 129 layer_0; #X obj 8 149 layer_0; #X obj 8 169 layer_0; #X obj 8 189 layer_0; #X obj 8 209 layer_0; #X obj 8 230 layer_0; #X obj 8 250 layer_0; #X obj 8 270 layer_0; #X obj 68 9 layer_0; #X obj 68 29 layer_0; #X obj 68 49 layer_0; #X obj 68 69 layer_0; #X obj 68 89 layer_0; #X obj 68 109 layer_0; #X obj 68 129 layer_0; #X obj 68 149 layer_0; #X obj 68 169 layer_0; #X obj 68 189 layer_0; #X obj 68 209 layer_0; #X obj 68 230 layer_0; #X obj 68 250 layer_0; #X obj 68 270 layer_0; #X obj 128 9 layer_0; #X obj 128 29 layer_0; #X obj 128 49 layer_0; #X obj 128 69 layer_0; #X obj 128 89 layer_0; #X obj 128 109 layer_0; #X obj 128 129 layer_0; #X obj 128 149 layer_0; #X obj 128 169 layer_0; #X obj 128 189 layer_0; #X obj 128 209 layer_0; #X obj 128 230 layer_0; #X obj 128 250 layer_0; #X obj 128 270 layer_0; #X obj 188 9 layer_0; #X obj 188 29 layer_0; #X obj 188 49 layer_0; #X obj 188 69 layer_0; #X obj 188 89 layer_0; #X obj 188 109 layer_0; #X obj 188 129 layer_0; #X obj 188 149 layer_0; #X obj 188 169 layer_0; #X obj 188 189 layer_0; #X obj 188 209 layer_0; #X obj 188 230 layer_0; #X obj 188 250 layer_0; #X obj 188 270 layer_0; #X obj 248 9 layer_0; #X obj 248 29 layer_0; #X obj 248 49 layer_0; #X obj 248 69 layer_0; #X obj 248 89 layer_0; #X obj 248 109 layer_0; #X obj 248 129 layer_0; #X obj 248 149 layer_0; #X obj 248 169 layer_0; #X obj 248 189 layer_0; #X obj 248 209 layer_0; #X obj 248 230 layer_0; #X obj 248 250 layer_0; #X obj 248 270 layer_0; #X obj 308 9 layer_0; #X obj 308 29 layer_0; #X obj 308 49 layer_0; #X obj 308 69 layer_0; #X obj 308 89 layer_0; #X obj 308 109 layer_0; #X obj 308 129 layer_0; #X obj 308 149 layer_0; #X obj 308 169 layer_0; #X obj 308 189 layer_0; #X obj 308 209 layer_0; #X obj 308 230 layer_0; #X obj 308 250 layer_0; #X obj 308 270 layer_0; #X obj 368 9 layer_0; #X obj 368 29 layer_0; #X obj 368 49 layer_0; #X obj 368 69 layer_0; #X obj 368 89 layer_0; #X obj 368 109 layer_0; #X obj 368 129 layer_0; #X obj 368 149 layer_0; #X obj 368 169 layer_0; #X obj 368 189 layer_0; #X obj 368 209 layer_0; #X obj 368 230 layer_0; #X obj 368 250 layer_0; #X obj 368 270 layer_0; #N canvas 0 0 450 300 10; #X obj 8 9 layer_1; #X obj 8 29 layer_1; #X obj 8 49 layer_1; #X obj 8 69 layer_1; #X obj 8 89 layer_1; #X obj 8 109 layer_1; #X obj 8 129 layer_1; #X obj 8 149 layer_1; #X obj 8 169 layer_1; #X obj 8 189 layer_1; #X obj 8 209 layer_1; #X obj 8 230 layer_1; #X obj 8 250 layer_1; #X obj 8 270 layer_1; #X obj 68 9 layer_1; #X obj 68 29 layer_1; #X obj 68 49 layer_1; #X obj 68 69 layer_1; #X obj 68 89 layer_1; #X obj 68 109 layer_1; #X obj 68 129 layer_1; #X obj 68 149 layer_1; #X obj 68 169 layer_1; #X obj 68 189 layer_1; #X obj 68 209 layer_1; #X obj 68 230 layer_1; #X obj 68 250 layer_1; #X obj 68 270 layer_1; #X obj 128 9 layer_1; #X obj 128 29 layer_1; #X obj 128 49 layer_1; #X obj 128 69 layer_1; #X obj 128 89 layer_1; #X obj 128 109 layer_1; #X obj 128 129 layer_1; #X obj 128 149 layer_1; #X obj 128 169 layer_1; #X obj 128 189 layer_1; #X obj 128 209 layer_1; #X obj 128 230 layer_1; #X obj 128 250 layer_1; #X obj 128 270 layer_1; #X obj 188 9 layer_1; #X obj 188 29 layer_1; #X obj 188 49 layer_1; #X obj 188 69 layer_1; #X obj 188 89 layer_1; #X obj 188 109 layer_1; #X obj 188 129 layer_1; #X obj 188 149 layer_1; #X obj 188 169 layer_1; #X obj 188 189 layer_1; #X obj 188 209 layer_1; #X obj 188 230 layer_1; #X obj 188 250 layer_1; #X obj 188 270 layer_1; #X obj 248 9 layer_1; #X obj 248 29 layer_1; #X obj 248 49 layer_1; #X obj 248 69 layer_1; #X obj 248 89 layer_1; #X obj 248 109 layer_1; #X obj 248 129 layer_1; #X obj 248 149 layer_1; #X obj 248 169 layer_1; #X obj 248 189 layer_1; #X obj 248 209 layer_1; #X obj 248 230 layer_1; #X obj 248 250 layer_1; #X obj 248 270 layer_1; #X obj 308 9 layer_1; #X obj 308 29 layer_1; #X obj 308 49 layer_1; #X obj 308 69 layer_1; #X obj 308 89 layer_1; #X obj 308 109 layer_1; #X obj 308 129 layer_1; #X obj 308 149 layer_1; #X obj 308 169 layer_1; #X obj 308 189 layer_1; #X obj 308 209 layer_1; #X obj 308 230 layer_1; #X obj 308 250 layer_1; #X obj 308 270 layer_1; #X obj 368 9 layer_1; #X obj 368 29 layer_1; #X obj 368 49 layer_1; #X obj 368 69 layer_1; #X obj 368 89 layer_1; #X obj 368 109 layer_1; #X obj 368 129 layer_1; #X obj 368 149 layer_1; #X obj 368 169 layer_1; #X obj 368 189 layer_1; #X obj 368 209 layer_1; #X obj 368 230 layer_1; #X obj 368 250 layer_1; #X obj 368 270 layer_1;

2 1

make uninstall problem in bash with vanilla
by patco 03 Oct '08

03 Oct '08

hello, when I do 'make uninstall', bash still have a reference of pd being in /usr/local/bin (with using ./configure --prefix=/usr/local) $ pd bash: /usr/local/bin/pd: Aucun fichier ou dossier de ce type how could I remove this reference? thanks

2 1

build farm update: gusty becomes intrepid
by Hans-Christoph Steiner 01 Oct '08

01 Oct '08

Hey all, I updated the gutsy build machine machine to intrepid since it is about to be released. They did a big merge from Lenny/testing, so there are lots of changes. .hc ------------------------------------------------------------------------ ---- "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore

1 0

[ pure-data-Bugs-2127854 ] autobuild: partconv~
by SourceForge.net 01 Oct '08

01 Oct '08

Bugs item #2127854, was opened at 2008-09-25 03:55 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2127854&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Hans-Christoph Steiner (eighthave) Summary: autobuild: partconv~ Initial Comment: partconv~ has stopped the auto-builds for a rather long period now. please somene do one of the following: - remove [partconv~] from the auto-build system - install fftw on the auto-build machines - make the dependency on fftw optional ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-10-01 05:08 Message: I agree that partconv~ shouldn't be built if fftw3 isn't found, but that should be handled by the build system (i.e. something like ./configure), not the compiler. As for including it in Pd-extended, I think it is more useful to have a working partconv~ that is not perfectly optimized than none at all. People who can figure out how to build fftw3 for their CPU, then build partconv~ using that fftw3 can easily figure out how to replace the included partconv~. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-10-01 03:43 Message: ok i have reverted my change. however, the #ifdef's do not make the object more unuseable then how it already is, if fftw3 is missing, so i don't fully understand the arguing. attached is a simplified patch that fully disables the object when no HAVE_FFTW3_H is not defined (leaving only the _setup function to tell the user what went wrong) File Added: partconv~.diff ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2008-09-30 14:08 Message: FFTW is required for partconv~ to work so the #ifdef additions will make it unusable. FFTW is tricky to include with binaries since it has such extensive optimizations for each CPU. You could attempt to statically link a generic x87 version, but that would result in pretty poor performance and partconv~ needs really good code to work with longer impulse responses. I would recommend leaving it out of the autobuild and letting those who want it build it on their own. The other option would be to make some static linked binaries for various CPUs and stick them in the build ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-09-30 05:42 Message: does partconv~ work with out FFTW3? If this just builds a dummy object, I don't think it is useful to include this hack. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-09-30 03:43 Message: i have added a number of #ifdef's to the original code (i hope nobody minds), so now the object should compile again on systems without fftw3 installed. the drawback is, that you have to explicitely define the HAVE_FFTW3_H at the command-line in order to enable it! (so hack the externals/Makefile which i don't dare) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-09-26 12:00 Message: I am working on it, but I have limited access to that machine, since it is a lab machine of a university. Plus there are still some bugs in Apple's gcc causing fftw3 not to build., so hopefully that's been fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2127854&group_…

1 0

[ pure-data-Bugs-2127854 ] autobuild: partconv~
by SourceForge.net 01 Oct '08

01 Oct '08

Bugs item #2127854, was opened at 2008-09-25 09:55 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2127854&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Hans-Christoph Steiner (eighthave) Summary: autobuild: partconv~ Initial Comment: partconv~ has stopped the auto-builds for a rather long period now. please somene do one of the following: - remove [partconv~] from the auto-build system - install fftw on the auto-build machines - make the dependency on fftw optional ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-10-01 09:43 Message: ok i have reverted my change. however, the #ifdef's do not make the object more unuseable then how it already is, if fftw3 is missing, so i don't fully understand the arguing. attached is a simplified patch that fully disables the object when no HAVE_FFTW3_H is not defined (leaving only the _setup function to tell the user what went wrong) File Added: partconv~.diff ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2008-09-30 20:08 Message: FFTW is required for partconv~ to work so the #ifdef additions will make it unusable. FFTW is tricky to include with binaries since it has such extensive optimizations for each CPU. You could attempt to statically link a generic x87 version, but that would result in pretty poor performance and partconv~ needs really good code to work with longer impulse responses. I would recommend leaving it out of the autobuild and letting those who want it build it on their own. The other option would be to make some static linked binaries for various CPUs and stick them in the build ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-09-30 11:42 Message: does partconv~ work with out FFTW3? If this just builds a dummy object, I don't think it is useful to include this hack. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-09-30 09:43 Message: i have added a number of #ifdef's to the original code (i hope nobody minds), so now the object should compile again on systems without fftw3 installed. the drawback is, that you have to explicitely define the HAVE_FFTW3_H at the command-line in order to enable it! (so hack the externals/Makefile which i don't dare) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-09-26 18:00 Message: I am working on it, but I have limited access to that machine, since it is a lab machine of a university. Plus there are still some bugs in Apple's gcc causing fftw3 not to build., so hopefully that's been fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2127854&group_…

1 0

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 October 2008