HI all,
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.
Especially, how you deal with:
at it for a month or two. :)
I would be keen to collect all these pearls of wisdom into one doc for the wiki or somewhere, if one does not already exist.
Cheers, Rod
Rodney Berry ATR Media Information Science Laboratories Kyoto Japan
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. :)
Rodney Berry ATR Media Information Science Laboratories Kyoto Japan
Frank Barknecht _ ______footils.org__