Views
Now that Pd has the beginnings of a fully functional namespace, its time to start thinking of Pd as a platform. The next big step is organizing the vast amount of code into coherent libraries with consistent interface paradigms. This page is a scratch pad to start working out ideas of how to organize the Pd platform libraries.
Library Structure
One key part is defining a standard library format. Libdir is close to working, but needs some additions to work for all libraries. One key thing to add to libdir is a shared library that is loaded first. Then when each objectclass is loaded from its individual file, the shared code will be available.
-
libfoo.so (loaded by pd)
-
libfoo.tcl (loaded by pd-gui)
Library Hierarchy
Generally, i + IOhannes? think, that we should differentiate between different types of data on a high level rather than a low level. e.g. i would recommend '/math/+' and '/audio/math/+~', instead of '/math/audio/+~' (as shown below). The reasoning behind this is, that the disambiguation at a low level will quickly become unmaintainable (except for some very generic types like signals and floats; as soon as you would like to apply this schematics to library-defined types (like image-buffers in pdp & Gem or grids in GridFlow?), hell will break loose.
References
Pd-vanilla
For reference, here is the list of categories in Pd-vanilla 0.42-4 (notice some inconsistencies in the names, that could be corrected).
-
glue
-
time
-
math
-
midi
-
tables
-
misc
-
audio math
-
audio glue
-
audio oscillators and tables
-
audio filters
-
audio delay
-
subwindows
-
data templates
-
acessing data
-
obsolete
Suggestions for the new category structure
glue
Dumb question: why is this section called glue? Would it make more sense to be called control? Or is it a too obvious csound reference?
-
all objects from pd-vanilla's same category
-
glue/time - time operations + info
-
all objects from pd-vanilla's same category
-
cputime, realtime, timer
-
time, gmtime, localtime
-
timezone
-
date +%Y.%M.%D
-
-
glue/math - math operations
-
all objects from pd-vanilla's same category
-
cart2pol, rad2deg
-
FFT
-
convolution
-
math/list
-
math/matrix
-
-
glue/tables
-
all objects from pd-vanilla's same category
-
relevant objects from pd-vanilla's acessing data category
-
VASP
-
midi
-
all objects from pd-vanilla's same category
object - objects for building objects
-
float_argument, symbol_argument, any_argument
-
objects for handling dynamic patch generation
regexp - regular expressions
-
regexp
-
regsub
-
pattern match
mapping - mapping data from inputs to outputs
-
polar, spiral
-
one2two, one2three
-
lowpass
audio
Should this category be called signal instead of audio? (or again another csound reference?)
-
audio/glue
-
all objects from pd-vanilla's same category
-
-
audio/math
-
all objects from pd-vanilla's same category
-
-
audio/oscillators
-
sine~, square~, triangle~, ...
-
audio/oscillators/pure
-
sine~, square~, triangle~ (two libraries probably make sense here, one for mathematically pure oscillators, and another for bandwidth-limited oscillators. Perhaps this could be called "generators")
-
-
-
audio/tables
-
all objects from pd-vanilla's same category
-
-
audio/time
-
all objects from pd-vanilla's same category
-
-
audio/filter
-
all objects from pd-vanilla's same category
-
-
audio/reverb
-
yafr~, freeverb~, etc.
-
-
audio/synth
-
vocoder~, FM, karplus/strong, etc.
-
buffer - buffer data streams
why not join this category with glue/time?
-
pipe
data templates
-
all objects from pd-vanilla's same category
-
relevant objects from pd-vanilla's acessing data category
graphics / video
-
Gem
-
Pidip
-
Pdp
-
Framestein
-
Gridflow
gui - classes for building GUIs
-
gui
-
vslider, hslider, bng, entry, knob, etc.
-
-
gui/audio
-
dsp, slider+vu, Scope~, sonogram~, etc
-
-
gui/file
-
playlist
-
-
TkWidget - Pd ports of the Tk widgets
file - file operations
-
chdir, chroot, mkdir, rmdir
-
chmod, chown, umask
-
ls, glob, link
-
move, rename, copy, delete
-
get file info (data, perms, size, atime, mtime, etc)
io - handle IO from files and ports
-
usb, serial, parallel
-
hid
-
qlist, text, xml, sql
-
mouse, joystick, gamepad, tablet
-
multio, arduino, miditron, memPIO
net - network primitives
-
sockets
-
OSC, UPD
-
URIs?
-
HTTP
-
streaming
databases - objects for using databases
-
SQL a library for using SQL databases
misc
I suggest to deprecate this category from pd-van and divide the objects between other categories
subwindows
I suggest to deprecate this category from pd-van and divide the objects between other categories
obsolete
-
all objects from pd-vanilla's same category
Documentation
After (or while) restructuring the new categories for pd-ext objects, an automatized solution for the documentation should be found. Here are some pointers:
-
some suggestions at methods of organising an automatised documentation - follow thread
-
lost the reference, can Mr. Schebella correct this sentence?