Re: [PD-dev] missing file from pd-MAIN and fftw version
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___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
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
Re: [PD-dev] missing file from pd-MAIN and fftw version
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. --- [EMAIL PROTECTED] http://mccormick.cx ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] problems compiling pd-devel-0.39
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\" -DPA_USE_ALSA -DPA_USE_JACK -DUSEAPI_ALSA -DUSEAPI_JACK -DUSEAPI_PORTAUDIO -DPA19 -DNDEBUG -DHAVE_ALLOCA -D_LARGEFILE64_SOURCE -DPD_INTERNAL -I/usr/include/tcl8.4 -Isrc -Iportaudio/src/os/unix -Iportaudio/include -Iportaudio/src/common -c -o src/s_audio_pa.o src/s_audio_pa.c src/s_audio_pa.c:48: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/s_audio_pa.c:51: error: expected ';', ',' or ')' before '*' token src/s_audio_pa.c: In function 'pa_open_audio': src/s_audio_pa.c:61: error: 'pa_callback' undeclared (first use in this function) src/s_audio_pa.c:61: error: (Each undeclared identifier is reported only once src/s_audio_pa.c:61: error: for each function it appears in.) src/s_audio_pa.c:61: error: 'process' undeclared (first use in this function) src/s_audio_pa.c:142: error: 'PaStreamParameters' undeclared (first use in this function)src/s_audio_pa.c:142: error: expected ';' before 'inputParameters' src/s_audio_pa.c:145: error: 'inputParameters' undeclared (first use in this function) src/s_audio_pa.c:147: error: 'paNonInterleaved' undeclared (first use in this function) src/s_audio_pa.c:152: error: 'outputParameters' undeclared (first use in this function) src/s_audio_pa.c:165: warning: passing argument 5 of 'Pa_OpenStream' makes pointer from integer without a cast src/s_audio_pa.c:165: warning: passing argument 8 of 'Pa_OpenStream' makes integer from pointer without a cast src/s_audio_pa.c:165: error: too few arguments to function 'Pa_OpenStream' src/s_audio_pa.c:169: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token src/s_audio_pa.c:169: error: 'streaminfo' undeclared (first use in this function) src/s_audio_pa.c: At top level: src/s_audio_pa.c:226: error: expected ';', ',' or ')' before '*' token scons: *** [src/s_audio_pa.o] Error 1 scons: building terminated because of errors. ...any idea of what's wrong? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
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 -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
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
http://at.or.at/hans/
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
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 -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk A paranoid is a man who knows a little of what's going on. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
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 -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] corelibs, build system
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. I am getting really tired of you breaking the stuff that I spent a lot of time setting up. I really don't want to have to use ACLs in CVS, but you are leaving me no other choice. corelibs is a section that I set up and only I have worked on so far. You did not ask at all. d_mayer_fft.c is the name of the file in 0.39.2. You have broken compilation for Pd-extended. - please revert all changes to the docs/developer section - please revert all changes to externals/corelibs Let's start over and do this right. .hc On Sep 26, 2006, at 5:02 AM, IOhannes m zmoelnig wrote: 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 (externals/Makefile vs. externals/corelibs/Makefile) which makes it impossible for a make-noob like me, to generate the .c files in the makefile while calling make in /externals (it does work fine when i do just "make" in externals/corelibs. the reason is, that CORELIBS_OBJECTS is evaluated before the files are generated (which would result in NO objects, since there should be no .c files before generation) a simple solution would be, to call "make -c corelibs/ generate" and then "make -C corelibs/" from the externals/Makefile. obviously this does not work, since externals/corelibs/Makefile has no logic and instead uses externals/Makefile with the "corelibs" target (which would make my idea quite recursive). then again there is the horror of touching externals/Makefile at all: this huge file makes it quite hard/impossible to work on / fix several targets at the same time. e.g. yesterday i first worked on corelibs, then noticed that zexy won't build as it should, so i had to revert all the changes i had done to the Makefile (since it didn't yet work properly) so i could start fixing the zexy-build (which i understand better, and which i was pretty sure to be able to fix). so i ask this again: would it not be better to have the build-logic for each directory in a separate Makefile (which could be edited separately)? these Makefile could make use of a generic(!) Makefile which (e.g.) lives in externals/ this generic Makefile MUST NOT have any intelligence about the separate destination targets (e.g. no different logic for building "corelibs" or "hid"; just a generic "build" target); if such intelligence is needed, it should live in the projects subdirectory (externals/corelibs/Makefile) i would also like to know the exact reason for the pwd-magic (i just never ever needed such thing in any makefile i wrote, so i'm curious) mfg.asdr IOhannes ___ 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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
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 +, 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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
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 +, 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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
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___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
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 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
Re: [PD-dev] missing file from pd-MAIN and fftw version
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 -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] corelibs, build system
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 (externals/Makefile vs. externals/corelibs/Makefile) which makes it impossible for a make-noob like me, to generate the .c files in the makefile while calling make in /externals (it does work fine when i do just "make" in externals/corelibs. the reason is, that CORELIBS_OBJECTS is evaluated before the files are generated (which would result in NO objects, since there should be no .c files before generation) a simple solution would be, to call "make -c corelibs/ generate" and then "make -C corelibs/" from the externals/Makefile. obviously this does not work, since externals/corelibs/Makefile has no logic and instead uses externals/Makefile with the "corelibs" target (which would make my idea quite recursive). then again there is the horror of touching externals/Makefile at all: this huge file makes it quite hard/impossible to work on / fix several targets at the same time. e.g. yesterday i first worked on corelibs, then noticed that zexy won't build as it should, so i had to revert all the changes i had done to the Makefile (since it didn't yet work properly) so i could start fixing the zexy-build (which i understand better, and which i was pretty sure to be able to fix). so i ask this again: would it not be better to have the build-logic for each directory in a separate Makefile (which could be edited separately)? these Makefile could make use of a generic(!) Makefile which (e.g.) lives in externals/ this generic Makefile MUST NOT have any intelligence about the separate destination targets (e.g. no different logic for building "corelibs" or "hid"; just a generic "build" target); if such intelligence is needed, it should live in the projects subdirectory (externals/corelibs/Makefile) i would also like to know the exact reason for the pwd-magic (i just never ever needed such thing in any makefile i wrote, so i'm curious) mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
> 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
Re: [PD-dev] missing file from pd-MAIN and fftw version
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 fftwwait...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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
