This seems as likely a subcategory as any...

I'd like to connect with teachers using Pure Data in the classroom.

• Where are the stumbling blocks that you see students crash into frequently?
  • (Anyone using Pd could chime in on that one... what are the things that confused you?)
• Are there any techniques/ideas/paradigms that helped the students to understand these difficulties more easily?

For a specific example: https://forum.pdpatchrepo.info/topic/13263/samphold-at-the-control-level -- "I want to get the number to update on the downbeat so it doesn't play anything while the number is being updated by some other process."

Extremely common scenario -- but I'll be danged if I can find anything in the help series that makes it clear.

This happens to be one of the sticking points for me -- which, lately, got me thinking about a paradigm of "feedforward" and "feedback" to cold inlets. It's (relatively) easy to understand chaining through hot inlets. Everything is immediate, and that's where the quoted question comes from -- if the only thing anyone taught you is how to chain immediate operations, then "save this datum for later" is scarcely even thinkable. (The quoted thread goes on to say "I'm having trouble explaining" -- meaning, whatever degree of exposure to Pd this user had, it wasn't enough to provide a vocabulary to talk about this problem.)

• "I have data now, but I don't want to use it until later" --> feed it forward to a storage object, then bang the storage object when you need it.
• "I want the next cycle of a loop to operate on the result of this cycle" --> feed it back to a storage object that's triggered by the loop.

This solves a bunch of problems. The quoted problem -- (data source) feeds forward to [f] right inlet. Or, initializing a counter at the beginning of the loop (feedforward). Or, building a list iteratively, but outputting only the final list (on each loop iteration, feed the list-in-progress forward to list storage, and bang the storage when the list is finished -- for this one in particular, I had struggled in the past with various bizarre usages of [spigot] but this is much easier).

One of the things I was missing over the last year and a half of getting up to speed in Pd is an established vocabulary of usage patterns. Sometimes I think Pd and Max pedagogy tries to stay away from typical computer-science problems -- but sooner or later, you're going to run into problems that have standard solutions. So why not collect them into a unified place? Like, in SC, for the fourth example below I can just write arrayOfMidiNotes.collect { |note| note.midicps } and uses of collect are all over the place in the help system... but in Pd, it took me literally over a year to figure out the best way to collect / map. That's... kinda crazy.

hjh

@jancsika Maybe like this.

for.zip

@ingox Yes, but with comma-separated arguents. I'll try to code it up to show what I mean.

@jancsika for++.zip

@ingox yeah, but what if you want to parse more then one variable? Here is an attempt, i think it's dirty but it works:
seperated-args.zip

@solipp Well, what i did was for the specific use case, not as a general solution. It works like shown in the help file...

@ingox right, it was about them for loops...
Although, getting lost in details is certainly a good paradigm for teaching/learning pd

It's too bad it took so long for Pd Vanilla to get simple, long-requested features like fetching abstraction args. If it had, someone could have designed a simple, standard abstraction to parse comma-delimited named args (and put a matching one in the public API).

So here's what I'm getting at-- when you start messing around with things like named args, you quickly start to see big productivity improvements that you can build into an interface if the environment gives you the tooling to quickly iterate over those improvements.

So [for++ 1 8 0 2] is an improvement over [until] in some ways, and [for++ start 1, end 8, step 2] is a more readable improvement on both.

But really, if we're setting up state to loop, and our system has automatic newlines on semicolons, why not just add the calculations directly in the body of the object?

[for++ start 1, end 8, step 2;
do some stuff;
more stuff here;
etc.]`

And if we're in the scope of a box, why not use a named arg to access the iterator variable when setting both the loop and the calculations?

[for++ i 1, i < 8, i + 2;
do some stuff with i here;
i * 2 * 3.14;
etc.]`

Here's an example called "dup":

dup.pd

dup-help.pd

Unfortunately, the tooling in Pd keeps this from being a more serious effort:

1. Very difficult to parse tokens in Pd. So I have to just depend on the user to remember to surround "i" with spaces, and I can't easily report an error in that case.
2. Even if I could report an error, that error can't prevent the object from successfully creating. But if the user typed in erroneous syntax, that's exactly what should happen.
3. There's just no sensible way to leverage functionality from other classes, like I'm doing with expr here. You have to dynamically instantiate full canvases of objects. That just doesn't scale and tends to be very difficult to debug.

Edit:

4. Iterating over lists of arbitrary atoms is extremely finicky in Pd. For just one example, [route] doesn't play well with lists-- you have to trim the list in order to route by the first element of the list, but the moment you do that you risk badly formed messages like "float boat etc." and "symbol 1 foo"

In terms of teaching paradigms for Pd, sticking to lists of float atoms makes the most sense. Students can leverage patterns of manipulating floats with impunity. While they can send around lists mixed with symbols and floats, manipulating these lists in any but trivial ways will quickly hit a wall with problems like these.

@jancsika From what i know you can install Ofelia and then you can use Lua scripts right inside a box. With this the for loop with do stuff and more stuff is possible.

@jancsika [dup] is just outputting bangs...

@ingox What if you do [dup 23; i]?

@jancsika This and the lower two examples in the help file do nothing at all...

Have you seen my [loop], [for] and [for++] abstractions? These together with [expr] or other objects can do everything with less complexity...

Oops, I had a $0 in a message box which just works in Purr Data.

Try this:

dup.pd

@jancsika Ok, now it works. Only [dup i 20, i < 45, i + 1] gives just bangs.

Have you seen my [loop], [for] and [for++] abstractions? These together with [expr] or other objects can do everything with less complexity...

My main purpose was-- can I use "i" to set a loop and reference "i" in the body of the object's arguments as a local variable? Even that turns out to be extremely difficult. And while I purposefully avoided using abstractions here, it wouldn't have changed much because the difficulty is in the core data structures available from the language.

You're right that just reading a single "$f1" in a separate expr isn't a big cost. But what about extending "i", with "j", or "amp" and "freq" and "dur"? In other languages people iterate over a design pattern to create everything up to (and sometimes beyond) a domain specific language. In Pd I can't easily add this seemingly simple convenience. The language just doesn't give me enough features to do it in a robust way. (And while I specifically avoided abstractions here, that wasn't the limiting factor.)

As far as teaching paradigms-- I think this means to stick to lists of floats even when teaching general principles like what OP covered above. If you're splitting or mapping lists of symbols or lists of symbols and floats, it's likely you'd be better off doing that business in another language and handing the results off to Pd.

As for Lua-- maybe that's the language to go to for handling these higher-level problems? The pdlua stuff looks great, but I wouldn't want to downplay the cost of adding another language to the mix, especially for newcomers.

Ok, now it works. Only [dup i 20, i < 45, i + 1] gives just bangs.

Hee hee. I actually designed it that way with [until] in mind. But yeah, it should probably just output "i" implicitly in that case.

@jancsika It is pretty cool!

Interesting progress on this thread! I'd dropped off -- will have to catch up.

Of scripting languages -- I'll get myself in hot water for saying this, but every really cool max or pd project I've seen involves some scripting objects somewhere. There are some things that are really hard to say with patch cords, that are very easy to say in imperative (or functional!) code -- and other things that are easy to say in patch cords that are harder in code (such as, my GUIs in SuperCollider usually have some model-view-controller glue underneath -- which is robust but you can't explain it in two sentences like you can explain a pd slider wired up to something).

Ofelia is quite nice for providing access to coding style logic with patches inlets and outlets.

hjh

@jancsika I made a version of [dup] with another coding approach. It should work mostly the same, supports counting for [dup 22] and also supports short styles like [dup 5 15 2] or [dup 2 = 10].

dup.pd

There is actually a trick: As long as the first line is not a single number, it will just assume the first number to be "from", the second number "to" and the third number "step", regardless of other symbols. It assumes "<" or ">" as default, only if it detects a "=" it will add another step.

@ingox Nice.

Once I added the semicolon-separated message args to hand off to expr, it didn't seem as pressing to allow expressions inside the conditions. At that point it just seemed easier to specify the loop length with a single floatarg and do whatever with "i" in the body.

I think this method of leveraging expr is probably useful for something like [array foreach]

[array foreach e, i;
e * 2;
i;

That is-- for each element of the list, output a list containing the current element multiplied by two, followed by the index.

But I guess you have to name the object something other than "array"...

@jancsika This works (has to have spaces around i ):