Collection of abstractions for Pd
=================================

This is a collection of abstractions for Pd. Pd is a language that is very
low-level. There are several concepts that need a certain amount of work in
order to be implemented. Instead of reimplementing these higher level concepts
again and again, this collection of abstractions try to establish a layer of
Pd abstractions that are reusable libraries that can be shared by Pd users.


What kind of abstractions?
==========================

One of the problems with organizing all this is the vague definition of
"abstraction" and "external".  "application" and "object" are much more useful
distinctions.  Therefore, there are two sections to the build system, one for
Pd patches which are objects, and another for Pd patches that are
"applications" (also examples, demos, etc.).


Criteria for Adding Patches
===========================

Patches that are added to this section ideally should be written using only
core Pd objects, without using externals whenever possible.  If that if not
possible, then it should work with the externals included with the Pd-extended
builds.

You can either send your abstraction with the request for adding it to the
pd-dev list, or if you are a member of the SourceForge project already, you
can add them by yourself.

If you have questions, please post them to the pd-dev list.  You can find all
of the mailing lists here:  http://puredata.org/community/lists

We are working on a style guide, you can see the current rendition in CVS in
doc/pddp/pddp_style_guide.pd


How to add your library of patches
==================================

The best way to start is to copy the complete section of an existing library,
like memento.  Then do a case-preserving search-and-replace, replacing
"memento" with the name of your library.  Editors such as emacs will make the
replacements will preversing the case of the text it is replacing.  For
example, replacing "memento" with "mylibrary" will make these changes:

MEMENTO_NAME = memento
objects_memento:

to this:

MYLIBRARY_NAME = mylibrary
objects_mylibrary:

If your editor does not do this, you will need to do two separate
search-and-replace actions, one for all lowercase, and another for all
uppercase.

Once you have your section setup after the search-and-replace, you need to
edit the paths of the files that you want to include.  The paths will be the
only text written out.  All of the installation paths will be Makefile
variables.  Check the below example:

	install -d $(HELP_DEST)/$(MEMENTO_NAME)
	install -p $(ABSTRACTIONS_SRC)/rradical/memento/*-help.pd \
		$(HELP_DEST)/$(MEMENTO_NAME)

becomes:

	install -d $(HELP_DEST)/$(MYLIBRARY_NAME)
	install -p $(ABSTRACTIONS_SRC)/mylibrary/*-help.pd \
		$(HELP_DEST)/$(MYLIBRARY_NAME)


Also, since it is common to store the help patches in the same directory as
the object patchs, you can use this pattern to exclude the help patches from
being copied to $(OBJECTS_DEST):

	install -p $(shell ls -1 $(ABSTRACTIONS_SRC)/mylibrary/*.pd | \
		grep -v '\-help.pd')  $(OBJECTS_DEST)/$(MYLIBRARY_NAME)




Explanations of Terms
=====================

MYLIBRARY_NAME = mylibrary

    At the top of each library's section in the Makefile, you will see a
	 variable MYLIBRARY_NAME.  This variable is the name used to install the
	 abstractions.  This should be all lowercase since its used in the loading
	 of objects within Pd (e.g. [mylibrary/myobject]).


$(APPLICATIONS_DEST): 

	 If your project is an application or patch that is meant to be run
	 directly, then it should go into this directory in its own subdirectory.
	 This directory is a browsable collection of applications.  If your
	 application has a lot of files associated with it, put a main patch and
	 have the extra files in a subdirectory.  rradical/usecases/showcase is a
	 good example of this.  This is the only place were mixed or upper case is
	 appropriate in directory names.


$(DOCS_DEST):
    All help patches should go into this directory in a subdirectory with the
    same nameas the subdirectory for your objects.  For example, for
    [mylibrary/myobject] above, the helpfile would be "mylibrary/myobject-help.pd".

	 The subdirectory name (e.g. mylibrary) should always be all lowercase.


$(MANUALS_DEST): 

    If you have any other kinds of documentation, like a text or HTML manual,
	 or a Pd-based tutorial, then it should go into this directory, again in a
	 subdirectory with the same name as the library or application.  Using the
	 previous example again, the "mylibrary" manual would be
	 "mylibrary/mylibrary.html".

	 The subdirectory name (e.g. mylibrary) should always be all lowercase.


$(OBJECTS_DEST):

    If your project consists of objects that are meant to be reused in other
    patches rather than used as a application, then they should go into this
    directory.  

	 They should be in a directory with a distinct name.  This will be the name
    of your library of objects, which can be added to the path, or called
    directly (e.g. [mylibrary/myobject]).

	 The subdirectory name (e.g. mylibrary) should always be all lowercase.


"objects" targets
    To add your objects to this build system, first make your own target and
    add it to the "objects" target.  For example: for the RRADical objects,
    there is a target called "objects_rradical:" which does everything needed
    to install the RRADical objects.  This includes installing help patches
    and any other documentation. 


"applications" targets:
   This target is meant for any patch that is intended to be opened up and
   used, played, ran, etc.  The RRADical the-showcase.pd is a good example