Fantastic idea,
I will be working on a few tutorials myself soon.
I suppose we should design a template for tutorials to keep things standard,
anyone with documentation experience have any suggestions? an initial thought would be following Chris's format with html plus example patches...
Ben
----- Original Message ----- From: Hans-Christoph Steiner hans@eds.org Date: Sunday, April 27, 2003 11:28 am Subject: RE: [PD] teaching PD to newbies [WAS: Re: [GEM] GEM users request ]
It would be really great if we could combine all of the existing tutorialsout there into one coherent, navigatible set of tutorials. Just like PDDP is becoming the central repository for docs, and the CVS is the centralrepository for externals, there should also be a central repository for tutorials.
I think that the tutorials and PDDP should ultimately be part of the pure-data.sf.net CVS. It makes working collaboratively much easier than if these files are spread out all over the net.
Once this semester is over, and I get some breathing room, I am going to make a "Getting Help" section for pure-data.org with links to all of the docs and tutorials I can find. If all of the docs and tutorials were interconnected and easily navigatible, that would be an amazing resource.
.hc
On Fri, 25 Apr 2003, David Sabine wrote:
Hello all,
This type of idea is inline with my eventual goal for the PDDP
files.>
I have felt that it's very important to, aside from brief and
precise> explanations of the inlets/outlets and arguments of each object, offer at
least one example of the object being used in a real and typical
situation.> I haven't written any complete tutorials, because I haven't felt that it was
part of the PDDP mandate -- however, I've been able to offer some 'real-world' examples of the objects in context.
As tutorials are written and completed I would like to provide
web links in
the PDDP to relevant tutorials. For example, if an online
tutorial shows a
typical usage of [loadbang] (or anything else), then the
[loadbang].pd help
document should provide a link to that tutorial.
Obviously, [loadbang] is rather straight forward, but other help
files would
benefit a lot from online tutorials.
For those writing these wonderful tutorials - I would appreciate
if you
contact me if you feel any of the PDDP files deserve a link to your tutorial.
Regards, Dave Sabine
p.s.: I like this thread a lot. There have been some good ideas
- many of
which are possible, important, and will make PD a more valuable
and useable
tool for all users.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
zen
\[D[D[D[D
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
I've also been enjoying this thread quite a bit! I have an idea which I would like to float by the list. A couple years ago, when I was working a bit with Reaktor, I spent some time on a user list where they had little "contests" to build different kinds of synths. One thing I saw a lot in the Reaktor-world was that there were a lot of user- and commercially-developed patches in existance [the ones from Lazyfish stand out as the really unique ones] that one could take apart and learn from.
Now, PD is different from Reaktor in many ways, and PD users also probably want to do different things than emulate classic synths with such rigor as Reaktor users, but why not provide the PD community with "ready mades" for simple tasks which they can dissect and learn from those who have already mastered the program? There are already a few very nice abstractions out there, with Looppool and Console being my two favs. Let's add to the collection.
So, my proposal is this:
A friendly contest to build a few end-user tools in PD and GEM.
These tools could be things like this: ---a video mixer for two files, with effects ---a video processor for an incoming stream, with effects ---an audiomixer for two files or incoming streams, with effects ---an event sequencer, with randomization, shuffle and a few banks of presets ---other ideas?
These tools should not be dry, programmer's demo-patches, but should be creatively engineered instruments which give way to many artistic possibilities, and inspire new users to explore the possibilities of PD as a programming environment.
These tools should be abstractions, not externals.
The abstractions should be cross-platform, and therfore use only common external libraries: GEM, IEMlib, GGEE and Zexy. [Please note: this is not to invalidate the hard work of all the amazing external programmers in the PD world, it is simply to keep the demo patches as accessible as possible to a new user, and to keep them from getting lost in tracking down, compiling and configuring tons of externals, which may or may not work on all platforms, to use something... Looppool is, unfortunately, a classic example of this....]
The abstractions should contain enough internal documentation [comments, etc] to make them understandable for a new user to dissect them.
Once a decent collection of these abstractions has been made, they should be effectively intergrated into the PDDB, PDDP, CVS and IEM pages.
please let me know what you all think of this, Derek
bbogart@ryerson.ca wrote:
Fantastic idea,
I will be working on a few tutorials myself soon.
I suppose we should design a template for tutorials to keep things standard,
anyone with documentation experience have any suggestions? an initial thought would be following Chris's format with html plus example patches...
Ben
----- Original Message ----- From: Hans-Christoph Steiner hans@eds.org Date: Sunday, April 27, 2003 11:28 am Subject: RE: [PD] teaching PD to newbies [WAS: Re: [GEM] GEM users request ]
It would be really great if we could combine all of the existing tutorialsout there into one coherent, navigatible set of tutorials. Just like PDDP is becoming the central repository for docs, and the CVS is the centralrepository for externals, there should also be a central repository for tutorials.
I think that the tutorials and PDDP should ultimately be part of the pure-data.sf.net CVS. It makes working collaboratively much easier than if these files are spread out all over the net.
Once this semester is over, and I get some breathing room, I am going to make a "Getting Help" section for pure-data.org with links to all of the docs and tutorials I can find. If all of the docs and tutorials were interconnected and easily navigatible, that would be an amazing resource.
.hc
On Fri, 25 Apr 2003, David Sabine wrote:
Hello all,
This type of idea is inline with my eventual goal for the PDDP
files.>
I have felt that it's very important to, aside from brief and
precise> explanations of the inlets/outlets and arguments of each object, offer at
least one example of the object being used in a real and typical
situation.> I haven't written any complete tutorials, because I haven't felt that it was
part of the PDDP mandate -- however, I've been able to offer some 'real-world' examples of the objects in context.
As tutorials are written and completed I would like to provide
web links in
the PDDP to relevant tutorials. For example, if an online
tutorial shows a
typical usage of [loadbang] (or anything else), then the
[loadbang].pd help
document should provide a link to that tutorial.
Obviously, [loadbang] is rather straight forward, but other help
files would
benefit a lot from online tutorials.
For those writing these wonderful tutorials - I would appreciate
if you
contact me if you feel any of the PDDP files deserve a link to your tutorial.
Regards, Dave Sabine
p.s.: I like this thread a lot. There have been some good ideas
- many of
which are possible, important, and will make PD a more valuable
and useable
tool for all users.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
zen
\[D[D[D[D
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Fantastic idea,
I will be working on a few tutorials myself soon.
I suppose we should design a template for tutorials to keep things standard,
anyone with documentation experience have any suggestions? an initial thought would be following Chris's format with html plus example patches...
Here are some of my reasonings for using html:
- html is a widely used standard
- web browsers are very common (some are even part of the OS...)
- html is very easy to browse and organize
- it's printer friendly
- no need for special software to write html just a text editor
- easy to link to the content of the tutorials rather than a binary
download (which will be offered too)
- modular design, just like pd ;)
- easy to update
the format of the info might not be the best right now, but i think tutorials should have working example patches for illustrative purposes. someone could write a tutorial that had the user write the patch as part of the tutorial, but i would still include a 'solution' patch in case the user had trouble building their own version.
also, i picked the subpatch style of presenting concepts and techniques because of the modular nature which allows for easy reuse of the examples. this might help users get going building their own patches. i think it cuts down on the visual clutter of large pd patches as well.
i'm not sure if the pics of the patches above the paragraph descriptions are the best way to present the content of the patches in the tutorial. it does introduce a potential problem where the tutorial is less useful if the .jpg files are not in the right place or missing. to make this less problematic, i plan to gzip the tutorial when it's more complete.
any suggestions about the format are welcome, and if someone wants to design a new, better format please do!
cgc
Ben
-
bbogart＠ryerson.ca -
chris clepper -
derek holzer