sure, they are great resource, mostly for learning about Max peculiarities, but with nice introductory parts, esp. in msp tuts.
However, there are musicians, new to technology, which are lost if left on their own with Max tutorials, and there are advance hackers, which find them naive and bad style.
Ok, so lets drop the port idea then. So what can we offer newbies that find the currenct documentation too difficult (millers book)? Is a text that deals with pd pecularities necessary. What level of dsp knowledge should it assume?
Id like to be able to make a stronger case for pd vs. max at school: besides the pro's that are allready there, platforms, licence, freedom etc etc. (I don't have to preach to the choir im assuming). I still like the idea of a 'mikrokosmos for pd'. Anybody else too?
Anton
Hey there,
I think an introduction needs to be there that is at the bottom level. I've not looked at much of Miller's book but I get the impression it compliments and fills in the doc/ "tutorial" examples.
I think the first few steps in PD should assume only the use of a computer, creating shortcuts, and so on. A real introduction would involve an installation guide as well. You would be damn suprised how problematic it is for a new user to add a new -lib flag on windows. (Marc Lavallee and I actually had a hard time getting it to work ourselves, having been so long sice we touched it.)
I think documentation should start at the very bottom and build knowledge and skill slowly. It should be structured so that a user with more knowledge can jump in at a particular part and still have a good experience.
B>
Anton Woldhek wrote:
Ok, so lets drop the port idea then. So what can we offer newbies that find the currenct documentation too difficult (millers book)? Is a text that deals with pd pecularities necessary. What level of dsp knowledge should it assume?
Bela Bartok's Mikrokosmos is an excellent example of building up from the very basic. The key part of it is that he manages to make each little exercise an interesting composition, so it doesn't feel so much like exercises. This is definitely what we should aim for with tutorials.
.hc
On May 4, 2005, at 11:42 AM, B. Bogart wrote:
Hey there,
I think an introduction needs to be there that is at the bottom level. I've not looked at much of Miller's book but I get the impression it compliments and fills in the doc/ "tutorial" examples.
I think the first few steps in PD should assume only the use of a computer, creating shortcuts, and so on. A real introduction would involve an installation guide as well. You would be damn suprised how problematic it is for a new user to add a new -lib flag on windows. (Marc Lavallee and I actually had a hard time getting it to work ourselves, having been so long sice we touched it.)
I think documentation should start at the very bottom and build knowledge and skill slowly. It should be structured so that a user with more knowledge can jump in at a particular part and still have a good experience.
B>
Anton Woldhek wrote:
Ok, so lets drop the port idea then. So what can we offer newbies that find the currenct documentation too difficult (millers book)? Is a text that deals with pd pecularities necessary. What level of dsp knowledge should it assume?
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"The arc of history bends towards justice." Dr. Martin Luther King, Jr.
MP3s online anywhere?
I wonder if there is some concept for doing this time of thing outside of a audio or visual specific manner. With the current PD lecture we start with UI objects, then metro, random and counter, and then control stuff with Gem using only those objects and learning new Gem specific objects.
I think it would be great if PD documentation was fun. One thing we have not talked about is exersises in the PD tutorials. Something like "try this...." at the bottom of a page and a challange to connect the parts of the patch above.
I think once the help thing is soemwhat layed out then tutorial stuff can start. I'm doing a workshop at the end of May, but I'm not sure if its a good idea to mess with a new (experimental) format for the workshop... ? Who knows maybe I'll feel adventerous.
B
Hans-Christoph Steiner wrote:
Bela Bartok's Mikrokosmos is an excellent example of building up from the very basic. The key part of it is that he manages to make each little exercise an interesting composition, so it doesn't feel so much like exercises. This is definitely what we should aim for with tutorials.
.hc
On May 4, 2005, at 11:42 AM, B. Bogart wrote:
Hey there,
I think an introduction needs to be there that is at the bottom level. I've not looked at much of Miller's book but I get the impression it compliments and fills in the doc/ "tutorial" examples.
I think the first few steps in PD should assume only the use of a computer, creating shortcuts, and so on. A real introduction would involve an installation guide as well. You would be damn suprised how problematic it is for a new user to add a new -lib flag on windows. (Marc Lavallee and I actually had a hard time getting it to work ourselves, having been so long sice we touched it.)
I think documentation should start at the very bottom and build knowledge and skill slowly. It should be structured so that a user with more knowledge can jump in at a particular part and still have a good experience.
B>
Anton Woldhek wrote:
Ok, so lets drop the port idea then. So what can we offer newbies that find the currenct documentation too difficult (millers book)? Is a text that deals with pd pecularities necessary. What level of dsp knowledge should it assume?
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"The arc of history bends towards justice." Dr.Martin Luther King, Jr.
On May 4, 2005, at 7:08 AM, Anton Woldhek wrote:
sure, they are great resource, mostly for learning about Max peculiarities, but with nice introductory parts, esp. in msp tuts.
However, there are musicians, new to technology, which are lost if left on their own with Max tutorials, and there are advance hackers, which find them naive and bad style.
Ok, so lets drop the port idea then. So what can we offer newbies that find the currenct documentation too difficult (millers book)? Is a text that deals with pd pecularities necessary. What level of dsp knowledge should it assume?
Id like to be able to make a stronger case for pd vs. max at school: besides the pro's that are allready there, platforms, licence, freedom etc etc. (I don't have to preach to the choir im assuming). I still like the idea of a 'mikrokosmos for pd'. Anybody else too?
Yes, mikrokosmos for Pd is a great example (I assume you are talking about Bela Bartok's Mikrokosmos, which he wrote for his kids to learn piano). I started some sketches along those lines that I call "play now". The idea was a set of patches with most of the guts hidden with a clear, straightforward interface. The total newbie could then open the first patch and basically instantly start controlling the sound in real time. As they learned more, they could open the [pd guts] to see what's going on inside.
.hc
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
Hans S wrote:
Yes, mikrokosmos for Pd is a great example (I assume you are talking about Bela Bartok's Mikrokosmos, which he wrote for his kids to learn piano).
Yes, that's the Mikrokosmos I meant.
I started some sketches along those lines that I call "play now". The idea was a set of patches with most of the guts hidden with a clear, straightforward interface. The total newbie could then open the first patch and basically instantly start controlling the sound in real time. As they learned more, they could open the [pd guts] to see what's going on inside.
Cool, I'd love to collaborate on this. Im teaching pd to total n00bs at school next semester again.
B. Bogart wrote:
For the SC help, The main thing I see you after here is that you can get help no matter where you are. I can see this fitting into PD where the popup menu on objects gives you the choice between help for that particular object, help in an all_about patch that includes this object, or the start of a tutorial on using that object...
Well the main thing that I like about the sc help files is that you can include allmost anything in the standard help documentation style. You can write large texts that explain different things with some examples in between. This transparancy makes it easy to 'discover' the documentation. With pd currently, you've got a gazillion .pd's, pdfs & txt's That you can look thru and they are all accesible through different means.
Anton
Hi Anton,
I think the idea is that the array of seperate files *-help.pd all_about etc.. all get hidden from the user and they are accessible through the new help system. That so far means through the catagorical organizer or though the searching tool.
As for different types of documents I'll save this for Krzysztof's email.
B>
Anton Woldhek wrote:
B. Bogart wrote:
For the SC help, The main thing I see you after here is that you can get help no matter where you are. I can see this fitting into PD where the popup menu on objects gives you the choice between help for that particular object, help in an all_about patch that includes this object, or the start of a tutorial on using that object...
Well the main thing that I like about the sc help files is that you can include allmost anything in the standard help documentation style. You can write large texts that explain different things with some examples in between. This transparancy makes it easy to 'discover' the documentation. With pd currently, you've got a gazillion .pd's, pdfs & txt's That you can look thru and they are all accesible through different means.
Anton
On May 5, 2005, at 5:04 AM, Anton Woldhek wrote:
Hans S wrote:
Yes, mikrokosmos for Pd is a great example (I assume you are talking about Bela Bartok's Mikrokosmos, which he wrote for his kids to learn piano).
Yes, that's the Mikrokosmos I meant.
I started some sketches along those lines that I call "play now". The idea was a set of patches with most of the guts hidden with a clear, straightforward interface. The total newbie could then open the first patch and basically instantly start controlling the sound in real time. As they learned more, they could open the [pd guts] to see what's going on inside.
Cool, I'd love to collaborate on this. Im teaching pd to total n00bs at school next semester again.
I just committed a bunch of my sketches for this idea. They are in doc/tutorials/playnow. Feel free to add more, clean mine up, whatever.
Mine are definitely sketches, they need work.
.hc
B. Bogart wrote:
For the SC help, The main thing I see you after here is that you can get help no matter where you are. I can see this fitting into PD where the popup menu on objects gives you the choice between help for that particular object, help in an all_about patch that includes this object, or the start of a tutorial on using that object...
Well the main thing that I like about the sc help files is that you can include allmost anything in the standard help documentation style. You can write large texts that explain different things with some examples in between. This transparancy makes it easy to 'discover' the documentation. With pd currently, you've got a gazillion .pd's, pdfs & txt's That you can look thru and they are all accesible through different means.
Anton
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
-
Anton Woldhek -
B. Bogart -
Hans-Christoph Steiner