changed:
-
----

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 ==
 * [http://lists.puredata.info/pipermail/pd-dev/2009-02/013069.html pd-dev-list discussion about categories]
 * [http://puredata.info/dev/summer-of-code/PdLib/ G Holzmann's suggestions for gos08]
 * [http://wiki.dataflow.ws/PdMtlAbstractions Pure Data Montréal abstrations]

= 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:
 * [http://lists.puredata.info/pipermail/pd-dev/2009-02/013025.html some suggestions at methods of organising an automatised documentation - follow thread]
 * [http://lists.puredata.info/pipermail/pd-dev/2009-02/013085.html sql database suggestion from dmotd]
 * [http://www.parasitaere-kapazitaeten.net/files/GENERAL_ALL.csv_.txt lost the reference, can Mr. Schebella correct this sentence?]
 * [http://lists.puredata.info/pipermail/pd-dev/attachments/20090220/b46c1e96/attachment-0001.xls (uncomplete) excel chart of pd-ext objects]