Pd-dev December 2005

pd-dev@lists.iem.at

30 participants
90 discussions

[ pure-data-Patches-1371478 ] Minor define fix for MinGW
by SourceForge.net 02 Dec '05

02 Dec '05

Patches item #1371478, was opened at 2005-12-02 00:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1371478&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: bugfix Status: Open Resolution: None Priority: 5 Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: Minor define fix for MinGW Initial Comment: MinGW doesn't use the #pragmas that MSVC does, and throws a warning. Changing #ifdef NT to #ifdef _MSC_VER will make sure that the #pragmas are only used with compiling with MSVC and not MinGW or Cygwin. This patch is part of the Pd-0.38.4-extended builds and applies cleanly to .38.x and CVS HEAD in combination with all of the patches that I am currently using (in CVS at packages/patches). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1371478&group_…

1 0

[ pure-data-Patches-1055258 ] fftw support
by SourceForge.net 02 Dec '05

02 Dec '05

Patches item #1055258, was opened at 2004-10-27 08:52 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1055258&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 Submitted By: Tim Blechmann (timblech) Assigned to: Nobody/Anonymous (nobody) Summary: fftw support Initial Comment: this patch provides the possibility to use the fftw library instead of the builtin mayer fft ... fftw is at least twice as fast ... it is a compile-time feature, so pd can be compiled without the fftw ... ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2005-12-02 00:48 Message: Logged In: YES user_id=27104 This patch is safe since it does not enable any modified code unless you set the HAVE_LIBFFTW3F define. It would be nice to have the option to use FFTW already in the source. ---------------------------------------------------------------------- Comment By: Guenter Geiger (ggeiger) Date: 2005-05-18 03:47 Message: Logged In: YES user_id=430561 There is another fast FFT package called oura, i haven't benchmarked it personally, but it seems to be quite fast. Its a "one source file" FFT, so it could be used as a replacement for the meyer FFT (except, it computes RIRIRI instead of RRRIIII) http://momonga.t.u-tokyo.ac.jp/~ooura/fft.html No ALTIVEC or SSE support in it I fear. Guenter ---------------------------------------------------------------------- Comment By: christopher clepper (cclepper) Date: 2005-05-18 01:15 Message: Logged In: YES user_id=663212 I have used fftw on OSX and the Altivec version is many, many times faster than the Pd FFT. The installation was not too difficult, although there are tons of compile time options and the defaults are not usually the most efficient ones. For the port of partconv~ I just statically linked it for the binary, which added a few hundred Kbytes but it seems well worth it. Overall it looks like the FFT lib to adopt for any cross-platform app that requires efficient implementations on multiple architectures. The code compares quite well to commercial libs and applications. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2005-05-18 00:54 Message: Logged In: YES user_id=313747 I don't know what to do about this one. I don't use FFTW because it requires "configure" and I don't have a windows machine with CYGWIN, so wouldn't ever be able to test this. Perhaps it's for use with linux only? Rumor has it fftw is much faster than meyer, but I've never wanted to go to the hassle of learning how to install it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1055258&group_…

1 0

sloppy patches in the patch tracker
by Hans-Christoph Steiner 02 Dec '05

02 Dec '05

I've noticed that a lot of the patches that are submitted to the patch tracker are quite sloppy. This makes them much less likely to be incorporated into the core. Here's a couple guidelines which should help: - use diff -uw (-u provides context, which is good for humans and the patch program. -w ignores whitespace changes) - the patch should only included changes that are relevant. There should be no other changes, include whitespace changes in the patch. - the patch should be for one feature. It is much easier to figure out what's what, and then it will less likely be skipped because one feature in a multi-feature patch was nixed. Way back at pd~conf, we all agreed to give this a shot, I think it can really work, but everyone has to do their bit. Do you think Linux Torvalds reads sloppy, untested patches? I think Linux has a well established model which we can emulate on a smaller scale. .hc ________________________________________________________________________ ____ If you are not part of the solution, you are part of the problem. - Eldridge Cleaver

1 0

[ pure-data-Patches-1371467 ] backwards compatible makefile.in cleanup
by SourceForge.net 02 Dec '05

02 Dec '05

Patches item #1371467, was opened at 2005-12-02 00:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1371467&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: bugfix Status: Open Resolution: None Priority: 7 Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: backwards compatible makefile.in cleanup Initial Comment: I cleaned up makefile.in so that it follows the GNU standards for configure variables. Plus I added a couple variables which allows the install target to work properly across platforms. This has the added benefit of making it easier to compile Pd from the Pd-extended build system. Tested on Pd-0.38.3 and 0.38.4 on all platforms and applies cleanly to the HEAD of pd in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1371467&group_…

1 0

proposed externals/build/src changes
by Hans-Christoph Steiner 02 Dec '05

02 Dec '05

I would like to incorporate the functionality in externals/build/*/makefile into the Pd-extended build, i.e. externals/Makefile. I would like to reorganize things so that we can take advantage of the namespace. This would mean that file locations would change. Plus, externals/Makefile builds for linux, darwin, and MinGW, so externals/build/*/makefile would not be needed anymore. Anyone can add Irix, BSD, etc. to externals/Makefile too, it should be pretty easy. MSVC might be trickier unless it can follow UNIX-style paths. Besides the debian packaging, is anyone else relying on the current setup? I want to break as little as possible in this process. .hc ________________________________________________________________________ ____ Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams

1 0

sethelpsymbol in Externals HOWTO
by Hans-Christoph Steiner 02 Dec '05

02 Dec '05

A lot of people think that class_sethelpsymbol is required, so some minor changes to the Externals-HOWTO would be good: http://iem.kug.ac.at/pd/externals-HOWTO/node5.html Could you change this line to match the standard format: class_sethelpsymbol(counter_class, gensym("help-counter")); To this: class_sethelpsymbol(counter_class, gensym("counter-help")); Also, a blurb like this would be good: "By default, Pd will look for a help patch based on the name of the class. An alternative help patch can be defined with the class_sethelpsymbol command." .hc ________________________________________________________________________ ____ If you are not part of the solution, you are part of the problem. - Eldridge Cleaver

1 0

SIMD for core Pd objects vs. my crappy C
by Hans-Christoph Steiner 02 Dec '05

02 Dec '05

So I just had a thought, perhaps its not an original one. I was thinking that if the core Pd objects were well optimized, using SIMD and all that good stuff, then the objects I write in Pd might actually be comparable in speed to the objects I write in plain C (I'm no assembly programmer). So on that topic, how hard would it be to make patches for the SIMD stuff that would apply to MSP's sources? .hc ________________________________________________________________________ ____ Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli

4 4

RRADical moving to 0.39!
by Frank Barknecht 01 Dec '05

01 Dec '05

Hi, this is just a warning message: I'm about to finally do a radical change of RRADical in probably the next two weeks, that is, the move to 0.39. That means, all future versions of RRADical will absoluetly require Pd in a version >= 0.39. All Pd packages which still are based on 0.38 will then not be able to use the CVS-HEAD of RRADical! Background is, that I want to use the new way of GOP and a lot of [list] stuff. I'm open for suggestions on how to create an "archive" of the old patches. As I also want to move all RRADical patches except core-memento to a single directory, I guess I will just tag the current state once, and then go crazy. So, please consider any support for RRADical on 0.38 stopping at this point. Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__

3 4

need access to a AMD64? PowerPC?
by Hans-Christoph Steiner 01 Dec '05

01 Dec '05

Check out SourceForge's compile farm, they have two AMD64's running Fedora Core 3. I am trying a build now. You can also get access to some x86, PowerPCs, Alpha, etc. running OSX Server, FreeBSD, OpenBSD and other GNU/Linux flavors. http://sourceforge.net/docman/display_doc.php? docid=762&group_id=1#cf_overview I am starting in on an automated build system that'll email us when things don't compile... .hc ________________________________________________________________________ ____ ¡El pueblo unido jamás será vencido!

3 5

hammer/accum error on AMD64
by Hans-Christoph Steiner 01 Dec '05

01 Dec '05

The first AMD64 issue: gcc -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -O6 -funroll-loops -fomit-frame-pointer -fno-strict-aliasing -DUNIX -I . -I ../../../pd/src -I ../shared -c -o hammer/accum.o hammer/accum.c gcc -o /home/users/e/ei/eighthave/cvs/pure-data/packages/linux_make/build// usr/local/lib/pd/extra/cyclone/accum.pd_linux -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -O6 -funroll-loops -fomit-frame-pointer -fno-strict-aliasing -DUNIX -I . -I ../../../pd/src -I ../shared -export_dynamic -shared hammer/accum.o /usr/bin/ld: hammer/accum.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC hammer/accum.o: could not read symbols: Bad value Shouldn't all externals be compiled with -fPIC on Linux? I know Darwin/Mac OS X compiles DLLs as -fPIC by default. .hc ________________________________________________________________________ ____ ¡El pueblo unido jamás será vencido!

2 2

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 December 2005