Work on Pd has traditionally been very fractured, so we have a lot of
partially complete efforts and no complete ones. I really think
we'll all be better off if we all focus on one effort first and
finish it, then explore other options.
I don't want to stop anyone from doing anything, but I would really
like to see a really nice manual for Pd completed.
.hc
On Apr 26, 2006, at 12:06 PM, adam wrote:
I think that there should be two strategies, a traditional 'manual'
and a PD patch manual. I dont see any need really for having just one.
Material can easily be copied between the two.the PD patch manual is a very exciting approach, more exciting I think than a 'traditional' approach, however, just cause i'm conservative
and boring I will keep scratching away at the manual i started at flossmanuals, and if anyone wants to pitch in that would be cool :)adam
..on Tue, Apr 25, 2006 at 02:34:16PM -0500, David Powers wrote:
I think there is a huge need for exactly something like what Derek mentions--a reference manual. I don't have the internet at home,
and when I'm planning something like writing a program, my first step is to
use pencil and paper, and sketch out the parts of my design, and try
to decide the most logical way to build and test my application. A real
reference encyclopedia would make this task MUCH easier. It's not a task
that PD really lends itself too, as I tend to get all mucked up, if I
didn't figure out the answer on paper first. For me, the computer screen makes
it too easy to just start patching away without a clear idea of the logic I need.However, I think there is a strong need for a manual in another
area, and that is overall program design and application building in Pure
Data. What different ways are there to conceptualize a Pure Data application?
What approaches can one take in application design? What decisions
should be made in advance? How can one do object-oriented PD (there are at least
some parallels), and how might that differ from other approaches? What are pitfalls to avoid? What are typical problems that one can expect to encounter, including problems relating to different platforms and limitations of PD, and what are good strategies to overcome these limitations? What are different ways to do GUI and control, and to
seperate the GUI from the rest of the patch? How to optimize a patch, or
reduce CPU load on a hungry patch? How can you do testing, to see if your
idea is even feasible with a given set of CPU resources?At the very least, a thorough FAQ is essential. But even better, a
manual that has an FAQ index pointing to the answers in context.
Remember, some people coming to PD, don't have real programming experience. So
teaching some programming concepts might be helpful--I myself don't totally
know the best way to work on large scale design in PD. I mostly learned
programming on my own, so I'm definitely lacking in ideas about how bigger
programming projects are organized. I don't even know what philosophies exist
(extreme programming I've heard of, but I'm sure there's many more.)THESE are the questions that I currently don't see being
addressed, except ad hoc in email exchanges on the list. They are, I would suggest, appropriate to a "manual" on PD programming, as it's not just a
matter of how a particluar object works, but would include insights gained
from the real world of programming. And honestly, when I open up PD, I'm
most likely working on a particular patch or problem. I want to have my reference material open next to me. I don't want to search through someone's
tutorial patches for the answer to one specific problem, especially if its
a more general philosophy/design question, rather than a question about a
specific object.If such a manual existed, alongside a reference manual of all the
objects and their inputs and outputs, I think PD would have great
potential to grow its user base.Just remember this: If I'm considering using a new programming
language or new musical software, the first thing I do is browse the website
and look at the manual. If the manual looks good, I'm FAR more likely to give the language a serious try. This is part of the reason why I didn't
try PD at all for a year after I first considered using it! To give another
example, I started programming in ChucK recently, partly because it has a
simple, nicely written manual (plus it's 10x quicker to develop some
things, like granular synthesis, than PD, and it has the working STK stuff that
I can't seem to get for PD Windows.) Reading the manual a couple of times
convinced me that it would do some interesting things and was worth a try.
I'm sure that I'm not the only user out there that approaches things in
this way. Accessible documentation is important -- and by accessible, I mean accessible outside of the program in question.~David
On 4/25/06, derek holzer derek@x-i.net wrote:
Hi HC, Adam,
Hans-Christoph Steiner wrote:
I am not opposed to things like PDB or ways of searching for
existing objects. But if you are going to learn the object, functional
examples work best. But a manual would not be a good way to search for
objects.In general, I don't really agree that a manual with pictures of
patches would be very useful. The functionality to learn and experiment by changing things really isn't there.OTOH, one thing that people in my workshops are always asking for
is a list of all the objects, including the externals. There isn't
really one place to get all this, except online with the PDB, but that's not
a good reference when you don't have any net access. I tried maintaining
a text file with as many as I could, but it's very incomplete.My suggestion would be to make a "dictionary" of objects, maybe
sorted by name, library or general function (dataflow, 3d, audio, video, I/O...), such as the directories which were made by the user
community for CSound. That might be useful as a PDF or hardcopy even. The PDcyclopia?d.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 109: "Lost in useless territory"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
--
Adam Hyde ~/.nl
selected projects http://www.xs4all.nl/~adam
the streaming suitcase http://www.streamingsuitcase.com
r a d i o q u a l i a http://www.radioqualia.net
Free as in 'media' email : adam@xs4all.nl mobile : + 31 6 186 75 356 (Netherlands mobile)
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it."
- Thomas
Jefferson