How is rawjoystick different from joystick?
Gerard
Also, I just finished up the first version of a couple of objects based on the Linux event system. The objects are called [rawmouse], [rawjoystick], and [rawevent]. They give you the raw data from the input device rather than from the GUI, like [MouseState].
joystick interface, but that shouldn't make a visible difference.
generated.
that's what I based it on....)
believe makes Pd respond whenever there is joystick event data. [joystick] uses a clock_delay, which polls, then waits for a certain length of time (5 ms by default, but configurable) I could be wrong about addpollfn. Its in m_imp.h rather than m_pd.h, so it may not be the best way to go...
I am now working on the same objects but written using libSDL, so this one should work on Win, Linux, MacOS 9/X, BSD, etc. I renamed the original [raw...] objects to [linux...] ([linuxjoystick, for example) since they are linux specific.
.hc
On Mon, 21 Apr 2003, vanDongen-Gilcher wrote:
How is rawjoystick different from joystick?
Gerard
Also, I just finished up the first version of a couple of objects based on the Linux event system. The objects are called [rawmouse], [rawjoystick], and [rawevent]. They give you the raw data from the input device rather than from the GUI, like [MouseState].
zen
\
\
\[D[D[D[D
Hans-Christoph Steiner said at "RE: [PD] mousestate."r[2003/04/22 19:46]
- [rawjoystick] uses the Linux input event system, rather than the older
joystick interface, but that shouldn't make a visible difference.
If you have configured the input layer in the kernel, /dev/js* is linked to /dev/input/js*, so [joystick] already uses the input layer.
- [rawjoystick] has a fixed number of outlets, [joystick]'s outlets are
dynamically generated.
That is curious, I think a inputlayer aware joystick driver announces its axis to the input layer. Although I think a HID joystick does it incorrectly, at least I always had the maximum number (18) axis
- [rawjoystick] supports a hat switch. (My joystick only has one, so
that's what I based it on....)
At least for my joystick, this is allready the case. The hat switches are mapped to 2 additional axis'
But the polling should be an improvement.
Gerard
On Wed, 23 Apr 2003, vanDongen-Gilcher wrote:
Hans-Christoph Steiner said at "RE: [PD] mousestate."r[2003/04/22 19:46]
- [rawjoystick] uses the Linux input event system, rather than the older
joystick interface, but that shouldn't make a visible difference.
If you have configured the input layer in the kernel, /dev/js* is linked to /dev/input/js*, so [joystick] already uses the input layer.
I meant I use it directly... [rawjoystick] uses /dev/input/event?, as does [rawmouse] and [rawevent]. /dev/input/js? wouldn't work with [rawjoystick] because of the different datatypes.
- [rawjoystick] has a fixed number of outlets, [joystick]'s outlets
are
dynamically generated.
That is curious, I think a inputlayer aware joystick driver announces its axis to the input layer.
I mean that if your joystick has 18 axes, then [joystick] will have 18 outlets for those axes, while [rawjoystick] will always have the same 6 outlets for axes. I did this to prevent the patch from breaking if you attach a different joystick.
Although I think a HID joystick does it incorrectly, at least I always had the maximum number (18) axis
I got a response from Vojtech Pavlik (Mr Linux HID) about this. Apparently, the HID drivers in linux 2.4 detect force-feedback devices as axes, thereby reporting the wrong number of axes. My joystick reports 41 axes under linux. It supposedly fixed in 2.5, but 2.5 is a major pain to install.
- [rawjoystick] supports a hat switch. (My joystick only has one, so
that's what I based it on....)
At least for my joystick, this is allready the case. The hat switches are mapped to 2 additional axis'
Well, I've only tested any of these objects on my one joystick, so...
But the polling should be an improvement.
Did you have problems with the polling latency of [joystick]? I ask because I am have started writing these same objects based on libSDL and it looks like it would be easier to use a clock_delay like [joystick] rather than the allpollfn like [rawjoystick].
Could I ask about your ff joystick setup? I am using a Saitek Cyborg 3D Force with linux 2.4.21-pre2-ff and I can't get the force feedback working. Plus linux HID reports it has 41 axes and 16 buttons (it has 6 axes and 9 buttons).
.hc
zen
\
\
\[D[D[D[D
Hi all
Over the past two weeks I have talked with a few people about GEM and most people found that the GEM distro lacked any patches that really showed off GEM's capabilities. So rather than write up some lame demo patches made by the developers, I thought maybe some of the GEM users could provide a patch or two that either does something very cool or just demonstrates some of the possibilities of GEM. This patch could be a live performance video mixer or something made for an installation that uses live video input, anything is really welcome. If you have something you would like to share with the world, please post a URL where the patch can be downloaded, and be sure to include comments, abstractions, and a proper credit for yourself!
also, i am also starting on a tutorial for GEM and if you want to help out with that effort let me know.
thanks
cgc
This is great! The working patches that come with GEM are already quite nice, I'd love to see more.
I am looking for a working [pix_snap] patch. But I don't yet have any to contribute.
.hc
On Thu, 24 Apr 2003, chris clepper wrote:
Hi all
Over the past two weeks I have talked with a few people about GEM and most people found that the GEM distro lacked any patches that really showed off GEM's capabilities. So rather than write up some lame demo patches made by the developers, I thought maybe some of the GEM users could provide a patch or two that either does something very cool or just demonstrates some of the possibilities of GEM. This patch could be a live performance video mixer or something made for an installation that uses live video input, anything is really welcome. If you have something you would like to share with the world, please post a URL where the patch can be downloaded, and be sure to include comments, abstractions, and a proper credit for yourself!
also, i am also starting on a tutorial for GEM and if you want to help out with that effort let me know.
thanks
cgc
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
chris,
after this big workshop in Amsterdam a few weeks back, i noticed that one of the things that is still really under development in the PD/GEM world is a way of teaching it coherently to non-programmers. starting with the message patches in the documentation and telling everybody about triggers, bangs, floats and dollar signs works if they can think in terms of abstract symbols already, but doesn't work at all if they are coming from the other side of it... i.e. they want to know about signal processing, making big noises and pretty pictures. an approach which goes backwards from said pretty pictures and big noises could teach them the very powerful message-handling side of PD "retroactively" so-to-speak. sneak in the data-stuff without them even realizing it, instead of slamming them up against all these abstract numbers and symbols first thing.
so your application-based tutorial is a great idea! IOhannes zmoelnig is also working on such a tutorial. i saw the beginnings of this at our workshop, and it looked good. perhaps you should join forces?
please keep me up to date on this, as i am sure i will find it very useful in my own educational excursions.
cheers, d.
chris clepper wrote:
Hi all
Over the past two weeks I have talked with a few people about GEM and most people found that the GEM distro lacked any patches that really showed off GEM's capabilities. So rather than write up some lame demo patches made by the developers, I thought maybe some of the GEM users could provide a patch or two that either does something very cool or just demonstrates some of the possibilities of GEM. This patch could be a live performance video mixer or something made for an installation that uses live video input, anything is really welcome.
If you have something you would like to share with the world, please post a URL where the patch can be downloaded, and be sure to include comments, abstractions, and a proper credit for yourself!also, i am also starting on a tutorial for GEM and if you want to help out with that effort let me know.
thanks
cgc
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hans-Christoph Steiner said at "RE: [PD] mousestate."r[2003/04/24 04:54]
Could I ask about your ff joystick setup? I am using a Saitek Cyborg 3D Force with linux 2.4.21-pre2-ff and I can't get the force feedback working. Plus linux HID reports it has 41 axes and 16 buttons (it has 6 axes and 9 buttons).
I am assuming you are using the ff-patch from Johann Deneux: http:// user.it.uu.se/~johannd/projects/ff/,
I am using the same stick. You have to use the iforce kernel module, not the HID module. This also reports the correct number of axes and buttons The HID only supports ff for a few logitech ff devices I think. Which means putting your stick on the USB-HID blacklist if you use hotplugging, somewhere in your /etc directory. Or modprobing manually: input,iforce and evdev
It should include my patch to support te Saitek stick. If not I can mail it to you.
Interesting how each kernel version reports a different number of axes (I am using 2.4.19)
Hope this helps
hi, learning to build pd-patches and learning about signal-processing - speaking for musicians - goes hand in hand... i think a tutorial tells much about dsp-tchniques and vice versa (to learn about signal processing, pd is a good way to explain and draw processes)
but on the other hand, i find it a good idea to offer a pack of patches, which can be used without understanding any programming, so that musicians can play them in performances.
marius.
----- Original Message ----- From: "derek holzer" derek@x-i.net To: "chris clepper" cclepper@artic.edu Cc: PD-list@iem.kug.ac.at Sent: Thursday, April 24, 2003 3:43 PM Subject: [PD] teaching PD to newbies [WAS: Re: [GEM] GEM users request ]
chris,
after this big workshop in Amsterdam a few weeks back, i noticed that one of the things that is still really under development in the PD/GEM world is a way of teaching it coherently to non-programmers. starting with the message patches in the documentation and telling everybody about triggers, bangs, floats and dollar signs works if they can think in terms of abstract symbols already, but doesn't work at all if they are coming from the other side of it... i.e. they want to know about signal processing, making big noises and pretty pictures. an approach which goes backwards from said pretty pictures and big noises could teach them the very powerful message-handling side of PD "retroactively" so-to-speak. sneak in the data-stuff without them even realizing it, instead of slamming them up against all these abstract numbers and symbols first thing.
so your application-based tutorial is a great idea! IOhannes zmoelnig is also working on such a tutorial. i saw the beginnings of this at our workshop, and it looked good. perhaps you should join forces?
please keep me up to date on this, as i am sure i will find it very useful in my own educational excursions.
cheers, d.
chris clepper wrote:
Hi all
Over the past two weeks I have talked with a few people about GEM and most people found that the GEM distro lacked any patches that really showed off GEM's capabilities. So rather than write up some lame demo patches made by the developers, I thought maybe some of the GEM users could provide a patch or two that either does something very cool or just demonstrates some of the possibilities of GEM. This patch could be a live performance video mixer or something made for an installation that uses live video input, anything is really welcome. If you have something you would like to share with the world, please post a URL where the patch can be downloaded, and be sure to include comments, abstractions, and a proper credit for yourself!
also, i am also starting on a tutorial for GEM and if you want to help out with that effort let me know.
thanks
cgc
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
On Fri, 2003-04-25 at 11:09, marius schebella wrote:
but on the other hand, i find it a good idea to offer a pack of patches, which can be used without understanding any programming, so that musicians can play them in performances.
Can I ask you what kind of patches to you offer and/or do they ask? What kind of operation they like to do with them? Any example of their music?
Thanks,
Maurizio Umberto Puxeddu.
On Thu, 24 Apr 2003, derek holzer wrote:
... i.e. they want to know about signal processing, making big noises and pretty pictures. an approach which goes backwards from said pretty pictures and big noises could teach them the very powerful message-handling side of PD "retroactively" so-to-speak. sneak in the data-stuff without them even realizing it, instead of slamming them up against all these abstract numbers and symbols first thing.
If something like this would exist, I would definitely use it if I have to give presentations.
Most people actually learn pd this way. They start out from something that already exists and learn by changing things. The danger of this approach is of course to miss some fundamental feature, but a tutorial designed top-down, could take care of this and cover everything.
Learning is much more efficient if it makes fun....
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Most people actually learn pd this way. They start out from something that already exists and learn by changing things. The danger of this approach is of course to miss some fundamental feature, but a tutorial designed top-down, could take care of this and cover everything.
Now this is an interesting thought. For several months I now have an unfinished Pd-tutorial in $HOME/lyx that explains my old angriff drum machine. It is botton-up in your terminology but that might really be the wrong way. Especiall something like angriff is a higher level object, that even an absolute beginner can "Just Use"(tm). Maybe I went the wrong way and I should first explain. how to make some nice drum loop, an then how this was done in the patch?
Frank Barknecht _ ______footils.org__
On Thu, 24 Apr 2003, derek holzer wrote:
... i.e. they want to know about signal processing, making big noises and pretty pictures. an approach which goes backwards from said pretty pictures and big noises could teach them the very powerful message-handling side of PD "retroactively" so-to-speak. sneak in the data-stuff without them even realizing it, instead of slamming them up against all these abstract numbers and symbols first thing.
If something like this would exist, I would definitely use it if I have to give presentations.
Most people actually learn pd this way. They start out from something that already exists and learn by changing things. The danger of this approach is of course to miss some fundamental feature, but a tutorial designed top-down, could take care of this and cover everything.
Yeah, this was sort of my thinking with the request for GEM patches, pick one that did something very nice and then build a tutorial out of it. I think this would be the 'advanced' section of the tutorial with the one I'm working on right now being the 'basic' one. My thinking was that there should be a very simple set of tutorials for those who prefer to start with 'how do I turn the thing on?', and build from there.
Here's a link to the current online tutorial: http://taproot.dyndns.org/~cgc/tutorial_gem/index.html
Learning is much more efficient if it makes fun....
I agree, which is why having a few different approaches to the tutorial would be nice.
cgc
Guenter
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.
It would be really great if we could combine all of the existing tutorials out there into one coherent, navigatible set of tutorials. Just like PDDP is becoming the central repository for docs, and the CVS is the central repository 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
Hi,
We have developed a small tutorial for our students and would like also to participate. Currently it is not available online but if there is a place at pure-data.sf.net I would upload it.
luis
At 16:28 27-04-2003, Hans-Christoph Steiner wrote:
It would be really great if we could combine all of the existing tutorials out there into one coherent, navigatible set of tutorials. Just like PDDP is becoming the central repository for docs, and the CVS is the central repository 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
hi all, the tutorials project sounds great!
For anybody developing pd docs, let me suggest looking at cycling74's stuff (it is downloadable, pdfs and patches).
They have years of experience and tons of user feedback.
Do not mean imitating, but excelling, of course.
Anytime I look around, the feeling grows stronger, that computer music development is mostly about reinventing the wheel...
Krzysztof
btw just realized, while scanning the pile of recent unread
messages from pd-list, that my last post looks like if I meant
this is just the ages old, buddy!'' (as if this was a faq), instead of
this is just the ages old [buddy]'', what I really
meant (i.e. an idiomatic max thing, now in cyclone).
So, I would like to apologize for that, sorry.
Hans-Christoph Steiner wrote:
It would be really great if we could combine all of the existing tutorials out there into one coherent, navigatible set of tutorials. Just like PDDP is becoming the central repository for docs, and the CVS is the central repository for externals, there should also be a central repository for tutorials.
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
It would be really great if we could combine all of the existing tutorials out there into one coherent, navigatible set of tutorials. Just like PDDP is becoming the central repository for docs, and the CVS is the central repository 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.
I'd second putting a "doc" section to the CVS (although I've come to hate Sourceforge's bad reliability in regard to cvs-access, grrr)
I think, at first we should not force a certain format of the tutorials on the authors. In the end, I think, HTML is not a good storage format. Something like Python's reStructuredText [http://docutils.sourceforge.net/] or a sgml/xml format [http://www.oasis-open.org/docbook/xml/4.1.2/] will be easier to convert to different output formats, like doing a printed book and such.
But discussing formats will only keep us away from doing the needed writing work, so I propose to allow any kind of format except binary document formats. To clarify: No MS-Word documents!
Frank Barknecht _ ______footils.org__
On Mon, 28 Apr 2003 12:12:04 +0200 Krzysztof Czaja czaja@chopin.edu.pl wrote:
Anytime I look around, the feeling grows stronger, that computer music development is mostly about reinventing the wheel...
because we now have the tools to reinvent things in ways that were not possible before ;)
pix.
At 16:28 27-04-2003, Hans-Christoph Steiner wrote:
It would be really great if we could combine all of the existing tutorials out there into one coherent, navigatible set of tutorials. Just like PDDP is becoming the central repository for docs, and the CVS is the central repository for externals, there should also be a central repository for tutorials.
I'm happy to donate my LJ article on Pd/GEM to the project, it's on-line here:
http://www.linuxjournal.com/article.php?sid=5994
Reiner Klenk has written a tutorial on using Pd with Ardour/JACK, you might also want to link to it :
http://www.djcj.org/LAU/quicktoots/toots/pd-ardour/
Whoever is organizing the effort can contact me regarding the use of these articles.
Best regards,
== Dave Phillips
The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm
The Linux Soundapps Site at http://linux-sound.org
Currently listening to: Harold Budd & Brian Eno, "Not Yet Remembered"
On Mon, 28 Apr 2003, Frank Barknecht wrote:
I'd second putting a "doc" section to the CVS (although I've come to hate Sourceforge's bad reliability in regard to cvs-access, grrr)
There is a doc section already, I have put Damien Henry's pd-msg package there. You are right with the SF CVS access, it has gotten worse the last few month. Hope they do something about it.
I think, at first we should not force a certain format of the tutorials on the authors. In the end, I think, HTML is not a good storage format. Something like Python's reStructuredText [http://docutils.sourceforge.net/] or a sgml/xml format [http://www.oasis-open.org/docbook/xml/4.1.2/] will be easier to convert to different output formats, like doing a printed book and such.
But discussing formats will only keep us away from doing the needed writing work, so I propose to allow any kind of format except binary document formats. To clarify: No MS-Word documents!
Plain HTML is not that bad after all, as a beginning. Its better to start working than having the barrier of having to learn yet another system. ...
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
There is a doc section already, I have put Damien Henry's pd-msg package there.
Ah, yes. I normally just work in the externals dir...
I guess, I'll now add a directory "tutorials/footils" there and check in my unfinished drum tutorial.
Plain HTML is not that bad after all, as a beginning. Its better to start working than having the barrier of having to learn yet another system. ...
Yes, document formats shouldn't matter now. Personally I like writing my docs in LyX, choose document format "LinuxDoc (SGML article)" and then export everything from LyX as is apt: HTML, pdflatex, Latex,...
When writing I don't like to see markup, so I prefer LyX with its "Word"-like look.
Recently I came to like reStructuredText, which also can be exported in a lot of formats, and has the advantage, that the "markup" is nearly invisible, too, because it follows the conventions of email-markup. A typical reST document looks like this:
I'd like to start with the *most important things* in italic letters. And so on...
This gets converted for example to html:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtm <html lang="en">
<head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="generator" content="Docutils 0.2.8: http://docutils.sourceforge.net/" /> <title>My first tutorial</title> <link rel="stylesheet" href="default.css" type="text/css" /> </head> <body> <div class="document" id="my-first-tutorial"> <h1 class="title">My first tutorial</h1> <h2 class="subtitle" id="chapter-1-starting-pd">Chapter 1: Starting Pd</h2> <p>I'd like to start with the <em>most important things</em> in italic letters. And so on...</p> </div> </body> </html>
Now which is easier to write?
Frank Barknecht _ ______footils.org__
Ultimately, I think Docbook would make the most sense, but writing SGML/XML is a lot more work than HTML. I think HTML will be the de facto format anyway, and that's a good thing.
But yes, definitely no binary formats.
.hc
On Mon, 28 Apr 2003, Frank Barknecht wrote:
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
It would be really great if we could combine all of the existing tutorials out there into one coherent, navigatible set of tutorials. Just like PDDP is becoming the central repository for docs, and the CVS is the central repository 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.
I'd second putting a "doc" section to the CVS (although I've come to hate Sourceforge's bad reliability in regard to cvs-access, grrr)
I think, at first we should not force a certain format of the tutorials on the authors. In the end, I think, HTML is not a good storage format. Something like Python's reStructuredText [http://docutils.sourceforge.net/] or a sgml/xml format [http://www.oasis-open.org/docbook/xml/4.1.2/] will be easier to convert to different output formats, like doing a printed book and such.
But discussing formats will only keep us away from doing the needed writing work, so I propose to allow any kind of format except binary document formats. To clarify: No MS-Word documents!
ciao
Frank Barknecht _ ______footils.org__
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
On Mon, 28 Apr 2003, Frank Barknecht wrote:
Recently I came to like reStructuredText, which also can be exported in a lot of formats, and has the advantage, that the "markup" is nearly invisible, too, because it follows the conventions of email-markup. A typical reST document looks like this:
My first tutorial
Chapter 1: Starting Pd
I'd like to start with the *most important things* in italic letters. And so on...
... wow this is really cool :) Have to take a look at it ..
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Mon, 28 Apr 2003, Frank Barknecht wrote:
Recently I came to like reStructuredText, which also can be exported in a lot of formats, and has the advantage, that the "markup" is nearly invisible, too, because it follows the conventions of email-markup. A typical reST document looks like this:
My first tutorial
Chapter 1: Starting Pd
I'd like to start with the *most important things* in italic letters. And so on...
... wow this is really cool :) Have to take a look at it ..
I checked in what I have from my drum tutorial so far into doc/footils/pddrums. pddrums.txt is the reSt source, pddrums.html is the resulting html-page, using a default.css, that matches our sourceforge pages.
(a copy currently is at http://footils.org/tut/pddrums/pddrums.html rsp. http://footils.org/tut/pddrums/pddrums.txt)
Frank Barknecht _ ______footils.org__
On Mon, 28 Apr 2003, Frank Barknecht wrote:
Recently I came to like reStructuredText, which also can be exported in a lot of formats, and has the advantage, that the "markup" is nearly invisible, too, because it follows the conventions of email-markup. A typical reST document looks like this:
My first tutorial
Chapter 1: Starting Pd
I'd like to start with the *most important things* in italic letters. And so on...
reST seems quite nifty for quickly banging out simple documents, but how does it hold up when do thing more complex things? Yes, SGML/XML is a pain, but once you have your docs in that format, you can do just about anything with it in terms of formatting or even machine parsing.
I like that CSS by the way. I edited the pd docs in the CVS to use a CSS, so you can make them look the same.
.hc
zen
\
\
\[D[D[D[D
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
reST seems quite nifty for quickly banging out simple documents, but how does it hold up when do thing more complex things? Yes, SGML/XML is a pain, but once you have your docs in that format, you can do just about anything with it in terms of formatting or even machine parsing.
reST can be extended by writing directives as the ".. image::"-directive. But you're right, it is made for quick editing with minimal markup. In this regard, it is very similar to Wiki-Web markup. But apart from the html- and tex-generators there also is a generator for XML, so reST even can function as a source for that. In the end it's just a matter of taste. reST also is a good utility for converting existing text documents into html.
I like that CSS by the way. I edited the pd docs in the CVS to use a CSS, so you can make them look the same.
The default.css in the tutorial is just the standard reST-CSS attached at the end of the standard pure-data.sf.net-CSS. That's the nice thing about *Cascading* style sheets. ;)
Frank Barknecht _ ______footils.org__
Hi All,
Related to the current thread about PD tutorials - I'm involved in organising a series of seminars about patching software. The audience is likely to be a mixture from non-patchers through to experienced users of PD/ Max / jMax /Reaktor etc.
The conference in question is Electrofringe, a yearly electronic arts festival in Newcastle, Australia. www.electrofringe.org
Whilst I think that workshop/ tutorial style approaches definitely work best for learning PD or patching in general, we don't have the facilities or sufficient time to offer this.
Instead I'm curious whether people have had interesting and useful seminar or lecture style sessions with patching software.
If so - what was the content and approach?
We're hoping to run sessions which offer something to non-users, experienced users and the presenters... perhaps not at all in a single session obviously.
So far, and based on previous years' experience, we're looking at doing the following:
software options
video... exchange data, ideas and patches and where others may mingle, examine running patches, ask questions and so on.
more on what's possible than on patch implementation - surround sound - video - interconnection (OSC, net streaming etc)
Any ideas, experience greatly appreciated.
Thanks, Daniel
Hello,
If you have a significant amount of time with the group I might be inclined to:
Determine the disparate levels of skills and knowledge of each person.
Then, assuming that you'll likely have some who know very little, and
some who know considerably MORE, I would organize the conference into a series of workshops. TOPIC + workshop wherein you can oversee the work of each group, but each group also has one of the more advanced users. Have the group teach the group.
I would think it's more important to NOT leave the inexperienced users in the dust; rather than try to titillate the more experienced. If both can be achieved then great!
Hmmm... Inexperienced users want to learn a lot. Experienced users can learn through the process of teaching the inexperienced. Every teacher/professor will agree that the best way to learn something is to explain it to others.
Moving directly from the "patching paradigm" to a jam session is a really big leap for inexperienced users...although definitely an enjoyable activity which would prove the software's usability and effectively in live performance to everybody involved.
Good luck...and if this festival ever comes to Canada, please keep me in mind!
Regards, Dave S
-----Original Message----- From: pd-list-admin@iem.kug.ac.at [mailto:pd-list-admin@iem.kug.ac.at] On Behalf Of Daniel Heckenberg Sent: April 29, 2003 9:15 PM To: PD-list@iem.kug.ac.at Subject: [PD] [OT] successful methods for PD seminars
Hi All,
Related to the current thread about PD tutorials - I'm involved in organising a series of seminars about patching software. The audience is likely to be a mixture from non-patchers through to experienced users of PD/ Max / jMax /Reaktor etc.
The conference in question is Electrofringe, a yearly electronic arts festival in Newcastle, Australia. www.electrofringe.org
Whilst I think that workshop/ tutorial style approaches definitely work best for learning PD or patching in general, we don't have the facilities or sufficient time to offer this.
Instead I'm curious whether people have had interesting and useful seminar or lecture style sessions with patching software.
If so - what was the content and approach?
We're hoping to run sessions which offer something to non-users, experienced users and the presenters... perhaps not at all in a single session obviously.
So far, and based on previous years' experience, we're looking at doing the following:
software options
video... exchange data, ideas and patches and where others may mingle, examine running patches, ask questions and so on.
more on what's possible than on patch implementation - surround sound - video - interconnection (OSC, net streaming etc)
Any ideas, experience greatly appreciated.
Thanks, Daniel
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi Dave, List,
----- Original Message ----- From: "David Sabine" dave@davesabine.com
If you have a significant amount of time with the group I might be
inclined
to:
Determine the disparate levels of skills and knowledge of each person.
Then, assuming that you'll likely have some who know very little, and
some who know considerably MORE, I would organize the conference into a series of workshops. TOPIC + workshop wherein you can oversee the work of each group, but each group also has one of the more advanced users. Have the group teach the group.
The problem here is that the sessions will be spread over a few days - only be 2 hours long each and will be lecture style - a computer, a projector and some mics. This is the nature of the festival and we don't really have the resources to do otherwise.
Definitely not optimal... as you point out. So we're trying to work out the best way of working in the format that we're limited to.
Thanks for your ideas. Daniel
does anybody know of any Pd seminars or user-groups in california?
preferably northern CA?
Scott
On Thu, 1 May 2003, Daniel Heckenberg wrote:
Hi Dave, List,
----- Original Message ----- From: "David Sabine" dave@davesabine.com
If you have a significant amount of time with the group I might be
inclined
to:
Determine the disparate levels of skills and knowledge of each person.
Then, assuming that you'll likely have some who know very little, and
some who know considerably MORE, I would organize the conference into a series of workshops. TOPIC + workshop wherein you can oversee the work of each group, but each group also has one of the more advanced users. Have the group teach the group.
The problem here is that the sessions will be spread over a few days - only be 2 hours long each and will be lecture style - a computer, a projector and some mics. This is the nature of the festival and we don't really have the resources to do otherwise.
Definitely not optimal... as you point out. So we're trying to work out the best way of working in the format that we're limited to.
Thanks for your ideas. Daniel
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
"640K ought to be enough for anybody." -- Bill Gates, 1981
Hi,
Former Novocastrian and past Electrofringe attendee here:
I was taught max last year, and in a short space of time over at the Uni of Sydney. The group that was taught were all pretty much novices, and were all pretty confused about what to do with this knowledge. The approach was pretty much to talk us through setting up a very simple patch and then show us pre-baked large scale patches and explain the critical concepts behind them. This managed to cover getting midi into Max and getting audio out, and a couple of other things about messages moving through the patch and subpatching etc.
The main good things that the lecturer did was to explain the important iput and output things fairly transparently and quickly. The main thing he could've done better is show how easy it is to build up a bigger patch from smaller building blocks. We were presented with enormous patches that did wonderful things as demonstrations, but we learnt how to do very simple things with patches we built painstakingly slowly as we learnt concept by concept. Time constraints (3hrs) were the main reason for this of course, but I think a good PD tutorial would hopefully finish with the students feeling that they could easily build something big if they had an idea for a patch. It would've been a bit more effective if the two concepts (small simple patch, big complicated patch) had been related effectively...
I do think that fiddling about and asking questions is the only good way to get an understanding of the program, because there really is a lot of ideas that aren't immediately obvious from the user interface and a lot of the ideas are fairly abstract at first. I also think the debugging process is one of the best ways of learning the inner workings of the program. But it can also be the most painful if you don't know how to go about debugging properly and can lead to getting stuck and giving up.
Anyways October hey, I'll make sure I'm there again this year....
Sam
----- Original Message ----- From: "Daniel Heckenberg" daniel@bogusfront.org To: PD-list@iem.kug.ac.at Sent: Wednesday, April 30, 2003 1:15 PM Subject: [PD] [OT] successful methods for PD seminars
Hi All,
Related to the current thread about PD tutorials - I'm involved in organising a series of seminars about patching software. The audience is likely to be a mixture from non-patchers through to experienced users of
PD/
Max / jMax /Reaktor etc.
The conference in question is Electrofringe, a yearly electronic arts festival in Newcastle, Australia. www.electrofringe.org
Whilst I think that workshop/ tutorial style approaches definitely work
best
for learning PD or patching in general, we don't have the facilities or sufficient time to offer this.
Instead I'm curious whether people have had interesting and useful seminar or lecture style sessions with patching software.
If so - what was the content and approach?
We're hoping to run sessions which offer something to non-users,
experienced
users and the presenters... perhaps not at all in a single session obviously.
So far, and based on previous years' experience, we're looking at doing
the
following:
- An intro session to explain the patching paradigm and give a quick tour
of
software options
- A laptop gig/jam where patchers can turn up, plug in and produce audio
and
video... exchange data, ideas and patches and where others may mingle, examine running patches, ask questions and so on.
- Various special purpose sessions exploring particular topics - focusing
more on what's possible than on patch implementation - surround sound - video - interconnection (OSC, net streaming etc)
Any ideas, experience greatly appreciated.
Thanks, Daniel
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list