[PD] PDDP meeting?

adam adam at xs4all.nl
Wed Apr 26 12:06:28 CEST 2006


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 at 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 at iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >

> _______________________________________________
> PD-list at 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 at xs4all.nl
mobile : + 31 6 186 75 356 (Netherlands mobile)




More information about the Pd-list mailing list