On Wed, 27 Sep 2006, Hans-Christoph Steiner wrote:
On Sep 27, 2006, at 2:32 AM, Mathieu Bouchard wrote:
For example, each patch gets its own objectmaker, and each objectmaker has
a class_addanything which causes a fallback of any unknown classname to a
parent namespace. Eventually, asking for c
On Sep 27, 2006, at 3:53 AM, Frank Barknecht wrote:
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 27 Sep 2006, Frank Barknecht wrote:
But, yes: This would be worse, if you wouldn't even know, which [+ ]
object is used, depending on which namespace is active.
The d
> Loading from a file shouldn't be too hard, the file could be loaded
> into memory, reordered as necessary, then executed. The hard part
> would be when inserting an [import] statement into a patch, if that
> is going to take effect immediately and reload objects based on that
> [import].
On Sep 27, 2006, at 2:32 AM, Mathieu Bouchard wrote:
On Tue, 26 Sep 2006, 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).
I should add, that it should be possible to achieve proper
nam
On Sep 26, 2006, at 5:46 PM, Tim Blechmann wrote:
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 Pyth
On 9/27/06, Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
I don't consider that interface design is something that strictly precedes
implementation design; rather, both are interacting in a feedback loop, if
the people involved are willing to make both the interface and
implementation evolve. (that
On Wed, 27 Sep 2006, Tim Blechmann wrote:
the difference is, pd patches are not written in a text editor (at
least, this is the usual case, i know, it's possible) and the parsing
order is not transparent to the user ...
Right, that's it. There are interactive interpreters/compilers, for most
On Wed, 27 Sep 2006, Mathieu Bouchard wrote:
If the implementation involves a network of objectmakers, this is an
opportunity to later add more namespace features that are logical
consequences of how that style of implementation.
typo, remove the "how".
what i mean by "logical consequences"
On Wed, 27 Sep 2006, Miller Puckette wrote:
It's probably all the same if there's one objectmaker that changes its
behavior or if there are several (just an inplementation question).
I'm talking about the implementation because implementations suggest
certain interfaces just like interfaces s
Hi all,
Sorry if I'm just increasing noise to signal ratio, but how will
authors who at the moment use frameworks such as Flext, which use the
inherited pd FFT (at this point) use fftw if you separate it in the
ways you're talking about? I may be missing the point of course.
d
On 27 Sep
It's probably all the same if there's one objectmaker that changes its
behavior or if there are several (just an inplementation question).
Perhaps the new "declare" object (designed to be visible :) could get
new flags to manipulate the way object names are mapped to creators.
Just an idea...
che
On Wed, 2006-09-27 at 12:00 +0200, IOhannes m zmoelnig wrote:
> Tim Blechmann wrote:
>
> > what makes you think, that this is similar in text-based languages?
>
> i think "script" language here did not mean "text-based" language
> (ignoring the etymology of "script"), but rather "interpreted" l
Tim Blechmann wrote:
what makes you think, that this is similar in text-based languages?
i think "script" language here did not mean "text-based" language
(ignoring the etymology of "script"), but rather "interpreted" language.
mfg.adsr
IOhannes
On Wed, 2006-09-27 at 03:05 -0400, Mathieu Bouchard wrote:
> On Tue, 26 Sep 2006, Tim Blechmann wrote:
> > On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote:
> >> IMO this step should wait until we have the equivalent to Python's
> >> "from pdcore import *" or C++'s "using namespace std"
> >
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
> On Wed, 27 Sep 2006, Frank Barknecht wrote:
>
> >But, yes: This would be worse, if you wouldn't even know, which [+ ]
> >object is used, depending on which namespace is active.
>
> The decoupling of the name and the thing that the
On Wed, 27 Sep 2006, Frank Barknecht wrote:
But, yes: This would be worse, if you wouldn't even know, which [+ ]
object is used, depending on which namespace is active.
The decoupling of the name and the thing that the name refers to, is
called late binding.
Wouldn't it be bad if you wouldn
On Tue, 26 Sep 2006, Tim Blechmann wrote:
On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote:
IMO this step should wait until we have the equivalent to Python's
"from pdcore import *" or C++'s "using namespace std"
sorry for some 'implementation details', but this is not as trivial as
it
On Tue, 26 Sep 2006, 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).
I should add, that it should be possible to achieve proper namespacing
without moving anything out of the root namespace
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 differ
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
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
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 th
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 "us
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 C
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 more
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 l
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 a
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.
cheers
Miller
On Tue, Sep 26, 2006 at 08:30:44AM +, carmen wrote:
> > and that is the questi
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 th
> 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
>
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 wai
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 wait for
fftw-4 or 5.
I didn't li
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 wait for
fftw-4 or 5.
I didn't like the way it was done in devel (with lots of fftw-specific
stuff in d_fft.c).
cheers
Miller
On Mon, Sep 25, 2006 at 10:22:48PM -040
I am trying to compile the HEAD of MAIN with --enable-fftw, and I
found that the CVS is missing a file: d_fft_fftw.c
Also, I was wondering why pd 0.40 uses fftw 2 rather than 3. fftw3
sounds like it would be much quicker since it uses sse/altivec.
.hc
--
34 matches
Mail list logo
