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
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
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 -0400, Hans-Christoph Steiner wrote:
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
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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 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 -0400, Hans-Christoph Steiner wrote:
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
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
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 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).
last week frank and me were invited to a radio show (tech talk) about pd: we finally came to a point where the moderators got very confused, why fftw was NOT used in pd. so after a little generic explanation, frank and me looked at each other, and answered: "well, pd is very flexible: you could write an external that does fft's using fftw....wait...hmmm...why has nobody done this yet?"
and that is the question: why do we necessarily need the fftw based fft-objects in plain pd and cannot use externals?
so i ripped the fftw-code out of tim's patch and checked it into the cvs as /externals/fftw/. the objects are called [fftw~], [ifftw~], [rfftw~] and [rifftw~]
currently it seems like the code it is not really working, the only object that produced any reasonable result was [rfftw~]; i guess this can be easily fixed, but i don't have the time right now to investigate this any further.
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 loaded class raises itself over an already existing class. while he is using it to overwrite objects from other externals (e.g. iemmatrix's [matrix~]), i don't see any reason why this should not work with internals.
et voila, does this not sound good?
mfg.adsr IOhannes
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 loaded class raises itself over an already existing class. while he is using it to overwrite objects from other externals (e.g. iemmatrix's [matrix~]), i don't see any reason why this should not work with internals.
et voila, does this not sound good?
sounds good. maybe there should be some official policy on the overloading of internals?
mfg.adsr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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 +0000, carmen wrote:
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 loaded class raises itself over an already existing class. while he is using it to overwrite objects from other externals (e.g. iemmatrix's [matrix~]), i don't see any reason why this should not work with internals.
et voila, does this not sound good?
sounds good. maybe there should be some official policy on the overloading of internals?
mfg.adsr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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, "externing over" should be a feature on patch level. I'm thinking of something like the Python syntax for importing modules which basically has three forms:
import zexy # builtin fft: fft() # zexy's fft has to be called with prefix: zexy.fft()
from zexy import fftw # now fft() also calls zexy's fft: fft()
from zexy import * # again zexy's fft shadows the builtin fft: fft()
Ciao
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 appropriate and proven way to deal with this issue. Its already working in Pd on a basic level, and most of what's needed for a full-fledged namespace system is already implemented.
.hc
On Sep 26, 2006, at 9:41 AM, 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.
cheers Miller
On Tue, Sep 26, 2006 at 08:30:44AM +0000, carmen wrote:
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 loaded class raises itself over an already existing class. while he is using it to overwrite objects from other externals (e.g. iemmatrix's [matrix~]), i don't see any reason why this should not work with internals.
et voila, does this not sound good?
sounds good. maybe there should be some official policy on the overloading of internals?
mfg.adsr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
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 like x_arithmatic.c will be trickier, but this does not have to happen at once. It can happen incrementally.
.hc
On Sep 26, 2006, at 9:41 AM, 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.
cheers Miller
On Tue, Sep 26, 2006 at 08:30:44AM +0000, carmen wrote:
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 loaded class raises itself over an already existing class. while he is using it to overwrite objects from other externals (e.g. iemmatrix's [matrix~]), i don't see any reason why this should not work with internals.
et voila, does this not sound good?
sounds good. maybe there should be some official policy on the overloading of internals?
mfg.adsr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
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++'s "using namespace std"
Ciao
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 namespace std"
sorry for some 'implementation details', but this is not as trivial as it would be in a script language.
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 data). for the second solution the creation time of the import object would be crucial (which would also be a contrary to §2.6.2), or objects will have to be reloaded when import objects are created/destroyed, which would increase the complexity of the implementation quite a bit...
just my 1.95 ¢
cheers ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
A paranoid is a man who knows a little of what's going on. William S. Burroughs
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 data).
If you refer to the "patches should be understandable in printed form" principle: It's already violated as you don't know, which [prepend], [urn], [scale] etc. is used in a patch when it's only printed.
But, yes: This would be worse, if you wouldn't even know, which [+ ] object is used, depending on which namespace is active.
However I don't want to be forced to write patches like:
[pdcore/float] | [pdcore/mult 2] | [pdcore/osc~] |\ [pdcore/dac~]
Ciao
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 principle (as written by miller in the pd docs, §2.6.2. persistence of data).
If you refer to the "patches should be understandable in printed form" principle: It's already violated as you don't know, which [prepend], [urn], [scale] etc. is used in a patch when it's only printed.
What about if [import] had to be banged to do it's work. Then you could use IOhannes' [initbang] and a bunch of [t b b b b] to specify loading order.
But, yes: This would be worse, if you wouldn't even know, which [+ ] object is used, depending on which namespace is active.
However I don't want to be forced to write patches like:
[pdcore/float] | [pdcore/mult 2] | [pdcore/osc~] |\ [pdcore/dac~]
In my opinion, pdcore should always be imported by default. Maybe have this optional using a command line option.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
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't even know, by sending a message, what are the classes of the objects that will receive that message! Well, that's what Pd/Max has always been, it's one kind of late binding, and it's the basis of polymorphism, which is a feature (or a set of features) that are very much sought for, because they increase context-dependency, which makes the code shorter *and* allows you to configure the code by changing its context.
If you liken pd messages to function calls, their context is the objects that the messages are sent to; it's context-sensitive: the receiver _is_ the context (or from another point of view, the class of the receiver _is_ the context).
in the case of making a [+] object, the receiver is ;objectmaker because pd unifies class lookup and method lookup. Now why would it be a bad idea to make ;objectmaker replaceable by something else? It's not so clear to me, given how pd is already made.
However I don't want to be forced to write patches like: [pdcore/float]
If namespaces force you to write complete names all of the time, then there is no difference between that and just considering slashes as part of the name and not thinking about namespaces.
In that sense, Perl5's namespaces are bullshit, just more syntactic noise; while namespaces are actually implemented in Tcl, Python, Ruby, C++, Java, ...
(Perl5 really implements its "namespaces" hierarchically, but you can't feel it until you ask a namespace to list its contents... there are no other benefits to namespaces in Perl, that I know of)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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 name refers to, is called late binding.
I was referring only to the printed form of a patch: If the printout doesn't include any information about active namespaces, it will become very hard to read a patch.
However I don't want to be forced to write patches like: [pdcore/float]
If namespaces force you to write complete names all of the time, then there is no difference between that and just considering slashes as part of the name and not thinking about namespaces.
Exactly.
Ciao
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 decoupling of the name and the thing that the name refers to, is called late binding.
I was referring only to the printed form of a patch: If the printout doesn't include any information about active namespaces, it will become very hard to read a patch.
The namespaces could be stored as a property of the canvas, while [import] objects or [;pd-patch.pd import( messages would be the way to manipulate those stored properties.
.hc
However I don't want to be forced to write patches like: [pdcore/float]
If namespaces force you to write complete names all of the time, then there is no difference between that and just considering slashes as part of the name and not thinking about namespaces.
Exactly.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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 would be in a script language.
1. It's not that trivial in a "script" language
2. It's exactly as difficult in a "script" languages as in pd. (pd isn't as special as we may believe it is)
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 data).
in practice, a pd canvas may have all of those persistent states which are not part of the canvas' contents per se:
(x,y) origin of the canvas window (x,y) size of the canvas window (x,y) size of the gop (x,y) margin for gop (x1,y1,x2,y2) range for graphing font size gop flag gop rectangle flag
and in practice, IEMGUI has been integrated to pd itself 5 years ago, everybody takes them for granted, and they're full of violations of 2.6.2; it could even be argued that the nature and the goal of IEMGUI is to violate 2.6.2.
for the second solution the creation time of the import object would be crucial (which would also be a contrary to §2.6.2),
the creation time would be also important in the case of the first solution. (i don't see why it wouldn't.)
or objects will have to be reloaded when import objects are created/destroyed, which would increase the complexity of the implementation quite a bit...
this can be made in a semi-automatic way, e.g. an item in the Edit menu which would recreate all objects as if the patch had been reloaded from a file. This is roughly equivalent to Ctrl+A Ctrl+X Ctrl+V, but now the second solution is different in the sense that Ctrl+V would have to figure out namespaces in order to create its objects properly (!!).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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 some 'implementation details', but this is not as trivial as it would be in a script language.
It's not that trivial in a "script" language
It's exactly as difficult in a "script" languages as in pd. (pd isn't
as special as we may believe it is)
well, it is in one term ... scripting languages are written in a text file, that's parsed from the top to the bottom. _this_ is absolutely the same as with pd ... 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 ...
unlike other interpreted languages, changes to the patch are done immediately, i.e. after changing something in the patch, there is no need to reload the patch file (compared with python's 'reload' or recompiling with a langugage like c/c++).
what makes you think, that this is similar in text-based languages?
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage
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" language.
when talking about script languages, i was referring to text-based languages like, c, c++, tcl, ada, ruby, python, lisp, scheme and in some extend esoteric languages like whitespace or brainfuck ...
i used this term in contrary to graphical languages like max, jmax, pd or pnpd ...
cheers ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac
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 languages (except mainly C, C++, ObjC, Java, C#, VB). However those usually don't result in things that get dumped to files (with the notable exceptions of Smalltalk and SELF).
unlike other interpreted languages, changes to the patch are done immediately,
Smalltalk and SELF make changes effective immediately on a per-method basis. However, those languages don't really have a top-to-bottom parsing order unless you really insist to load the code from text files (which is not usual for Smalltalk and SELF).
i.e. after changing something in the patch, there is no need to reload the patch file (compared with python's 'reload' or recompiling with a langugage like c/c++).
What pd needs here is the decoupling of creators from the classname-table, in such a way that it is possible to know what is the t_class associated to a given name, so that pd can know whether an object needs to be recreated or not, depending on whether the t_class associated with a name has changed or not.
what makes you think, that this is similar in text-based languages?
What you just said clarifies the distinction that you wanted to make.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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 Python's "from pdcore import *" or C++'s "using namespace std"
sorry for some 'implementation details', but this is not as trivial as it would be in a script language.
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 data). for the second solution the creation time of the import object would be crucial (which would also be a contrary to §2.6.2), or objects will have to be reloaded when import objects are created/destroyed, which would increase the complexity of the implementation quite a bit...
Yes, that is a good principle, but its already violated in a number of places, like properties panels on GUI objects. Properties on a canvas probably makes sense for a namespace.
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].
For the next step, it could just change the loading statement, only affecting the load. Then we can test the idea out, and see whether its worth the effort of making it take effect immediately.
I guess realtime languages don't usually have namespaces. Anyone know of some examples?
.hc
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].
For the next step, it could just change the loading statement, only affecting the load. Then we can test the idea out, and see whether its worth the effort of making it take effect immediately.
yes ... it's just that someone has to volunteer to do that :)
I guess realtime languages don't usually have namespaces. Anyone know of some examples?
pnpd contains namespaces similar to python, although it still lacks an 'import'-facility ...
cheers ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
The aim of education is the knowledge, not of facts, but of values William S. Burroughs
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 the equivalent to Python's "from pdcore import *" or C++'s "using namespace std"
In Pd-extended ("standard" is just an example name):
* "-lib standard" works
* [import standard] as long as its the first object in the patch.
Both are far from perfect, but both are quite functional right now and could easily be included in pd-MAIN. Plus I am almost done writing a libdir loader to work with Pd 0.40, which is a cleaner implementation.
.hc
------------------------------------------------------------------------
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.
BTW, here's an idea that I consider interesting regarding namespaces. Currently, the objectmaker of pd holds all classnames of pd and maps them to creators using its methodtable. Now what if "the" objectmaker was just "an" objectmaker among others? Think: namespace = objectmaker.
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 creation of a [+] box crawls up a chain that leads back to the root namespace, if none of the objectmakers in the chain defines a + method.
That way, we avoid coding extra namespace-handling features and avoid creating a bunch of symbols with slashes in them and we reuse the features already in pd.
This idea should raise a few questions and a few eyebrows but I believe that it's an idea worth considering and which could pay off.
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 like x_arithmatic.c will be trickier, but this does not have to happen at once. It can happen incrementally.
I can't think of why x_arithmetic.c would be trickier, maybe you can explain. What I believe will be really trickier are things that are even more elementary to the pd language: [pd] [inlet] [outlet] [objectmaker] [canvasmaker] [struct] [loadbang].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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 namespacing without moving anything out of the root namespace.
BTW, here's an idea that I consider interesting regarding namespaces. Currently, the objectmaker of pd holds all classnames of pd and maps them to creators using its methodtable. Now what if "the" objectmaker was just "an" objectmaker among others? Think: namespace = objectmaker.
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 creation of a [+] box crawls up a chain that leads back to the root namespace, if none of the objectmakers in the chain defines a + method.
That way, we avoid coding extra namespace-handling features and avoid creating a bunch of symbols with slashes in them and we reuse the features already in pd.
This idea should raise a few questions and a few eyebrows but I believe that it's an idea worth considering and which could pay off.
Sounds like an interesting idea. But how does it map to the filesystem?
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 like x_arithmatic.c will be trickier, but this does not have to happen at once. It can happen incrementally.
I can't think of why x_arithmetic.c would be trickier, maybe you can explain. What I believe will be really trickier are things that are even more elementary to the pd language: [pd] [inlet] [outlet] [objectmaker] [canvasmaker] [struct] [loadbang].
Its trickier because of the build dependencies. As for [pd] [inlet] [outlet] [objectmaker] [canvasmaker] [struct] [loadbang], somethings need to be in the core of the language. Something like [import] would be needed too. Think reserved words.
.hc
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 creation of a [+] box crawls up a chain that leads back to the root namespace, if none of the objectmakers in the chain defines a + method.
Sounds like an interesting idea. But how does it map to the filesystem?
I don't have answers to everything, and in particular, not to that one.
The only recommendations that I'd make right away, are not how mapping to the filesystem will work when creating objects; I think that this can work the way pd or pd-extended works right now; the difference would be that the code for this, would be bound to namespace objects (objectmakers).
That way, one could add support for .zip (aka ".jar") files just by calling class_addanything. ok, maybe not that straightforward, but almost so.
Its trickier because of the build dependencies. As for [pd] [inlet] [outlet] [objectmaker] [canvasmaker] [struct] [loadbang], somethings need to be in the core of the language. Something like [import] would be needed too. Think reserved words.
Yes. They could be considered the basis of a pd microlanguage... but in another sense pd is already a microlanguage, as most of its functionality is already in chunks that are easy to separate from the pd kernel. What's left to do is to find where the line lies and to cut it there.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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 different methods defined in them?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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...
cheers Miller
On Wed, Sep 27, 2006 at 01:52:52AM -0400, Mathieu Bouchard wrote:
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 different methods defined in them?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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 2006, at 17:29, 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).
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...
cheers Miller
On Wed, Sep 27, 2006 at 01:52:52AM -0400, Mathieu Bouchard wrote:
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 different methods defined in them?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- David Plans Casal main at davidcasal dot com http://www.davidcasal.com
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 suggest certain implementations.
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's like, the top principle of extreme programming, though not said like that)
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.
Perhaps the new "declare" object (designed to be visible :)
How do you make Ctrl+V, [declare], namespaces and principle 2.6.2 work together?
could get new flags to manipulate the way object names are mapped to creators. Just an idea...
what do you mean?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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 features that you get "for free" in the sense that the amount of code that you have to write to get them is nearly zero, and sometimes exactly zero.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 9/27/06, Mathieu Bouchard matju@artengine.ca 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's like, the top principle of extreme programming, though not said like that)
This is similar the ADDIE principle that is often used in rapid prototyping for instructional design (http://en.wikipedia.org/wiki/ADDIE_Model).
~Kyle
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 as C calls to the Pd API directly (pd_fft, mayer_fft, etc) instead of as using [fft~].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
carmen -
Chris McCormick -
David Plans Casal -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Kyle Klipowicz -
Mathieu Bouchard -
Miller Puckette -
Tim Blechmann