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!
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.
compiling on amd64 is still quite the trick right now. I have managed an attempt using these infos:
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:
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:
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.