does anyone know how the transition of lenny to stable is affecting this? also, that soup recipe is great!

actually, Pd cost me a job one time! a couple years ago I was interviewing for a video game tester position that was one or two days a week and sounded like a great way to fill in my schedule with some extra cash. unfortunately, since I put all my Pd, programming, and new media work on my resume, they thought I was over qualified, and that I would get bored and quit!

hey very cool! I did not know about this project thanks for the video.

I've been running PDa on my nokia n810 but I haven't had time to get scratchbox running to compile the latest version

I would remove those bangs after the metros. there's no real reason why you need to see them flash every 80ms, is there?

thinkpad x61 tablet that is running ubuntu hardy. intel core2 duo 1.8ghz, 4g ram. it does very well, but the multitouch screen is not as nice as it sounded, and not worth the loss in resolution I think.

was previously using apple 12" powerbook g4 1.25ghz, 1.25g ram running debian. that did pretty well, but started to choke a bit doing some heavy realtime stuff.

I think "lol" is in order here

hello again

I found another useful bit of info buried in my link collection

http://www.debian-administration.org/articles/531

happy patching

hey guys,

compiling on amd64 is still quite the trick right now. I have managed an attempt using these infos:

http://puredata.info/docs/developer/Debian/?searchterm=debian
http://www.mail-archive.com/pd-list@iem.at/msg13552.html

but I have not been really succesful yet..

the trouble is that many of the externals are not very 64bit friendly yet. the core pd-vanilla runs just fine though. you can find that in the package repositories.

you can install the 32bit version, but it is somewhat cumbersome, and honestly, might break some things.

install the base 32 bit libraries with:

aptitude install ia32-libs

install the pd-extended package with:

sudo dpkg -i --force-architecture pd-extended-0.XX.deb

and watch the output for errors. you will have to manually download and install the 32bit version of every library that it complains about not having, using this command:

sudo dpkg -x libfoo.deb /emul/ia32-linux

the emul directory might be different in ubuntu I'm not sure.

when you start pd, you will likely see more errors. track down the packages it complains about and manually install them as well.

the "right" way to do this is to install all of the libraries in a chroot, but that is more work that alot of people will want to put in.

if you are interested please read this:
http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292205

if you need help with this feel free to message or email me the info is in my profile here.

I find abstractions to be the only way to go in some patches. most of mine have names like: simple.delay, pitch.node, s.ch.send, s.panner, etc etc. you can probably guess what they do

when working with very large projects, I'm not sure I would be too happy if couldn't use abstractions with creation arguments. my 12 channel mixer with 8 stereo sends on each channel is a good example.

for organizing, I like to use this scheme:

~/pd/
---/abstractions/
---/patches/
------/hello/
---------/abstractions/
---------/hello.pd

where the "main" abstractions folder holds things like ch.send and simple.delay; things that are simple and will probably not change. also libraries of abstractions like the montreal users group go in here (which are very awesome btw thanks!)

abstractions that are likely to change, or really obscure ones that won't be used in other patches, go in their own folders in their respective patches directory.

hi chris,

the only way I know, is to type in the relative path when you create them, or add an absolute path in your pdsettings/pdrc file

of course, if someone has another way, I too would like to hear it =)