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

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

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

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

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

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

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

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

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

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

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:

1. Determine the disparate levels of skills and knowledge of each person.

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

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

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