[PD] Managing really big PD projects?? Style guide or best practice etc?

[Frank Barknecht]

Hallo,
rodney hat gesagt: // rodney wrote:

> I have been building a project  in pd and lately it has got difficult to
> manage because of the complex web of spagetti all over the place.
> 
> I'd like to hear others' advice on sensible architectures for PD projects to
> prevent them becoming unweildy and confusing.

My RRADical abstraction collection could be an example for how to
organize patches. Big projects need reusability. So every
functionality that would feel natural as a standalone modul should be
an abstraction.

> Especially, how you deal with:
> - lots of abstractions with multiple instances

This is no problem, as long as you: 

- localize *everything*, that could be global. Never use names that do
  not start with "$0-" for senders and tables. Use table instead of
  arrays. 

- abstractions with inlets are almost always better than senders. 

- direct connections are good, too.

- learn how passing $0 as abstraction argument keeps your names 
  local even in sub-abstractions.

- [makefilename] can make every name a $0-name, [prepend]---[; $1 $2(
  makes it a sender.

- don't write abstractions with more than 4 arguments.

- don't write abstractions with more than 4 inlets.

- even 4 is too much.

- fight inlet count explosions with [route] or [OSCroute].

- write help files for all abstractions.

- [inlet tooltip] might be useful. help files are more important. ;)

- use graph on parent.

> - send and receive objects and remembering where they all go to - come from

- don't try too hard to remember send and receive names at all! Build
  abstractions on a higher level of abstraction and remember how they
  are used (with help-files). 
  
  Example: You're building a sample player. You need a [r
  $0-filename], [r $0-speed], [r $0-volume]. Make it an abstraction
  with methods for all three:

  [inlet speed_filename_volume]
  |
  [route speed filename volume]
  |
  ...

  and document the usage in a help file.

- GUI objects: use the same name for labels and send/receives, the
  sender/receivers always prepended with "$0-" of course.

- GUI 2: use the same name for sends and receives. It works!

- same s/r name does not work for standard symbol and number objects.
  Try to avoid sending to them until it works, or use explicit s/r
  objects.

> - identifying where slow-downs occur in big patch networks

- Tom Schouten: "use Forth, Python, Scheme. Don't optimize too early"

- use dummy abstractions: [inlet~]---[outlet~] for debugging.

- last resort: replacing abstractions with externals

> - keeping notes of your project in a way that makes sense after not looking
> at it for a month or two. :)

- use reStructuredText: http://docutils.sf.net

> Rodney Berry
> ATR Media Information Science Laboratories
> Kyoto Japan

- invite Frank B. to Japan. :)

Ciao
-- 
 Frank Barknecht                               _ ______footils.org__