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
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
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 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
sorry for
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
___
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...
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
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 is
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 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
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
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
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
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
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
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
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
25 matches
Mail list logo
