[PD] pdp 0.13 update

[Tom Schouten]

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 at 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