I was wondering if anyone has made pd into a guitar effects processor and recording too. I was thinking that i could coble together a control structure to use all kinds off effect the community has already created and just run my audio in through them...then have an option for file output.

I just had this flash of insight...

A visual trace debugger could (probably, by someone more skilled than I) easily be programmed for PD. It would have the ability to trace through a patch as it executes...in real time or in slow motion. This would allow you to see how convoluted your control structures acutually are. I know PD can process multiple things at the same time...to get around this "pulses" of control flow would have to be used and you would end up with something like christmas lights blinking in a row.

I've been running pd on the older laptop i have here because I've never been able to get it to run on the win NT box. For some reason if I try to change the settings to get the sound card to work I get a memory error (which are common in win NT)...has anyone else had this problem? Do you know of a fix?

Ok, I've got a tricky one here. I'm setting up an experiment on pitch shift using wav files. I'd like to be able to pitch shift and preserve duration; in real time with sounds of indeterminate length. Is this asking too much or will it just take some time to work out? Any ideas?

In ./pd/docs/audio.examples/ the sampler patches are ones that take in soundfiles...

I got PD working on the amd64 machine and if used the 64 bit libs. Here is what i did:

1. i used pd-extended with the source from the pd-extended sourceforge page.
2. extract the archive somewhere...
3. enter puredata/bin and run ./configure
4. edit "Makefile" so that paths read /usr/X11R6/libs64, /usr/libs64, etc. (I believe there are three that you have to change.
5. make
6. run pd

The only problem i have so far (and it is a big one) is that it isn't reading the example files (bells, voice, and voice2) because it says they have malformed headers or something. I hope its just the files and not the program itself, because the work i do relies on bringing in sound files. Still, I think that if the program was broke i would have seen at least a warning when compiling.

eh, I was wrong. I did some poking around and found out that porting an app to be 64 bit can be much more difficult than it looks...depending on how it was written. In a 64 bit architecture certain variables are stored with a 64 bit word length and some with a 32 bit word length and when there is typecasting involved it gets even more complicated.

and if you want to learn to be the DSP master go here:
[url=http://crca.ucsd.edu/~msp/techniques/latest/book-html/node1.html ]http://crca.ucsd.edu/~msp/techniques/latest/book-html/node1.html

and learn from the master himself.

i believe you can try "make -m32" and it will make pd as a 32 bit binary....but you might want to "man make" to see what other switches there are.

not really a useful reply, but i'm having the same difficulties. I'm guessing that something in the source code specifically is written for the 32 architecture. For instance on a 32 bit machine integers and floats are a specific size but in a 64 bit machine that size is different. Perhaps Puckette has some variables that are created on a low level so that he has specified the size to be that which is normally used in a 32 bit environment.

Hopefully when (if) I get the time i can take a look at the source code and see if I can find anything out. A cursory look at x_gui.c says that the line in quesiton reads "sprintf(buf, "d%x", (t_int)x);" . sprintf is this buffer writting mechanism...here he is writting something into the buffer and converting it to his own type (t_int), through explicit type casting, in the process.

He defines t_int in m_pd.h where he takes care of making sure all the precompiler junk is squared away.
"#ifdef __alpha__
typedef long t_int;
#else
typedef int t_int;
#endif"

Perhaps someone with experience in multiple architectures could help...or perhaps someone wants to bug a pd-extended developer or even Puckette himself.

My guess at a solution is to get the compiler to use a 32 bit word ("word" is the term for the size a variable takes up) and not a 64 bit word for all variables. (not quite sure if this is really possible though). You might also try compiling it on a 32 bit machine and copying the whole pd directory over to your 64 and giving that a shot.

Also you may want to change the makefile so that it points entirely to ../libs64/ or entirely to ../libs/