Bugs item #1563095, was opened at 2006-09-21 12:13
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=478070aid=1563095group_id=55736
Please note that this message will contain a full copy of the comment
Hans-Christoph Steiner wrote:
It would be very nice to have FFTW in Pd, its really much much faster.
.hc
On Sep 25, 2006, at 10:38 PM, Miller Puckette wrote:
Well, I started coding for fftw-2, then found out it had already been
replaced with fft-3, then decided that perhaps I should just
and that is the question: why do we necessarily need the fftw based
fft-objects in plain pd and cannot use externals?
so the only drawback is see is: the objects are called [fftw~] instead of
[fft~]; but lo and behold, i vaguely remembered krzysztof magic in cyclone,
where a newly
corelibs is currently broken due to a renaming of pd/src/d_mayer_fft.c
to pd/src/d_fft_mayer.c
while i updated the corelibs/generate.sh script to handle this, it still
does not really work with the autobuild-system.
the reason for this is (imo) the very complicated stacking of Makefiles
Hallo,
Miller Puckette hat gesagt: // Miller Puckette wrote:
Yes indeed. I'm thinking of automatically having new classes shadow old ones,
so that anything in Pd could simpy be externed over. Not sure of all the
long-term ramifications, but I like the idea.
Namespaces, anyone? ;)
I think,
On Tue, 26 Sep 2006, IOhannes m zmoelnig wrote:
and that is the question: why do we necessarily need the fftw based
fft-objects in plain pd and cannot use externals?
The main reason for not doing so is that it doesn't allow you to override
the uses of FFT that are made in other Pd externals
I should add, the next key step is to remove as many classes as
possible from the root namespace (i.e. compiled into Pd). For many,
it would be trivial to do, just compile them as individual objects in
a libdir. I've already done this for x_list.c, x_net.c, and a couple
others. Things
Using loading order will have similar problems whether you use the
first loaded or the last loaded. And changing the order of
precedence will have lots of unintended consequences.
Modern programming languages use namespaces (C++, Python, Java,
SmallTalk, etc). Namespaces are a much
IOhannes, PLEASE PLEASE PLEASE PLEASE PLEASE! ASK BEFORE YOU
MESS WITH SOMEONE ELSE'S STUFF!!! This is one of the most basic
and fundamental rules of working together, and you are violating this
rule again and again, though we ask you not to! That is why we have
this list.
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I should add, the next key step is to remove as many classes as
possible from the root namespace (i.e. compiled into Pd).
IMO this step should wait until we have the equivalent to Python's
from pdcore import * or
On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote:
I should add, the next key step is to remove as many classes as
possible from the root namespace (i.e. compiled into Pd).
IMO this step should wait until we have the equivalent to Python's
from pdcore import * or C++'s using
On Sep 26, 2006, at 5:21 PM, Frank Barknecht wrote:
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I should add, the next key step is to remove as many classes as
possible from the root namespace (i.e. compiled into Pd).
IMO this step should wait until we have
Hallo,
Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i can think of two ways to implement a namespace:
- a property of the canvas
- a |using| or |import| object
the first solution would be a contrary to pd's design principle (as
written by miller in the pd docs, ยง2.6.2. persistence of
hi,
I'm trying to compile pd-devel-0.39 on a FC5+ccrma laptop but I get this
error:
[...]
gcc -O3 -mfpmath=sse -mmmx -msse -fprefetch-loop-arrays -DPD -DDL_OPEN
-DHAVE_LIBFFTW3F -DNEWHASH -DLOCKFREE -DPABLIO -DUNISTD -DUNIX
-DUSEAPI_OSS -DPA_LITTLE_ENDIAN -DINSTALL_PREFIX=\/usr/local\
On Wed, Sep 27, 2006 at 12:15:21AM +0200, Frank Barknecht wrote:
Hallo,
Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i can think of two ways to implement a namespace:
- a property of the canvas
- a |using| or |import| object
the first solution would be a contrary to pd's design
On Tue, 26 Sep 2006, Miller Puckette wrote:
Yes indeed. I'm thinking of automatically having new classes shadow old ones,
so that anything in Pd could simpy be externed over. Not sure of all the
long-term ramifications, but I like the idea.
How about having several objectmakers with
16 matches
Mail list logo
