[PD] PDDP meeting?

[Hans-Christoph Steiner]

On Apr 25, 2006, at 9:34 PM, 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.

This has been discussed at length in PDDP meetings.  We have designed  
a system of meta data in help patches.  This meta data will  
automatically parsed and used to generate a searchable index.  We  
have the plan, we just need help implementing.

http://puredata.org/dev/pddp

> 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.)


http://puredata.org/docs/faq

Its a wiki!  Please update it!    This page could easily be included  
in the Pd-extended distro too.


> 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.


Please have a look at the intro tutorial/manual materials in CVS:
doc/tutorials/intro
doc/tutorials/sound
doc/tutorials/visual
doc/tutorials/networking
doc/tutorials/physical

This is a start for such a manual, its also included in the test  
releases on my site.

.hc

> 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


________________________________________________________________________ 
____

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.
Now that he can realize them, he must either change them, or perish.
		                                                -William Carlos  
Williams

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20060426/a5fc0992/attachment.htm>