@ddw_music Alright, until loop might work.

loop.zip

@ddw_music There is an external named [for++] in the iemlib library which takes arguments including a wait time and will increment or decrement by integer or float.
There is another with the same name and arguments in purepd.
They have inlets for all the parameters.
David.

There is an external named [for++] in the iemlib library which takes arguments including a wait time and will increment or decrement by integer or float.

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

Compare readability of [for++ 1 8 0 2] to [for++ start 1, end 8, step 2]

Someone can still do that. But there are already named flag args in [sigmund~] and other classes that would be inconsistent with that. (Not to mention the Max @key value syntax.)

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