Pd-dev January 2006

pd-dev@lists.iem.at

27 participants
100 discussions

[ pure-data-Patches-1055258 ] fftw support
by SourceForge.net 17 Jan '06

17 Jan '06

Patches item #1055258, was opened at 2004-10-27 14:52 Message generated for change (Comment added) made by timblech 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: Miller Puckette (millerpuckette) 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: Tim Blechmann (timblech) Date: 2006-01-17 18:36 Message: Logged In: YES user_id=326084 hans, i think that after having a look at the patch, adapting (insert you favorite build system here) is more than trivial miller, scons has autoconf functionality for multiple platforms including windows, linux & osx ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-01-17 14:43 Message: Logged In: YES user_id=27104 I forgot to mention, this patch is incomplete. It includes all the FFTW code, but no way to enable the compilation of it. Ideally, FFTW would be added to the configure.in/Makefile.in ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-01-17 14:41 Message: Logged In: YES user_id=27104 http://www.fftw.org/install/windows.html According to that website, it sounds like FFTW builds fine with SSE on MinGW. So that should work well, since everything else in CVS builds with MinGW too. ---------------------------------------------------------------------- Comment By: Ed Kelly (edkelly) Date: 2006-01-17 14:10 Message: Logged In: YES user_id=1322859 Have you checked out the Windows binaries of FFTW3 at http://www.fftw.org/install/windows.html ? Maybe it's a hassle, but there are build files for VC6 and precompiled binaries...perhaps the problems mentioned on this page with SIMD instructions would be addressed by a more recent MSVC, but I only have MSVC6 so I can't check this... Ed ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2005-12-02 06: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 09: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 07: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 06: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

[ pure-data-Patches-1055258 ] fftw support
by SourceForge.net 17 Jan '06

17 Jan '06

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: Miller Puckette (millerpuckette) 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: 2006-01-17 08:43 Message: Logged In: YES user_id=27104 I forgot to mention, this patch is incomplete. It includes all the FFTW code, but no way to enable the compilation of it. Ideally, FFTW would be added to the configure.in/Makefile.in ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-01-17 08:41 Message: Logged In: YES user_id=27104 http://www.fftw.org/install/windows.html According to that website, it sounds like FFTW builds fine with SSE on MinGW. So that should work well, since everything else in CVS builds with MinGW too. ---------------------------------------------------------------------- Comment By: Ed Kelly (edkelly) Date: 2006-01-17 08:10 Message: Logged In: YES user_id=1322859 Have you checked out the Windows binaries of FFTW3 at http://www.fftw.org/install/windows.html ? Maybe it's a hassle, but there are build files for VC6 and precompiled binaries...perhaps the problems mentioned on this page with SIMD instructions would be addressed by a more recent MSVC, but I only have MSVC6 so I can't check this... Ed ---------------------------------------------------------------------- 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

[ pure-data-Patches-1055258 ] fftw support
by SourceForge.net 17 Jan '06

17 Jan '06

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: Miller Puckette (millerpuckette) 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: 2006-01-17 08:41 Message: Logged In: YES user_id=27104 http://www.fftw.org/install/windows.html According to that website, it sounds like FFTW builds fine with SSE on MinGW. So that should work well, since everything else in CVS builds with MinGW too. ---------------------------------------------------------------------- Comment By: Ed Kelly (edkelly) Date: 2006-01-17 08:10 Message: Logged In: YES user_id=1322859 Have you checked out the Windows binaries of FFTW3 at http://www.fftw.org/install/windows.html ? Maybe it's a hassle, but there are build files for VC6 and precompiled binaries...perhaps the problems mentioned on this page with SIMD instructions would be addressed by a more recent MSVC, but I only have MSVC6 so I can't check this... Ed ---------------------------------------------------------------------- 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

[ pure-data-Patches-1055258 ] fftw support
by SourceForge.net 17 Jan '06

17 Jan '06

Patches item #1055258, was opened at 2004-10-27 13:52 Message generated for change (Comment added) made by edkelly 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: Miller Puckette (millerpuckette) 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: Ed Kelly (edkelly) Date: 2006-01-17 13:10 Message: Logged In: YES user_id=1322859 Have you checked out the Windows binaries of FFTW3 at http://www.fftw.org/install/windows.html ? Maybe it's a hassle, but there are build files for VC6 and precompiled binaries...perhaps the problems mentioned on this page with SIMD instructions would be addressed by a more recent MSVC, but I only have MSVC6 so I can't check this... Ed ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2005-12-02 05: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 08: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 06: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 05: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

building OSCx on Windows
by Hans-Christoph Steiner 17 Jan '06

17 Jan '06

Has anyone gotten OSCx to build completely on Windows using MinGW? The ./configure && make compiles everything, and makes the single objects fine, but it just doesn't link the OSC.dll library. I'd like to find the fixes and put them in CVS, so that the MinGW builds will automatically build OSC too. This is the stage where the error is: gcc -shared -o OSC.dll OSC.o sendOSC.o dumpOSC.o OSCroute.o htmsocket.o OSC-pattern-match.o OSC-system-dependent.o -L../../../pd/bin -lpd -lm -lwsock32 ../libOSC/libOSC.a Info: resolving _s_float by linking to __imp__s_float (auto-import) OSC.o: In function `OSC_setup': C:/msys/1.0/home/hans/cvs/pure-data/externals/OSCx/src/OSC.c:61: undefined reference to `_imp__sendOSC_setup' C:/msys/1.0/home/hans/cvs/pure-data/externals/OSCx/src/OSC.c:62: undefined reference to `_imp__dumpOSC_setup' C:/msys/1.0/home/hans/cvs/pure-data/externals/OSCx/src/OSC.c:63: undefined reference to `_imp__OSCroute_setup' collect2: ld returned 1 exit status make[1]: *** [OSC.dll] Error 1 make[1]: Leaving directory `/home/hans/cvs/pure-data/externals/OSCx/src' make: *** [all] Error 2 Its very strange since sendOSC.o, dumpOSC.o, and OSCroute.o are all included. .hc ________________________________________________________________________ ____ "Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies." - Amy Smith

3 6

[ pure-data-Patches-1055258 ] fftw support
by SourceForge.net 17 Jan '06

17 Jan '06

Patches item #1055258, was opened at 2004-10-27 08:52 Message generated for change (Settings changed) 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: Miller Puckette (millerpuckette) 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

floating point exception while compiling devel
by Ed Kelly 16 Jan '06

16 Jan '06

...on a Pentium M 1.6, Fedora Core 3, gcc-3.3 and scons 0.96.1.D001 Don't know if the output is any use, but the preprocessed compiler output is enclosed. It was in module u_pdreceive.o that the error occurred. Best Ed -> -> --> ---> -----> --------> -------------> r3search + praktik EK5perimenz --------------------------------- To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.

2 1

[ pure-data-Patches-1403917 ] bind abtraction-canvas to full classname
by SourceForge.net 16 Jan '06

16 Jan '06

Patches item #1403917, was opened at 2006-01-12 15: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=1403917&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: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: bind abtraction-canvas to full classname Initial Comment: each abstraction-canvas is bound to a receive-symbol, based on the abstraction name, which enables you to send special messages to the canvas (like "vis 1") e.g. [foo] will be bound to "pd-foo.pd"; however, when the abstraction is created with a path-name, this is not reflected. e.g. [foo/bar] will be bound to "pd-bar.pd" this is unfortunate if you are using multiple abstractions of the same name within different directories, like [foo/bar] and [task/bar] (both will listen to "pd-bar.pd") the attached patch will modify g_canvas.c and m_class.c to additionally bind the abstraction's canvas to the full classname of the abstraction, with "pd-" prepended in the given example this means, that [foo/bar] will be bound to "pd-foo/bar" and [task/bar] will be bound to "pd-task/bar" caveat: no ".pd" is suffixed, since the full classname does not hold any file-suffixes. i do not consider this too bad, but who knows. what for?: i need this for a general framework where people can write their own modules that will be saved within a directory; the entry-point to each module is an abstraction with the same name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1403917&group_…

7 33

[ pure-data-Bugs-1285041 ] writesf_open bug
by SourceForge.net 13 Jan '06

13 Jan '06

Bugs item #1285041, was opened at 2005-09-08 17:49 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1285041&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: Fixed Priority: 5 Submitted By: Georg Holzmann (grholzi) Assigned to: Nobody/Anonymous (nobody) Summary: writesf_open bug Initial Comment: in a construction like this [savepanel] | [open $1( | [writesf~] clicking directly on the [open( message kills Pd gdb output: 0x080e7512 in writesf_open (x=0x811af68, s=0x81137e8, argc=1, argv=0x80f92d0) at d_soundfile.c:2312 2312 x->x_filename = filesym->s_name; ---------------------------------------------------------------------- >Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2006-01-13 21:00 Message: Logged In: YES user_id=564396 fixed in 0.39-2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1285041&group_…

1 0

[ pure-data-Patches-1403917 ] bind abtraction-canvas to full classname
by SourceForge.net 13 Jan '06

13 Jan '06

Patches item #1403917, was opened at 2006-01-12 15:26 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1403917&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: wishlist Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmÃ¶lnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: bind abtraction-canvas to full classname Initial Comment: each abstraction-canvas is bound to a receive-symbol, based on the abstraction name, which enables you to send special messages to the canvas (like "vis 1") e.g. [foo] will be bound to "pd-foo.pd"; however, when the abstraction is created with a path-name, this is not reflected. e.g. [foo/bar] will be bound to "pd-bar.pd" this is unfortunate if you are using multiple abstractions of the same name within different directories, like [foo/bar] and [task/bar] (both will listen to "pd-bar.pd") the attached patch will modify g_canvas.c and m_class.c to additionally bind the abstraction's canvas to the full classname of the abstraction, with "pd-" prepended in the given example this means, that [foo/bar] will be bound to "pd-foo/bar" and [task/bar] will be bound to "pd-task/bar" caveat: no ".pd" is suffixed, since the full classname does not hold any file-suffixes. i do not consider this too bad, but who knows. what for?: i need this for a general framework where people can write their own modules that will be saved within a directory; the entry-point to each module is an abstraction with the same name. ---------------------------------------------------------------------- >Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2006-01-13 20:11 Message: Logged In: YES user_id=564396 as discussed on the list, it should be considered removing the compatibility binding to the file-name. e.g. [foo/bar] binds to "pd-foo/bar.pd" and [pizza/bar] binds to "pd-pizza/bar.pd" but none of them binds to [pd-bar.pd] i don't give a patch for this, since the change is simple (just remove 1 (or 2) lines), and the decision should be made by somebody responsible. ---------------------------------------------------------------------- Comment By: IOhannes m zmÃ¶lnig (zmoelnig) Date: 2006-01-13 10:04 Message: Logged In: YES user_id=564396 a refined patch "bind2classname.pd.diff" now also adds ".pd" to the full classname, regardless of what the actual file-extension is. it uses addfileextent(). so now [foo/bar] will bind to "pd-foo/bar.pd" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1403917&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
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 January 2006