hi all,
last release was a joke. really. from now on it's serious. thanks to aymeric, rama, yves & artem for testing.
pdp 0.13 is an unstable intermediate release based on packet forth (libtile/libpdp). if you use pd/pdp/pidip to make a living, stick with 0.12 for a while. especially libtile (the image processing engine) is still very experimental.
gemheads, see at the bottom of the page.
stuff below is a lotta verbose yada.
PF
the only real extra feature 0.13 brings is packet forth. packet forth (pf) is like mole, only more highlevel. a forth interpreter working with packets (and strings and network streams and other subprocesses etc...)
pf's core (packets + forth interpreter) is now reasonably stable. it's been a while since i found a bug there, but there are still a whole lot of small bugs in the modules. i'm hunting them down atm. major pain is that 3dp (opengl drawing) still does not work.
DOC
one thing you can do with the forth is to write pd objects that can communicate with other pd/pdp/pidip objects. in the same spirit as Thomas' py/pyext objects for python. the advantage of pf is that the language is tailored for real-time use, python is not.
it also has support for video, audio (there are dsp2pdp~ and pdp@dsp objects that enable you to convert audio streams to pdp vector packets) and other data types. vectors can be operated on using matrix operations and other functions from gsl. yeah, it's just the old pdp in a new jacket.
the disadvantage is that pf is of course a forth, and not even a standard forth.
now pf is linked to guile already, and a link to python will hopefully happen soon after most of the bugs for the current features are fixed, so there is hope.
i'm working on some docs to explain how to get started. this is in doc/pf.xml (convert this to html using 'xmlto xhtml pf.xml'). it's pretty raw.
to see some example objects written in pf, have a look at the files in /usr/local/lib/pdp/script/puredata
these can be loaded in pd with [pdp <name>] you can load an arbitrary script with [pf <filename>] 3dp works like this too [3dp <object>], but is not working atm.
eventually, i plan to write a whole lot of extra pdp modules, there is a lot of functionality in pf which just needs to be combined and exported as pdp modules. there's not much of them right now, because the language has been continuously in flux, breaking everything again. in 0.14 it will be frozen and backward compatible. the pdp 0.12 api (which pidip uses) will remain there until the end of the fishing season.
BUILD
last week i kicked out the autotools and replaced them with a very small perl script. most of the configure&build process is the same as it was before, only that libpdp is now 2-pass (libpdp compile+install and pf+plugins compile+install). to do this in one go, use
make all_install
after running (./bootstrap and) ./configure in the libpdp dir.
this builds and installs libpdp and the plugins. by default all the plugins try to build, and only those that succeed will be installed. this seems like the least hassle. it's very straightforward. each plugin needs its set of libraries. most is the same as pdp 0.12.x
if something fails, you can check build/build.log for details. all the error messages of the build are dumped there. most build problems seem to be fixed now. if you encounter any, please email me the build.log file.
CVS
distribution is still CVS only. see http://zwizwa.fartit.com/pd/pdp/doc/ for details.
GCC
small note on libtile (small virtual machine for image tile processing).
this makes extensive use of some gcc vector extensions and agressive inlining and optimization. some versions of gcc seem to choke on this. i use gcc.real (GCC) 3.3.4 (Debian 1:3.3.4-6sarge1) which seems to work, but i had to navigate around a bug.
problems are reported with these versions: 3.2.2 (crashes, or at least runs into some inconsistency) 3.3.3 warning: can't inline 3.4.? warning: can't inline
i didn't find a pattern yet.
this sucks, i know, and i'm trying to find a workaround. the -Werror flag is removed so it at least builds. 'can't inline' in libtile really is an error, since inlining is the whole point of libtile ('codelets').
FINK & CYGWIN
i tried to build libpdp on OSX/fink, which works for the most part. but since libtile does not work yet, there's not too much you can do with it.
same for cygwin. compiling the core seems to pose no problems. i think the rest has been done by carmen (pdp base library). so, a windows port is definitely in reach. now somebody needs to just do it (write native input/output modules).
GEM
for the platform-dependent stuff it might be wise to start piggybacking on GEM, a kind advice i've been ignoring for a while.
seriously, talking about gem. i think the moment has come to connect a headless pf (libpdp) to gem. this should be really straightforward. the only thing i'd need is a point in the control flow, where i can execute some opengl statements in the current context.
then in a later step all the data types (and processors?) of GEM could be mapped to pf's or wrapped as abstract data types, intertwining them a bit more. this would lead to a situation where 'the user' could choose an interface or a policy or hair style (gem or pdp) and all the functionality would be available. pf uses pdp/pidip's data format, so when pf is connected to gem, pdp/pidip is too. (livido will come soon).
that should be enough pf promo for today. as usual, if you encounter a problem, don't hesitate to report it.
cheers, tom