Hello!

I am going to be teaching a pure data workshop next month in April, and wanted to turn the output of my workshop into a free tutorial to offer as a tutorial/walkthrough. It would be posted in the repo, and hopefully shared elsewhere.

The workshop is for beginners learning to use Pd, and to give them many different ways they can generate and manipulate numbers. I often see workshops showing people objects like [osc~] and teaching them how to use a vslider to change pitch, but waiting until later to really encourage people to learn to think creatively about number creation and data flow.

My idea is to create a large Pd patch with sub patches acting as categorized areas for people to play and experiment with data flow, and dialogue within the subpatches as comment boxes with additional information provided by the lecturer.

My aim is to cover three different levels within the tutorial:

1. Simple objects such as moses, spigot, shuffle/random, pack/unpack, send/receive and the such. Mainly focused on direct mechanics and what ways these objects can be "broken" or generate stack overflows, improper order of operations, etc.
2. Turning these concepts into basic tools, and introducing logical operators.
3. Providing clear examples as to why these are handy for certain applications (e.g. using pack to send a list of floating point variables to act as a "preset")

I was wanting to ask openly what specific objects, forms of data manipulation, and handy tools you wish someone gave you starting out, and how to offer a variety of focuses in this workshop within a three hour time span. What things do you feel NEED to be there, versus could be supplemented later in one's development? What objects or forms of data flow seem more flexible and capable of multiple applications than one would assume with a basic understanding?

Once I get it all written up I can post, in case anyone wants to supplement their own teaching/give to a friend.

Sounds like a great project. Here are some initial thoughts:

1. Trigger is at the heart of data flow programming, but learning how to use it is always a stumbling block for beginners. I'm sure that every PD user has spent hours banging their head against the screen with a patch whose order of operations is incorrectly sequenced. It's not intuitive to think of an object working in time, or right to left; it's not intuitive what is meant by "logical time", nor that one outlet will always wait for the next, no matter what is attached to it. So I'd say that a good set of problems and exercises relating to the trigger are essential.

2. While I was learning PD, I wish that someone had taught me about CPU usage and efficiency. There are usually many ways of completing a task (in fact, probably an infinite number!) but some are much more CPU intensive than others. A great lesson here is the comparing the recursive [list-drip] object with the more intuitive iterative method of atomising a list (using until, f + 1 and list split). The list-drip object (which is completely non-intuitive and very difficult to understand) works exponentially faster than the other! Why does this happen and what patching techniques can we use to minimize CPU usage in simpler situations? I've developed a lot of my own techniques here, but I could have saved a lot of time and CPU if I had had a good teacher.

3. Similarly important to know is the need to save memory by minimizing the use of [float] and [list] objects, and the need to save PD processing time by minimizing GUI objects. Most beginners have float gatoms scattered all over the place, when they're usually unnecessary and definitely slow things down.

4. I'm sure that every new patcher finds themselves copying and pasting 64 versions of the same thing, only to learn about abstractions a few weeks later. So introducing sub-patching and abstractions at the right time is essential.

5. Perhaps it's just my style, but I find the [demux] object (or cyclone/gate] to be the most versatile and indispensable object).

6. Not for beginners, but I stick to the advice that I gave here.

Hello again Gummi...... good idea..... a few thoughts.

So your (first) workshop will be "data-flow"......
I tried a while ago to build a patch that might demonstrate "what is a dataflow language". When I first came across Pd it reminded me of a very brief lesson at school (long long ago) where I learnt (a little) about the data-flow diagram. But Pd is more sophisticated than that, and I had some trouble demonstrating the possibilities without just chaining a whole load of spigots together. I suppose I tried to make it too simple. I will be very interested to see your patch!

However, I think you should start with this.........a simple drawing.....in traditional "diamond" boxes.....
Is there a good film on?... yes/no
shall we go?.......yes/no
Is it raining?......yes/no
Do we have 2 umbrella?.........yes/no
etc.
There will be no need to resolve the chart..... but it gives a hint about how Pd works. That is the bit I forget every day....... that Pd also deals much of the time with logic...... 1 and 0..... true and false...

Because Pure Data is in fact a formidable system engineering platform........... that is used most of the time for audio and music.

And then I agree with @Liam about all of the points he made, but I think you will need to "whet their appetites" before you deal with "nitty gritty". They should be given http://puredata.info/docs/manuals/pd/x2.htm for absolutely compulsory homework

I think I would start with an osc control and not an [osc~] sound....... and show them how you can have a touch fader on a tablet sending osc messages that controls a gui in Pd via udp binary packets (maybe not too much detail there at first though?) over a wi-fi connection and then transform that data into some visuals and sounds so as to get them excited.......... because.......
....... if you can see the beginning and the end of the journey before you start it is much easier to understand all of the decisions that were taken on the "rocky road" in between.......
If Pd was a system for growing vegetables I would have said "and then show them some vegetables". I am a fan of the data-flow more than the vegetables..... sorry, more than the audio-visual...... even though I am an audio-visual engineer. Pd does all of the "stuff" that you cannot do elsewhere with audio-visual software.

Make sure as @Liam says that you have trigger and route and other important objects in the chain (unavoidable really), and go through the whole chain with "magic glass" showing them what is going on in the "string" (of course you will need a "slow metro" at the head of the chain for that). Don't bother showing them how you generate the sounds and visuals.... that will be too much for day one....... but explain how you got the "data" to "flow"..............
And then finish up with more of the bin ops and [expr] maybe to show the "power at your fingertips".........

I wish I had better understood list from day one (and float symbol anything pointer).
My favourite tools are the list tools..... split, drip etc. and I cannot live without [cxc_split] and especially [slist] !
David.