Update of /cvsroot/pure-data/externals/pdp/doc/misc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3209/doc/misc
Added Files:
devdoc.html layers.txt overview.html todo.jme
Log Message:
checking in pdp 0.12.4 from http://zwizwa.fartit.com/pd/pdp/pdp-0.12.4.tar.gz
--- NEW FILE: todo.jme ---
todo list of jme(a)off.net
------------------------
- a packet to trigger packet generator instead of bang
o the created packet has the same format as the incoming packet
--- NEW FILE: overview.html ---
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>Pure Data Packet</title></head>
<body>
<h1>Pure Data Packet</h1>
<h2>Introduction</h2>
<p>Pure Data Packet (PDP) is an extension library for the computer music
program <a href="http://www.pure-data.org">Pure Data</a> (PD), by <a href =
"http://www-crca.ucsd.edu/~msp/software.html">Miller Puckette</a> and
others. Its goal is to provide a way to use arbitrary data types (data
packets) as messages that can be passed around inside PD, along side the
standard PD numbers and symbol types. In short it puts any data object on
the same level as a float or a symbol.
<p>PDP runs on Linux and OSX. The OSX version depends on <a
href="http://fink.sourceforge.net/">Fink</a>, which is not in the "point &
click" stage yet, so setting it up will require some efford. There is no
windows version. The reason for this is simple: i don't use windows myself.
Porting would require writing code for input/output and getting the
libraries PDP depends on to work. If anyone is willing to do this, just let
me know. PDP can run without X Window, using SDL.
<p> Currently, PDP's focus is on images and video, but there is no reason it
should stay like that. There is limited support for matrix processing
included in the main library (like Jitter or Gridflow). There is an
extension library for 1D and 2D binary cellular automata, opengl rendering
(like Gem). Some plans include audio buffers (like Vasp), ascii packets,
text buffers, ... Finally there's a library that enables you to connect a
scheme interpreter (guile) to PD/PDP. For more image processing objects,
have a look at Yves Degoyon's <a
href="http://ydegoyon.free.fr/pidip.html">PiDiP</a> library.
<h2>Getting Started</h2>
If you're used to working with PD, the the documentation and example
patches should be enough to get you started. Have a look at the README file
in the distribution to find out how to compile and setup. The file
doc/reference.txt contains a list of objects. If you have installed PDP
properly, you can just press the right mouse button on an object and select
help to get a help patch. If this doesn't work, look in the directory
doc/objects for a collection of help patches. The directory doc/examples
contains some more demos. The directory doc/objects contains two
abstractions that are used to setup the input and output in the help
patches. You might want to cut and connect some wires to use the
input/output setup that works for you.
<h2>Packets and Types</h2>
<p> PDP is centered around the concept of packets and operations on
packets. There are several types of packets. The default type for most
objects is <code><b>image/YCrCb/320x240</b></code>. This is a single video
frame, encoded in the internal 16bit YUV format, measuring 320 by 240
pixels. Another image type is the grayscale image
<code><b>image/grey/320x240</b></code>. Important notes: All image processing objects that
combine two or more packets need to be fed with the same packet types, i.e.
encoding (YCrCb/grey) and dimensions need to be the same. Image dimensions need to be a
multiple of <code><b>8x8</b></code>.
<p> The
<code><b>bitmap/*/*</b></code> type is another image representation type
supporting several encodings. I.e. <code><b>bitmap/rgb/*</b></code>,
<code><b>bitmap/rgba/*</b></code>, <code><b>bitmap/yv12/*</b></code>, ...
This type cannot be processed directly by most of the image processing
objects, but it can be used to store in delay lines, or to send over the
network. It's main use is to support all kinds of input/output devices, and
opengl textures, without introducing too many conversions, but it can serve
as a space and bandwidth saver too (especially
<code><b>bitmap/yv12/*</b></code>).
<p> One of the interesting
features in PD is the possibility of connecting everything with everything.
If you want to generalize this to all kinds of media objects, the complexity
of managing the different types starts to grow quite fast. Therefore PDP has
a type conversion system that can take care of most of the conversions
using the <code><b>[pdp_convert]</b></code> object. You can manually convert
packets to a certain type by specifying a type template as a creation
argument. I.e. <code><b>[pdp_convert image/grey/*]</b></code> will convert
any packet to a greyscale image. Most of the conversion will become
automatic later on.
<p> An example: You can use the basic PDP library together with the
cellular automata library and the opengl rendering library to use a cellular
automaton as an input to a video processing chain. You can convert the
processed image to a texture that can be applied to a 3d object, which then
can be drawn to the screen, captured as a texture, converted back to an
image, which can then be converted to a sound, processed and converted back
to an image, etc... You get the point. The possibilities are endless.
<hr>
<address><a href="mailto:pdp@zzz.kotnet.org">Tom Schouten</a></address>
<!-- Created: Thu Apr 24 22:21:03 CEST 2003 -->
<!-- hhmts start -->
Last modified: Thu Sep 25 20:51:44 CEST 2003
<!-- hhmts end -->
</body>
</html>
--- NEW FILE: devdoc.html ---
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>PDP Developer Documentation</title>
</head>
<body>
<h1>PDP Developer Documentation</h1>
<h2>Introduction</h2>
<p>There is not yet much developer information, partly because pdp is not that big and since the goals are
not completely clear yet, a lot will probably change on the inside in the future. I believe it is
not too hard to figure out how it works, once you get started somewhere. This document is a minimalistic
attempt to provide that starting point. For full prototypes see the header files. I suggest you have a look at the pdp_base base class, and some simple
modules: pdp_add, pdp_noise and pdp_gain for examples.
<h2> PDP architecture </h2>
<p> Architecture is a big word, but pdp is organized as modules. A packet pool module (a reuse pool memory manager),
a packet class, a processing queue module, a high level type conversion module, an image packet class, and some
low level modules for image type conversion, image resampling and all sorts of other image processing. Besides that
there are 2 extension libraries: pdp_scaf, a cellular automata extension and pdp_opengl, a 3d rendering extension.
These are separate because of portability issues. The different pdp_* externs in the main pdp library use the
core modules' functionality to minimize code duplication. I'm relatively happy with how it fits together,
but some things need to change for future plans. Most objects are written in the object oriented c style of pd.
To prevent namespace conflicts, (almost) all routines start with the pdp_ prefix. The second name is the name of the
object or module they belong to. The first argument is always a pointer to an object or an integer (for packets).
<h2> PD ties </h2>
<p> PDP is written as an extension for PD. One of the goals of pdp is to evolve to a separate library that can
be reused in other software. The architecture will be split into two parts. A pd-independent part (the packet classes,
the packet pool, the type conversion system and the forth system) and a part with pd specific stuff (the process queue and interfaces to the
pd system like the base classes and the pd communication protocol). In order to do this the packet class will probably
evolve to a proper object model, supporting run time attribute binding (inspired by the python object model).
<p>There are some things that put a stamp on the current pdp design. Most importantly pd's processor object model and
communication protocol. (i.e. the fact that pd only supports unidirectional messaging creates the awkward concept
of a "passing packet" to eliminate excessive data copying.)
<p> In pd, the pdp messaging protocol is implemented as pd messages. The protocol is however 3 phase.
With a read only register phase, a read/write register phase and a process phase. This functionality
is part of the base class or the forth processor object. The dpd protocol is entirely different,
and is used in the opengl library. It is
not based on parallel dataflow but serial context passing.
<h2> Packets </h2>
<p> PDP introduces a new atom: the data packet. This can contain all kinds of data. Images (16bit/8bit), cellular
automata (1bit), matrices (real/complex float/double), opengl textures and 3d rendering contexts. Packets
are stored in a pool to ensure fast reuse, and to enable sharing. The paradigm is centered around a
combination of an object oriented approach and a dataflow approach.
<p>The methods operating on packets
(pdp_packet_*) are mainly for administrative purposes: memory management (construction, registering, copying)
and getting or setting info.
<p>All processing is done in the pd modules. Processors can be defined using
the forth scripting language, but this is still experimental. The forth system can be accessed
from the guile library.
<p> There is a central mechanism for packet type conversion. This is to facilitate the combination of different
media types. Whenever a packet class is constructed (i.e. in an extension library), a number of conversion
routines should be defined to convert the added type to one or some of the main pdp types.
<h2>PDP API Overview</h2>
The pdp public api contains only a single class: the packet. (The internal api has more classes, that can be used
too if necessary, but i won't document them.) A packet is a class in pdp. The table below lists the supported methods.
The first argument of a call is a packet id.
<TABLE border = "1">
<TR><TH colspan = "2">pdp_packet_*
<TR><TD>new <TD>construct a raw packet (depreciated)
<TR><TD>new_* <TD>construct packet of specific type/subtype/...
<TR><TD>mark_unused <TD>release
<TR><TD>mark_passing <TD>conditional release (release on first copy ro/rw)
<TR><TD>copy_ro <TD>readonly (shared) copy
<TR><TD>copy_rw <TD>private copy
<TR><TD>clone_rw <TD>private copy (copies only meta data, not the content)
<TR><TD>header <TD>get the raw header (t_pdp *)
<TR><TD>data <TD>get the raw data (void *)
<TR><TD>pass_if_valid <TD>send a packet to pd outlet, if it is valid, and mark unused
<TR><TD>replace_if_valid <TD>delete packet and replace with new one, if new is valid
<TR><TD>copy_ro_or_drop <TD>copy readonly, or don't copy if dest slot is full + send drop notify
<TR><TD>copy_rw_or_drop <TD>same, but private copy
<TR><TD>get_description <TD>retrieve type info
<TR><TD>convert_ro <TD>same as copy_ro, but with an automatic conversion matching a type template
<TR><TD>convert_rw <TD>same as convert_ro, but producing a private copy
</TABLE>
<p>The pool object methods. All the packets are stored in a central packet pool.
<TABLE border = "1">
<TR><TH colspan = "2">pdp_pool_*
<TR><TD>collect_garbage <TD>manually free all unused resources in packet pool
</TABLE>
<p>The process queue object methods. PDP supports a separate processing thread.
<TABLE border = "1">
<TR><TH colspan = "2"> pdp_queue_*
<TR><TD>add <TD>add a process method + callback
<TR><TD>finish <TD>wait until a specific task is done
<TR><TD>wait <TD>wait until processing queue is done
</TABLE>
<p>The control methods. General pdp control messages.
<TABLE border = "1">
<TR><TH colspan = "2"> pdp_control_*
<TR><TD>notify_drop <TD>notify that a packet has been dropped
</TABLE>
<p> The type mediator methods.
<TABLE border = "1">
<TR><TH colspan = "2"> pdp_type_*
<TR><TD>description_match <TD>check if two type templates match
<TR><TD>register_conversion <TD>register a type conversion program
</TABLE>
<p>NOTE: it is advised to derive your module from the pdp base class defined in pdp_base.h
instead of communicating directly with the pdp core
<h2>pdp_base class</h2>
If you want to write a pdp extern, you can derive it from the pdp_base class, instead of t_object.
This class abstracts a lot of the hassle of writing ordinary (inplace) packet processors. The base
allows you to register process callbacks. There are 3 kinds of callbacks: preproc, process and postproc.
The preproc method is called inside the pd thread. This can be used to setup some things that can only
be done inside the pd thread. The process method should do most of the work, and is called from the
pdp processing thread if it is enabled, after the preproc method is finished. You can't use most
of pd's calls in this method. The postproc method is called
from the pd thread after the process method is finished, and can be used to send data to pd outlets. Simple
packet processors only need the process method (packet input/output is handled by the pdp_base class).
<h2>pdp_imageproc_* modules</h2>
Most of the image processing code is organized as planar 16 bit signed processors.
This is crude and oversimplified, but it helps to keep the code size small and fast
at the same time (platform dependent assembly code is reduced to a bare minimum). These
routines can be used to build higher level image processing objects that are more (cache)
efficient than an abstraction using separate pdp modules. If you plan to write your own image
processing routines, you can use the pdp_imageproc_dispatch_ routine to support all 16bit image
types at once (greyscale, subsampled YCrCb, multichannel planar). This requires you write the
image processing routine as a planar (greyscale) processor using the pdp_imageproc_
interface. (see pdp_imageproc.h)
<h2>pdp_llconv call</h2>
Low level image conversion routines. (operating on raw data buffers). You probably won't need this,
since the high level type conversion (pdp_packet_convert_ro/rw) covers most of its functionality.
<hr>
<address><a href="mailto:pdp@zzz.kotnet.org">Tom Schouten</a></address>
<!-- Created: Mon Apr 28 15:35:12 CEST 2003 -->
<!-- hhmts start -->
Last modified: Fri Sep 19 04:52:12 CEST 2003
<!-- hhmts end -->
</body>
</html>
--- NEW FILE: layers.txt ---
pdp 0.13 design layers + components
-----------------------------------
from version 0.13 onwards, pdp is no longer just a pd plugin but a
standalone unix library (libpdp). this documents is an attempt to
describe the design layers.
A. PD INTERFACE
---------------
on the top level, libpdp is interfaced to pd using a glue layer which
consists of
1. pdp/dpd protocols for pd
2. process queue
3. base classes for pdp/dpd
4. some small utility pd objects
5. pd specific interfaces to part of pdp core
6. pdp_console
7. pd object interface to packet forth (pdp object)
1. is the same as previous versions to ensure backwards compatibility in
pd with previous pdp modules and extensions that are written as pd
externs or external libs. this includes parts of pdp that are not yet
migrated to libpdp (some of them are very pd specific and will not be
moved to libpdp), and pidip. if you intend to write new modules, it is
encouraged to use the new forth based api, so your code can be part of
libpdp to use it in other image processing applications.
2. is considered a pd part. it implements multithreading of pdp inside
pd. multithreading is considered a host interface part, since it usually
requires special code.
3. the base classes (pd objects) for pdp image processing remain part of
the pd<->pdp layer. the reason is the same as 1. a lot of the original
pd style pdp is written as subclasses of the pdp_base, pdp_image_base,
dpd_base and pdp_3dp_base classes. if you need to write pd specific
code, it is still encouraged to use these apis, since they eliminate a
lot of red tape involving the pdp protocol. a disadvantage is that this
api is badly documented, and the basic api (1.) is a lot simpler to
learn and documented. 3dp is supposed to merge to the new forth api,
along with the image/video processing code.
4. is small enough to be ignored here
5. includes interfaces to thread system and type conversion system +
some pd specific stuff using 1. or 3.
6. the console interface to the pdp core, basicly a console for a
forth like language called packet forth which is pdp's main scripting
language. it's inteded for develloping and testing pdp but it can be
used to write controllers for pd/pdp/... too. this is based on 1.
7. is the main link between the new libpdp and pd. it is used to
instantiate pdp processors in pd which are written in the packet forth.
i.e. to create a mixer, you instantiate a [pdp mix] object, which would
be the same as the previous [pdp_mix] object. each [pdp] object creates
a forth environment, which is initialized by calling a forth init
method. [pdp mix] would call the forth word init_mix to create the local
environment for the mix object. wrappers will be included for backward
compatibility when the image processing code is moved to libpdp.
B. PDP SYSTEM CODE
------------------
1. basic building blocks: symbol, list, memory manager
2. packet implementation (packet class and reuse queue)
3. packet type conversion system
4. os interface (X11, net, png, ...)
5. packet forth
6. additional libraries
1. pdp makes intensive use of symbols and lists (trees, stacks, queues).
pdp's namespace is built on the symbol implementation. a lot of other
code uses the list
2. the pdp packet model is very simple. basicly nothing more than
constructors (new, copy, clone), destructors (mark_unused (for reuse
later), delete). there is no real object model for processors. this is a
conscious decision. processor objects are implemented as packet forth
processes with object state stored in process data space. this is enough
to interface the functionality present in packet forth code to any
arbitrary object oriented language or system.
3. each packet type can register conversion methods to other types. the
type conversion system does the casting. this is not completely finished
yet (no automatic multistage casting yet) but most of it is in place and
usable. no types without casts.
4. os specific modules for input/output. not much fun here..
5. All of pdp is glued together with a scripting language called packet
forth. This is a "high level" forth dialect that can operate on floats,
ints, symbols, lists, trees and packets. It is a "fool proof" forth,
which is polymorphic and relatively robust to user errors (read: it
should not crash or cause memory leaks when experimenting). It is
intended to serve as a packet level glue language, so it is not very
efficient for scalar code. This is usually not a problem, since packet
operations (esp. image processing) are much more expensive than a this
thin layer of glue connecting them.
All packet operations can be accessed in the forth. If you've ever
worked with HP's RPN calculators, you can use packet forth. The basic
idea is to write objects in packet forth that can be used in pd or in
other image processing applications. For more information on packet
forth, see the code (pdp_forth.h, pdp_forth.c and words.def)
6. opengl lib, based on dpd (3.) which will be moved to packet forth
words and the cellular automata lib, which will be moved to
vector/slice forth later.
C. LOW LEVEL CODE
-----------------
All the packet processing code is (will be) exported as packet forth
words. This section is about how the code exported by those words is
structured.
C.1 IMAGE PROESSING: VECTOR FORTH
Eventually, image operations need to be implemented, and in order
to do this efficiently, both codewize (good modularity) as execution speed
wize, i've opted for another forth. DSP and forth seem to mix well, once
you get the risc pipeline issues out of the way. And, as a less rational
explanation, forth has this magic kind of feel, something like art..
well, whatever :)
As opposed to the packet forth, this is a "real" lowlevel forth
optimized for performance. Its reason of being is the solution of 3
problems: image processing code factoring, quasi optimal processor
pipeline & instruction usage, and locality of reference for maximum
cache performance. Expect crashes when you start experimenting with
this. It's really nothing more than a fancy macro assembler. It has no
safety belts. Chuck Moore doctrine..
The distinction between the two forths is at first sight not a good
example of minimizing glue layers. I.e. both systems (packet script
forth and low level slice forth) are forths in essence, requiring
(partial) design duplication. Both implementations are however
significantly different which justified this design duplication.
Apart from the implementation differences, the purpose of both languages
is not the same. This requires the designs of both languages to be
different in some respect. So, with the rule of "do everything right
once" in mind, this small remark tries to justify the fact that forth !=
forth.
The only place where apparent design correspondence (the language model)
is actually used is in the interface between the packet forth and the
slice forth.
The base forth is an ordinary minimal 32bit (or machine word
lenght) subroutine threaded forth, with a native code kernel for
i386/mmx, a portable c code kernel and room for more native code kernels
(i.e i386/sse/sse2/3dnow, altivec, dsp, ...) Besides support for native
machine words bit ints and pointers, no floats, since they clash with
mmx, are not needed for the fixed point image type, and can be
implemented using other vector instructions when needed), support for
slices and a separate "vector stack".
Vectors are the native machine vectors, i.e. 64bit for mmx/3dnow,
128bit for sse/sse2, or anything else. The architecture is supposed to
be open. (I've been thinking to add a block forth, operating on 256bit
blocks to eliminate pipeline issues). Blocks are just blocks of vectors
which are used as a basic loop unrolling data size grain for solving
pipeline operations in slice processing words.
Slices are just arrays of blocks. In the mmx forth kernel, they can
represent 4 scanlines or a 4 colour component scanline, depending on how
they are fed from packet data. Slices can be anything, but right now,
they're just scanlines. The forth kernel has a very simple and efficient
(branchless) reference count based memory allocator for slices. This
slice allocator is also stack based which ensures locality of reference:
a new allocated slice is the last deallocated slice.
The reason for this obsession with slices is that a lot of video
effects can be chained on the slice level (scanline or bunch of
scanlines), which improves speed through more locality of reference. In
concreto intermediates are not flushed to slower memory. The same
principles can be used to do audio dsp, but that's for later.
The mmx forth kernel is further factored down following another
virtual machine paradigm. After doing some profiling, i came to the
conclusion that the only, single paradigm way of writing efficient
vector code on today's machines is multiple accumulators to avoid
pipeline stalls. The nice thing about image processing is that it
parallellizes easily. Hence the slice/block thing. This leads to the
1-operand virtual machine concept for the mmx slice operations. The
basic data size is one 4x4 pixel block (16bit pixels), which is
implemented as asm macros in mmx-sliceops-macro.s and used in
mmx-sliceops-code.s to build slice operations. The slice operations are
built out of macro instructions for this 256bit or 512bit, 2 or 1
register virtual machine which has practically no pipeline delays
between its instructions.
Since the base of sliceforth is just another forth, it could be that
(part of) 3dp will be implemented in this lowlevel forth too, if
performance dictates it. It's probably simpler to do it in the lowlevel
forth than the packet forth anyway, in the form of cwords.
C.2: MATRIX PROCESSING: LIBGSL
All matrix processing packet forth words are (will be) basicly wrappers
around gsl library calls. Very straightforward.
C.3: OPENGL STUFF
The same goes for opengl. The difference here is that it uses the dpd
protocol in pdp, which is more like the Gem way of doing things. The
reason for this is that, although i've tried hard to avoid it, opengl
seems to dictate a drawing context based, instead of an object based way
of working. So processing is context (accumulator) based. Packet forth
will probably get some object oriented, or context oriented feel when
this is implemented.
Update of /cvsroot/pure-data/externals/pdp/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3209/doc
Added Files:
reference.txt
Log Message:
checking in pdp 0.12.4 from http://zwizwa.fartit.com/pd/pdp/pdp-0.12.4.tar.gz
--- NEW FILE: reference.txt ---
This is a list of all pdp objects and abstractions with a minimal description.
Take a look at the patches in the doc/ directory for more info.
(Messy doc & test patches can be found in the test/ directory.)
general purpose pdp modules:
pdp_del a packet delay line
pdp_reg a packet register
pdp_snap takes a snapshot of a packet stream
pdp_trigger similar to pd's trigger object
pdp_route routes a packet to a specific outlet
pdp_loop a packet loop sampler (packet array)
pdp_description output a symbol describing the packet type
pdp_convert convert between packet types
image inputs/outputs:
pdp_xv displays images using the xvideo extension
pdp_glx displays images using opengl
pdp_v4l reads images from a video4linux device
pdp_qt reads quicktime movies
image processors:
pdp_abs absolute value
pdp_add adds two images
pdp_and bitwize and
pdp_bitdepth set bit depth
pdp_bitmask apply a bit mask
pdp_bq spatial biquad filter
pdp_bqt temporal biquad filter
pdp_cog gaussian blob estimator
pdp_constant fills an image with a constant
pdp_conv horizontal/vertical seperable convolution filter
pdp_cheby chebyshev color shaper
pdp_chrot rotates the chroma components
pdp_flip_lr flip left <-> right
pdp_flip_tb flip top <-> bottom
pdp_grey converts an image to greyscale
pdp_grey2mask converts a greyscale image to an image mask
pdp_hthresh hard thresholding
pdp_mul multiplies two images
pdp_mix crossfade between 2 images
pdp_mix2 mixes 2 images after applying a gain to each of them
pdp_noise a noise generator
pdp_not bitwize not
pdp_or bitwize or
pdp_plasma plasma generator
pdp_pointcloud convert an image to a point cloud
pdp_positive sign function that creates a bitmask
pdp_randmix crossfades 2 images by taking random pixels
pdp_rotate tiled rotate
pdp_scale rescale an image
pdp_sign sign function
pdp_sthresh soft thresholding
pdp_zoom tiled zoom
pdp_zrot tiled zoom + rotate
pdp_zthresh zero threshold (x<0 -> 0)
pdp_xor bitwize xor
dsp objects
pdp_scope~ a very simple oscilloscope
pdp_scan~ phase input scanned synthesis oscillator
pdp_scanxy~ x,y coordinate input scanned synthesis oscillator
utility abstractions
pdp_pps computes the packet rate in packets/sec
image abstractions
pdp_affine scale (gain) + offset
pdp_agc automatic gain control (intensity maximizer)
pdp_alledge an all edge detector
pdp_blur blurs an image
pdp_blur_hor horizontal blur
pdp_blur_ver vertical blur
pdp_contrast contrast enhancement
pdp_conv_alledge edge detector
pdp_conv_emboss emboss effect
pdp_conv_smooth smoothing
pdp_conv_sobel_hor horizontal sobel edge detector
pdp_conv_sobel_ver vertical sobel edge detector
pdp_conv_sobel_edge sum of squares of hor and ver edge detector
pdp_dither a dither effect
pdp_gain3 independent channel gains
pdp_gradient grayscale to colour gradient conversion
pdp_grey convert image to greyscale
pdp_invert invert video
pdp_motion_blur blurs motion
pdp_motion_fade motion triggered fade out
pdp_motion_phase phase shifts motion
pdp_offset add an offset to an image
pdp_phase applies an allpass filter to an image
pdp_phase_hor horizontal allpass
pdp_phase_ver vertical allpass
pdp_png_to convert a png file (on disk) to a certain packet type
pdp_qt_control movie file controller (different play modes)
pdp_qtloop~ varispeed (interpolated) looper
pdp_qtloop2~ same, but depends on tabreadmix~ from creb
pdp_saturation change colour saturation
pdp_save_png_sequence save png sequence in /tmp dir
pdp_sub subtract 2 images
pdp_invert inverse video
pdp_tag tag a packet (to use it with route)
pdp_xv_keycursor a keyboard/mouse controller using pdp_xv
matrix processors
pdp_m_mv matrix vector multiply
pdp_m_mm matrix matrix multiply
pdp_m_+=mm matrix matrix multiply add
pdp_m_LU compute LU decomposition
pdp_m_LU_inverse compute matrix inverse from LU decomp
pdp_m_LU_solve solve a linear system using LU decomp
matrix abstractions
pdp_m_inverse compute matrix inverse
SEPARATE LIBRARIES:
cellular automata
(pdp_scaf)
pdp_ca computes a cellular automaton (as a generator or a filter)
pdp_ca2image convert a CA packet to a greyscale image (obsolete: use pdp_convert)
pdp_image2ca convert an image to a CA packet (black and white) (obsolete: use pdp_convert)
3d drawing objects
(pdp_opengl)
3dp_windowcontext a drawable window
3dp_draw draw objects (cube, sphere, ...)
3dp_view viewing transforms (rotate, translate, ...)
3dp_light light source
3dp_push push a matrix (modelview, texture, ...)
3dp_dlist compile a display list
3dp_snap copies the drawing buffer to a texture packet
3dp_mode set the current matrix mode
3dp_toggle set some opengl state variables
3d drawing abstractions (pdp_opengl)
3dp_mouserotate connect to 3dp_windowcontext to rotate the scene
3dp_blend turn on accumulative blending mode
Update of /cvsroot/pure-data/externals/pdp
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3209
Added Files:
CHANGES.LOG COPYING README TAGS TODO buildall configure
configure.ac
Log Message:
checking in pdp 0.12.4 from http://zwizwa.fartit.com/pd/pdp/pdp-0.12.4.tar.gz
--- NEW FILE: configure ---
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.57.
#
# Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002
# Free Software Foundation, Inc.
# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.
## --------------------- ##
## M4sh Initialization. ##
## --------------------- ##
# Be Bourne compatible
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
emulate sh
NULLCMD=:
# Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
# is contrary to our usage. Disable this feature.
alias -g '${1+"$@"}'='"$@"'
[...4788 lines suppressed...]
# output is simply discarded. So we exec the FD to /dev/null,
# effectively closing config.log, so it can be properly (re)opened and
# appended to by config.status. When coming back to configure, we
# need to make the FD available again.
if test "$no_create" != yes; then
ac_cs_success=:
ac_config_status_args=
test "$silent" = yes &&
ac_config_status_args="$ac_config_status_args --quiet"
exec 5>/dev/null
$SHELL $CONFIG_STATUS $ac_config_status_args || ac_cs_success=false
exec 5>>config.log
# Use ||, not &&, to avoid exiting from the if with $? = 1, which
# would make configure fail if this is the last instruction.
$ac_cs_success || { (exit 1); exit 1; }
fi
--- NEW FILE: TAGS ---
include/pdp.h,21
#define PDP_H24,840
include/pdp_ascii.h,140
#define PDP_H23,858
} t_ascii;t_ascii31,1093
#define PDP_ASCII_BW 35,1128
#define PDP_ASCII_IBM 36,1198
#define PDP_ASCII_RGB 37,1324
include/pdp_base.h,221
#define MAX_NB_PDP_BASE_INLETS 30,1059
#define MAX_NB_PDP_BASE_OUTLETS 31,1092
typedef void (*t_pdp_method)t_pdp_method41,1288
typedef void* (*t_pdp_newmethod)t_pdp_newmethod42,1326
} t_pdp_base;t_pdp_base78,2653
include/pdp_bitmap.h,327
[...2578 lines suppressed...]
static void _pdp_tex_copy(298,8259
static void _pdp_tex_cleanup(313,8820
static int _pdp_packet_texture_old_or_dummy(324,9147
static void _pdp_packet_gentexture(381,10597
int pdp_packet_new_texture(398,10960
void pdp_packet_texture_make_current(414,11386
void pdp_packet_texture_make_current_enable(421,11573
float pdp_packet_texture_fracx(432,12041
float pdp_packet_texture_fracy(439,12206
u32 pdp_packet_texture_total_width(446,12373
u32 pdp_packet_texture_total_height(453,12524
u32 pdp_packet_texture_sub_width(461,12678
u32 pdp_packet_texture_sub_height(468,12831
float pdp_packet_texture_sub_aspect(475,12983
void pdp_packet_texture_setup_2d_context(483,13209
void pdp_texture_setup(508,13868
opengl/system/setup.c,52
#define D(D47,1258
void pdp_opengl_setup(49,1274
--- NEW FILE: CHANGES.LOG ---
last modified: 2003/02/27
ChangeLog:
v0.1: 2002/11/23
initial release
v0.2: 2002/11/27
added support for BC_YUV422 video and audio playback in pdp_qt /
pdp_qt~ (thanks to Yves Degoyon for contrib)
some makefile cleanups
v0.3: 2002/11/28
pdp_qt / pdp_qt~: fixed some bugs in audio playback and added
suport for BC_RGB888 colormodel (loads as greyscale until there
is internal support for a rgb image packet)
v0.4: 2002/12/03
code style changes
added scaf / cellular automata support.
added some basic filter abstractions. (blur, phase)
v0.5: 2002/12/13
first attempt at a documentation (see doc/)
added support for processing in separate lower priority thread
with a packet dropping mechanism to avoid audio dropouts.
added pdp_control object for controlling pdp's scheduling and
detecting packet drops
pdp api cleanup (name changes)
added some more filter abstractions
(motion blur/phase, emboss, sobel, edge)
added pdp_route
v0.6: 2003/01/03
added pdp_gain, finished pdp_gradient
added channel method to pdp_v4l, display method to pdp_xv
added some examples in doc/examples
fixed gcc3 compilation probs
fixed some pdp_qt bugs (shouldn't crash any more)
v0.7: 2003/01/12
moved image format conversion routines to pdp_llconv.c
added support for rgb->PDP_IMAGE_YV12 in pdp_v4l, pdp_qt
added pdp_grey, pdp_chrot, pdp_scope~
moved mmx wrappers to pdp_imageproc_mmx.c
added portable c code in pdp_imageproc_portable.c
added mmx code for pdp_gain
fixed bug in pdp_mix/pdp_mix2
fixed bug in pdp_bq (removed state reset)
moved CA stuff to separate lib (see scaf/)
(0.7.1) fixed rgb colour conversion bug
v0.8: 2003/02/02
added pdp_scale, pdp_zoom, pdp_rotate, pdp_zrot, pdp_scan~, pdp_cheby
added support for 1D ca's + shift compensation in pdp_ca
thread processing is off by default now
added cursor method to pdp_xv, freq method to pdp_v4l (thanks CK)
added pdp_sdl (thanks Martin Pi)
added some example patches in doc/examples
(0.8.1) fixed scaf + gcc<3 compilation problem
(0.8.2) fixed compile prob + added documentation
(0.8.3) completed documentation
v0.9: 2003/02/27
added pdp_scanxy~, pdp_invert
now uses autoconf for configuration
standard "make install" target
optional compililation for external dependencies (xv,qt,v4l,sdl)
experimental OSX port (without i/o)
fixed crash when closing xv window manually
added mouse event output to pdp_xv
pdp_ca now automaticly compiles rule files
fixed image dimension crashes
fixed pdp_xv bang crash
added pdp_grey2mask
added pdp_slice_cut/pdp_slice_glue (experimental/nondoc)
v0.10: 2003/03/06
modules code reorganization
removed pdp_affine object and added compatibility object based on pdp_cheby
added pdp_mchp and PDP_IMAGE_MCHP packet format (experimental)
added pdp_and, pdp_or, pdp_xor, pdp_not, pdp_bitmask, pdp_bitdepth
added base class for pdp objects
added incremental garbage collector
added support for "not so pure" data packets
added opengl subproject containing a pdp_glx display object
added a PDP_TEX opengl texture packet (opengl lib)
added PDP_IMAGE_GREY8, PDP_IMAGE_RGB8, PDP_IMAGE_RGBA8 packets
(0.10.1) fixed (fatal) bug in pdp_base, and bug in pdp_noise (non-mmx)
(0.10.1) pdp_glx now compiles on mac osx
v0.11: 2003/04/08
updated pdp_trigger to behave like pd's trigger object
added automatic philips web cam detection
removed "zombie" packet passing and made pool manager thread safe
(this required an api change: backward compat for pdp thread proc broken)
added gem style object rendering & transformation objects (opengl lib)
removed pdp_gradient binary module (it is now an abstraction)
added pdp_loop (a packet array / loop sampler)
added pdp_description
added support for libquicktime on osx (thanks Jamie)
added support for accumulation packets (dpd) (still experimental)
(0.11.1) fixed some packet registering and frame dropping bugs
v0.12: 2003/06/21
added support for high level packet conversion (mime-like descriptions)
added pdp_convert
added "memlimit" message to pdp_control (to limit pdp's mem usage)
maximum nb of packets is now only limited by the memlimit
added new basic type: bitmap/*/* (PDP_BITMAP) for standard fourcc formats
cleaned up pdp_xv/glx (x window glue code reuse)
fixed rgb/bgr bug in conversion code
added pdp_abs, pdp_zthresh
completed dpd framework (for context based processing, i.e. 3dp)
rewrote gem like 3d library on top of dpd (it's almost stable)
added a matrix type (float/double real/complex) for linear algebra stuff
added matrix processors pdp_m_*: mv, mm, +=mm, LU, LU_inverse, LU_solve
pdp_cheby now accepts an array with a mapping function
added pdp_plasma
fixed outlet_pdp bug (this caused all kind of weirdness)
added embedded scheme interpreter for testing (see the guile/ dir)
added simple forth-style scripting language (pdp's rpn calculator)
added png load/save support to pdp_reg
(0.12.1) fixed OSX compilation probs
(0.12.1) fixed texture coordinate bugs (pdp_opengl)
(0.12.1) added multipass rendering support (pdp_opengl)
(0.12.1) pdp_cog (Johannes Taelman's gaussian blob estimator)
(0.12.1) pdp_sthresh, hthresh, positive, offset, sign
(0.12.1) pdp_agc, contrast, flip_lr, flip_tb
(0.12.1) added pdp and pdp_opengl examples
(0.12.2) pdp_histo, dither, pointcloud
(0.12.2) more examples & added some conversion code
(0.12.2) fixed c++ compilation issues
0.12.3: 2004/01/13
various bug fixes
added pdp_grey2array
fixed window event routing problem (3dp)
cleaned up source tree (for libpdp)
added pdp_netsend / pdp_netreceive to send packets over udp (experimental)
more forth scripting stuff
added "norm" message and rgb32 colour model to pdp_v4l
added keyboard and mouse motion events to pdp_xv and pdp_glx
compiles without x support, for use with sdl (i.e. svgalib)
more packet forth work
started sliceforth library (core signal processing routines)
finished pd interface to forth scripting language
fixed some crashes with pdp_xv and pdp_glx
removed "passing packet" hack
added minimal OO support to packet forth
moved all the forth stuff to libpdp project (no longer in pdp distro)
fixed (worked around) pdp_opengl deadlock bug on startup
pdp_opengl still not working properly
0.12.4: 2004/07/09
build fixes
--- NEW FILE: configure.ac ---
AC_INIT(system/pdp.c)
AC_CONFIG_HEADER(include/pdp_config.h)
AC_PROG_CC
AC_HEADER_STDC
dnl TAG CVS WHEN RELEASE VERSION CHANGES !!!
PDP_VERSION=0.12.4
AC_SUBST(PDP_VERSION)
AC_ARG_ENABLE(mmx,
[ --enable-mmx enable MMX support (no)], , enable_mmx=no)
AC_ARG_ENABLE(quicktime,
[ --enable-quicktime enable libquicktime support (yes)], , enable_quicktime=yes)
AC_ARG_ENABLE(v4l,
[ --enable-v4l enable Video4Linux support (yes)], , enable_v4l=yes)
AC_ARG_ENABLE(pwc,
[ --enable-pwc force additional Philips WebCam support (auto)],,enable_pwc=auto)
AC_ARG_ENABLE(x,
[ --enable-x enable X11 support (required by XVideo and GLX) (yes)], , enable_x=yes)
AC_ARG_ENABLE(xv,
[ --enable-xv enable XVideo display support (yes)], , enable_xv=yes)
AC_ARG_ENABLE(sdl,
[ --enable-sdl enable SDL display support (yes)], , enable_sdl=yes)
AC_ARG_ENABLE(glx,
[ --enable-glx enable GLX display support (yes)], , enable_glx=yes)
AC_ARG_ENABLE(gsl,
[ --enable-gsl enable gsl support (for matrix packets) (yes)], , enable_gsl=yes)
AC_ARG_ENABLE(png,
[ --enable-png enable png image load/save support (yes)], , enable_png=yes)
AC_ARG_ENABLE(debug,
[ --enable-debug enable debugging support (no)], , enable_debug=no)
PDP_CFLAGS="-DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch"
dnl -Werror -Wshadow
dnl setup debugging
if test $enable_debug == yes
then
AC_DEFINE(PDP_DEBUG, 1, "enable debugging support")
PDP_CFLAGS="$PDP_CFLAGS -g -Werror -Wshadow"
else
AC_DEFINE(PDP_DEBUG, 0, "disable debugging support")
PDP_CFLAGS="$PDP_CFLAGS -O2 -funroll-loops -fomit-frame-pointer -ffast-math"
fi
if test $prefix == NONE;
then
prefix=/usr/local
fi
dnl setup forced pwc support
if test $enable_pwc == yes;
then
AC_DEFINE(HAVE_PWCV4L, 1,enable forced pwc v4l support)
fi
dnl try to locate the pd header in case the setup is nonstandard
dnl check in $prefix/pd/src then ../pd/src
dnl if this fails we trust it is in the standard include path
PWD=`pwd`
if test -f $prefix/pd/src/m_pd.h;
then
PD_CPPFLAGS="-I$prefix/pd/src"
elif test -f $prefix/src/pd/src/m_pd.h;
then
PD_CPPFLAGS="-I$prefix/src/pd/src"
elif test -f $PWD/../pd/src/m_pd.h;
then
PD_CPPFLAGS="-I$PWD/../pd/src"
elif test -f $PWD/../src/m_pd.h;
then
PD_CPPFLAGS="-I$PWD/../src"
fi
CPPFLAGS="$CPPFLAGS $PD_CPPFLAGS"
AC_CHECK_HEADER(m_pd.h,,
echo "WARNING: m_pd.h not found. Is PD installed?"
echo "WARNING: if you have changed PD_CPPFLAGS in Makefile.config.in you can ignore this warning." )
AC_CHECK_LIB(m,sin)
ARCH=`uname -s`
if test $ARCH == Linux;
then
PDP_LIBRARY_NAME=pdp.pd_linux
if test $enable_mmx == yes;
then
PDP_TARGET=linux_mmx
else
PDP_TARGET=linux
fi
elif test $ARCH == Darwin;
then
PDP_LIBRARY_NAME=pdp.pd_darwin
PDP_TARGET=darwin
else
echo WARNING: Architecture `uname -s` not supported.
exit
fi
dnl Darwin specific stuff: this is still pretty experimental
dnl How to test if frameworks are present ????
if test $ARCH == Darwin
then
PD_EXECUTABLE=$prefix/bin/pd
LIBS="$LIBS -L/sw/lib"
CPPFLAGS="$CPPFLAGS -I/sw/include"
PDP_EXTRA_CPPFLAGS="-I/sw/include"
dnl if not darwin, assume target is linux
else
AC_CHECK_HEADER(linux/videodev.h,
PDP_OPTMOD="$PDP_OPTMOD pdp_v4l.o"
AC_DEFINE(HAVE_PDP_V4L, 1, build pdp_v4l),
echo " linux/videodev.h not found: not building pdp_v4l")
fi
dnl optional gsl support
if test $enable_gsl == yes;
then
AC_CHECK_LIB(gslcblas,main)
AC_CHECK_LIB(gsl,main,
PDP_OPTTYPES="$PDP_OPTTYPES pdp_matrix.o"
PDP_MATRIX_BASIC="$PDP_MATRIX_BASIC pdp_mat_mul.o pdp_mat_lu.o pdp_mat_vec.o"
PDP_IMAGE_BASIC="$PDP_IMAGE_BASIC pdp_cheby.o"
PDP_IMAGE_SPECIAL="$PDP_IMAGE_SPECIAL pdp_histo.o"
AC_DEFINE(HAVE_PDP_GSL, 1, gsl support)
LIBS="$LIBS -lgslcblas -lgsl",
echo " libgsl not found: not building matrix type support")
fi
dnl optional png support
if test $enable_png == yes
then
AC_CHECK_LIB(png, png_read_image,
LIBS="$LIBS -lz -lpng"
AC_DEFINE(HAVE_PDP_PNG, 1, build png support),
echo " libpng not found: not building png support")
fi
dnl optional xwindow support
if test $enable_x == yes;
then
AC_CHECK_LIB(X11, XOpenDisplay,
PDP_X11MOD="$PDP_X11MOD pdp_xwindow.o"
AC_DEFINE(HAVE_PDP_X, 1, build X11 support)
LIBS="$LIBS -L/usr/X11R6/lib -lX11",
echo " libX11 not found: not building X11 support",
-L/usr/X11R6/lib)
else
dnl no x support -> no xv and glx support
enable_xv=no
enable_glx=no
fi
dnl optional xvideo support
if test $enable_xv == yes;
then
AC_CHECK_LIB(Xv, XvPutImage,
PDP_X11MOD="$PDP_X11MOD pdp_xvideo.o"
PDP_OPTMOD="$PDP_OPTMOD pdp_xv.o"
LIBS="$LIBS -lXv -lXext"
AC_DEFINE(HAVE_PDP_XV, 1, build pdp_xv),
echo " libXv not found: not building pdp_xv",
-L/usr/X11R6/lib -lX11 -lXext)
fi
dnl optional libquicktime support
if test $enable_quicktime == yes;
then
AC_CHECK_LIB(quicktime, lqt_decode_video,
PDP_OPTMOD="$PDP_OPTMOD pdp_qt.o"
LIBS="$LIBS -lquicktime"
AC_DEFINE(HAVE_PDP_QT, 1, build pdp_qt),
echo " libquicktime not found: not building pdp_qt")
fi
dnl optional glx support
if test $enable_glx == yes
then
AC_CHECK_LIB(GL, glXSwapBuffers,
PDP_OPTMOD="$PDP_OPTMOD pdp_glx.o"
LIBS="$LIBS -lGL -lGLU"
AC_DEFINE(HAVE_PDP_GLX, 1, build pdp_glx),
echo " libGL not found: not building pdp_glx",
-L/usr/X11R6/lib -lGLU)
fi
dnl optional sdl support
if test $enable_sdl == yes
then
AC_CHECK_LIB(SDL, SDL_Init,
PDP_OPTMOD="$PDP_OPTMOD pdp_sdl.o"
LIBS="$LIBS -lSDL"
AC_DEFINE(HAVE_PDP_SDL, 1, build pdp_sdl),
echo " libSDL not found: not building pdp_sdl")
fi
echo target is $PDP_TARGET
echo "used configure options:"
echo " --enable-mmx=$enable_mmx"
echo " --enable-quicktime=$enable_quicktime"
echo " --enable-v4l=$enable_v4l"
echo " --enable-pwc=$enable_pwc"
echo " --enable-sdl=$enable_sdl"
echo " --enable-x=$enable_x"
echo " --enable-xv=$enable_xv"
echo " --enable-glx=$enable_glx"
echo " --enable-gsl=$enable_gsl"
echo " --enable-png=$enable_png"
echo " --enable-debug=$enable_debug"
AC_SUBST(PD_CPPFLAGS)
AC_SUBST(PD_EXECUTABLE)
AC_SUBST(PDP_EXTRA_CPPFLAGS)
AC_SUBST(PDP_CFLAGS)
AC_SUBST(PDP_EXTRA_CFLAGS)
AC_SUBST(PDP_LIBRARY_NAME)
AC_SUBST(PDP_TARGET)
AC_SUBST(PDP_OPTMOD)
AC_SUBST(PDP_X11MOD)
AC_SUBST(PDP_PDMOD)
AC_SUBST(PDP_OPTTYPES)
AC_SUBST(PDP_IMAGE_BASIC)
AC_SUBST(PDP_IMAGE_SPECIAL)
AC_SUBST(PDP_MATRIX_BASIC)
AC_CONFIG_FILES(Makefile.config)
AC_CONFIG_FILES(bin/pdp-config)
AC_OUTPUT
--- NEW FILE: COPYING ---
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR PDP.LICENSE, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
--- NEW FILE: README ---
PDP - Pure Data Packet v0.12.4
a packet processing library for pure data
Copyright (c) by Tom Schouten <pdp(a)zzz.kotnet.org>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
The GNU Public Licence can be found in the file COPYING
------------------------------------------------------------------
This external pd library is a framework for image/video processing (and
other raw data packets) that is fast, simple and flexible and as much
as possible compatible with the pd messaging system.
This distro contains the main pdp library and 3 extension libs:
* pdp_scaf (in directory scaf/)
* pdp_opengl (in directory opengl/)
* pdp_guile (in directory guile)
Features:
* packet formats: greyscale and YCrCb encoded images,
binary cellular automata (CA), textures, render buffers,
matrices.
* sources: noise, video4linux and quicktime (with audio), CA, plasma
* sinks: xvideo display, sdl, glx display
* filters: convolution, biquad time, biquad space, CA
* warping: rotate, zoom, stretch
* transforms: colour translation/scaling, grey->palette
* add, mul, mix, random pixel mix
* utility objs: packet register, snapshot, trigger
* packet delay line, loop, ..
* and more.. (see doc/reference.txt)
Optional features
* cellular automata simulator and effects processor with
built in forth extension language (only for mmx)
* opengl 3d processing (gem like, but built around packets)
* embedded guile interpreter
See the README files in the scaf/ opengl/ and guile/ dirs for more
info on the extension libraries.
Requirements:
* pd
* linux
* libgsl
* a video4linux device for video input. special support for
philips webcam included.
* libquicktime (not quicktime4linux!) for quicktime playback.
* libpng for png image loading/saving
* an X display with XVideo extension, glx or SDL for video display.
Documentation:
When you use "make install" to install pd, all docs will be in
the pd doc directory. Right click on an object and select help
for a help patch. The pdp directory in pd's doc contains a
reference.txt file which lists all objects and abstractions and
an introduction and example section.
NOTE: all help patches use a pdp_help_input and pdp_help_output
abstraction. you can edit these to choose which input or output
object you want for the help patches.
Building:
./configure
make
Options for configure:
--enable-mmx compile with mmx support
--enable-pwc force pdp_v4l to use philips web cam
If pd is not installed in /usr/local you'll have to
specify the prefix on the configure command line with
./configure --prefix=/prefix
type
make install
To install pdp in $prefix/lib/pd: the library in externs/
the abstractions in extra/ and the documentation in doc/5.reference
and doc/pdp
You can also try the "buildall" script. This will configure, build
and install the whole distribution. It works for intel/mmx.
NOTE: If you're not using the standard pd install location, and have
everything in a single tree, just untar pdp next to the pd source tree,
or set the prefix dir to the location of the pd source.
Bugs:
See the TODO file. Apart from the few items listed on top of this
file, pdp is fairly stable: i am unaware of crash bugs. If you encounter
a crash please consider sending a bug report.
PiDiP Is Definitely In Pieces
Have a look at Yves Degoyon's PiDiP library, the must have addition
to the basic pdp library. It contains a lot of extra effects (from
EffecTV and FreeJ), a quicktime recording object, streaming modules,
ascii art objects ... (the list is growing rapidly ;)
Yves also did a gem2pd and a pdp2gem object to connect pdp and gem
together.
http://ydegoyon.free.fr/
Acknowledgements
PDP is no longer a one man show. Many thanks to the people who
directly or indirectly contributed to this project. Either by
writing a giant extension lib (thanks Yves) or by contributing code
snippets (Thanks Martin, CK), or by giving mental support, feedback,
bug reports and ideas.
I also wish to thank the GEM crew. This project borrows a lot of ideas
and some code from the GEM project. And while i'm at it, i wish to
thank everyone who contributed code to the PD project as a whole and
the people that are very helpful at answering questions on the mailing
list.
Last but not least i wish to thank Miller for making the PD project
open source. If that didn't happen i wouldn't know what i'd be doing
now :)
Some Remarks:
* New versions of this package can be found at
http://zwizwa.fartit.com/pd/pdp
Experimental relases are in the subdirectory test/
* If you have libquicktime and quicktime4linux installed, this can
give problems with the configure script. Consider removing
quicktime4linux. (libquicktime is a drop-in replacement).
* The modules that depend on system libraries only get compiled when
the configure script can locate them. If compilation or linking fails
please let me know.
* Packets can be processed in a low priority thread with a dropping
mechanism to prevent overload or audio drops, or they can be processed
in the main pd thread. This can be set/unset by sending a "thread x"
message to pdp_control. Processing in pdp thread is off by default.
Use the pd thread for rock solid video timing. Increase the audio
latency to avoid dropouts. If you want low audio latency, and don't
care about a dropped video frame here and there, switch on the pdp
thread. Note that when using the pdp thread, the control flow is no
longer depth first. Additinal delays will be introduced.
* Pdp runs on osx, using an x server (apple or fink) and libquickime
(fink). pdp_xv does not work yet. Once apple includes xv support in
their x server, it should. Until then, use pdp_glx for output.
* Some quicktime remarks: pdp_qt~ is still a bit experimental, you might
try pdp_yqt in yves' lib to see if it works better for you. Also, it
seems that libquicktime does not work with compressed headers. The
suggested codec is jpeg (photo) and uncompressed audio with the same
samplerate as the one pd is using. You can use other codecs, but i've
found this one to perform the best. (hint: compile libquicktime with
mmx jpeg support) Try to avoid the mpga codec. It is haunted.
* The reason i use YV12 and not RGB is simple: it's faster, and for
linear operations it doesn't make much difference. Most camera's and
codecs use a luma/chroma system, and most video cards support hardware
accellerated display. Note that in YUV, the u (Cb) and v (Cr) components
can be negative, so saturation after multiplication with a positive
(or negative) value produces not only black and white, but also red,
green, blue and their complements. In short, in YUV, nonlinear operations
have a different effect than in RGB. Another thing: all the spatial
operations are not implemented "correctly" because of the subsampling
involved.The image packets are 16bit/component planar. This is to
simplify the mmx code and to have a little more headroom and precision
for processing.
* Since version 0.11 there is a type system used for identifying a
packet type and performing type conversion. A type is represented
by a symbol, with subtypes separated by the "/" character. I.e.
"image/grey/320x240" is a grey 16 bit/component image with dimensions
320 by 240. For conversions a wildcard can be specified. I.e.
"image/*/*" which matches image type packets with all encodings
and dimensions.
* Since version 0.12 there are 2 different image data types: "image/*/*"
and "bitmap/*/*". The image type is the native 16 bit/component pdp
type. It supports the subtypes "image/grey/*": one channel grey
scale images, "image/YCrCb/*": luma/chroma packets with subsampled
chroma planes and "image/multi/*": a multi channel planar format (i.e.
to store 3 or 4 channel rgb or rgba data). Almost all processors
use this data type. The bitmap type is an intermediate type which
can contain standard fourcc encoded 8 bit/component images i.e.
"bitmap/rgb/*", "bitmap/yv12/*", "bitmap/grey/*". Currently no processors
support this type natively, so you have to use pdp_convert to convert
them to "image/*/*".
* Writing new objects is not much different than normal pd externs.
Pdp just adds some functions to the pd kernel for package allocation,
manipulation and communication. The api is very raw to keep it as
simple as possible. Since 0.10 there is a pdp_base object you can
derive your objects from. Have a look at pdp_add, pdp_gain and
pdp_noise to see how it works. There is not much documentation, but
i do my best to keep things clean so the code and the header files
should get you started. You can always just send me an email for info,
or ask on the pd-dev list. Since version 0.12 there is a simple forth
scripting language in pdp. This is far from finished, but it should
make pdp programming a lot easier.
* Philips webcam detection is now automatic. However this requires a
fairly recent kernel (one which includes the pwc driver version 8.6
or higher). If you have a pwc and pdp_v4l does not display a
"pwc detected" message, you can conifigure with --enable-pwc. This
forces pdp_v4l to use the pwc api extensions.
Directory structure:
abstractions/ some abstractions that use the pdp objects
doc/introduction/ getting started with pdp
doc/examples/ some example patches
doc/objects/ pd style reference documentation
include/ header files
modules/ pd object code
opengl/ opengl extension lib (experimental)
scaf/ CA extension lib
guile/ scheme extension lib
system/ core pdp system
Bugreports, feature suggestions, code, documentation, example patches
and general comments and questions are welcome.
Have Fun,
Tom
last modified: 2003/07/20
--- NEW FILE: buildall ---
#!/bin/sh
# a build script to build and configure the entire pdp distro
# might need some editing to work for you
# build the stable stuff
autoconf && ./configure --enable-mmx --prefix=/home/tom/pd && make install
cd scaf
autoconf && ./configure && make install
cd ..
# build the experimental stuff
make -C opengl
--- NEW FILE: TODO ---
todo 0.12.x:
best to do an intermediate release for documentation. 0.13 is not
there yet.
* check reference.txt
known bugs:
* running out of memory (using delay lines or loops) will likely crash pd.
short story: don't, use pdp_control's memlimit for limiting pdp's memory usage.
* no known other fatal (crashing) bugs. please let me know if you find one.
pdp/libpdp remark:
i'm working on a version 2 of pdp. until that is finished, pdp proper will
probably be frozen, except for bug fixes.
todo 0.13:
* yves shm code
* make fobs (all c object code usable in packet forth should be wrapped (automaticly??))
* pdp_xwindow event handling is not thread safe (fixed ?)
* fine tune udp protocol
* solve scheduling probs: pd+3dp = ok, pd+pdp+(3dp) = not
(lots of frags -> video slow, few frags -> audio drops.
pdp threading is not implemented everywhere and is a problem for feedback stuff. think about
a synchronous dropping scheme (central point of failure), like for 3dp. most of the threading
problems could be solved with the new threadsafe pd 0.37 -> check this out)
* add source type to source objects (noise,plasma,constant,...) (solve with forth)
* pdp_crop/pad
* seed plasma
* reorganize headers to cut down compile time (done for core stuff, move pd objects to forth)
* fullscreen x command -> add window manager suppression
* where to solve autoconvert? per type, or central in pdp_base? 2 cases:
- template based autoconvert: in pdp_base
- compatibility based autoconvert: i.e. pdp_add (solve in base: move_passive)
* finish high level packet conversion:
- move 8bit images to packet level (iow: cleanup pdp_qt, pdp_v4l, pdp_xv) (solve with forth)
- add bitmap packet support to source modules (optim for pdp_opengl usage)
(solve with sliceforth: pdp image processing should become independent of image encoding: at least
packed 8/16 rgb(a), and all planar rgb/yuv formats should be well supported: sliceforth feeders)
- get rid of pdp_type* methods
* fix mac/linux name differences (use pdp_video, pdp_movie, pdp_window)
* pdp_xv framerate doc + pwc addons
todo 0.14:
* stress test the memory manager. it looks like there's a bug that pops up after running for a while
* enable audio output on bttv cards in pdp_v4l
* fix cache slicer objects + thread problems (fixed in sliceforth)
* derive as much classes as possible from pdp_base class (obsolete: use forth instead)
* displacement warp, substitution warp, refraction warp, timespace warp, wormhole warp
* check the use of varargs for image processing dispatching routine (obsolete: forth)
* more scopes
* 2D affine transforms parametrized by vectors (center, x-axis, y-axis) (np1 + matrix processing objects)
* some abstractions around pdp_cheby (colour shape, ...)
* efficient rescalers: pdp_double pdp_halve (+ efficient arbitrary scaler in sliceforth)
* move float color conversion and float<->fixed point conv code to system
* crop, shift (pad+scroll)
* solve biquad (blur) mmx boundary init prob (bands at edges: solve with proper init?) (sliceforth)
* optimize blur effect (1 pole ? / dependency stalls) (sliceforth)
* jpeg/png packet and streaming support (pdp_netsend / pdp_netreceive : binary compat issues!!)
* find out why resampling code (warping) is so slow (reg->mem->reg->mem stalls?) (solve in sliceforth)
* mmx profiling (done: sliceforth)
* add audio resampling in pdp_qt~
* use pd_error instead of post for errors
* ascii art packet processors
* 3D time space interpolation
* colour keying
* motion tracking
* moebius transforms
* type multiplexing: find a way to use the same name for packet processors. (solved in forth: polymorhpy)
i.e. pdp_add should add images, but also vectors, ascii packets, textures,...
experimental stuff
* modify 2D rotation to be used as arbitrary rotation (givens)
* add 3D rotation
* frame rate limited delay line (burst delay?)
* optimize resampling code (mipmapped packed 16bit format?)
* better type handling
core is in place. todo:
- better (tree) search algorithm (breadth first + cost)
- add more converters