@Spacechild1 posted yesterday about the new message [;pd fast-forward( that allows batch processing within interactive mode.
Here is a help-file that shows my understanding (probably wrong) of this extremely useful new tool.
pd_batch-help.pd
Maybe this post should be in "News" because that is what it is.
Pd 0.51.1 (onwards.....?)
David.

@whale-av So I should reread the entire manual on each release? I suppose I could run diff on the old and new manual on each release, but then I also need to copy the old manual to a safe location so it does not get overwritten on the new install. I really wish they would start a new changelog.

Edit; no need to diff the manual, can just check the doc folder on github and see if any have been updated. That is not so bad and I can live with it. And x5 is the release notes, I guess I forgot that.

I don't think this would work as a busy wait, I triggered a [metro 100] incrementing a counter into a print to the start bang in your help file, it printed out 0 to 200 immediately and then waited until the fast-forward was finished and resumed counting at 200 ever 100ms. But I also do not understand the busy wait.

Edit: if the metro is started by the bang that sends [fast-forward 0( instead of the one that starts the process, it does seem to busy wait as I understand it, the counter does 0 and then nothing until it is finished and resumes at 1 counting at 100ms intervals. All I did in the previous test was fast forward the counter

@oid So it does suspend real-time in the sense that the clock no longer runs the patch thread until the fast-forward message has been deterministically completed, although real-time is used when DSP is off to un-suspend the patch when the "fast-forward" is finished.
I think that probably maybe fulfills the busy wait requirement..... but only @jameslo will know.
David.

@whale-av said:

Asking because I didn't really understand for what purpose "busy wait" was requested, or even what purpose it could serve.

Oh man, in no way should my question about busy wait be interpreted as a "request" for a feature! I was just remarking on a language difficulty that wasn't obvious to me based on my flawed understanding of Pd. As a programming pattern, I could believe that busy wait is just an inappropriate application of coding instincts borrowed from lazy/beginner Arduino programming. That said, I want to look into this when I have time because it looks interesting.

@oid

How exactly is one supposed to keep up to date on new features?

Read the release notes: http://msp.ucsd.edu/Pd_documentation/x5.htm#s1

The changelog is 12 years out of date.

Good catch. This needs to be fixed. Also, the change log should reside in the toplevel directory and not buried in the "src" folder. I'll make a PR on GitHub.

Usually, features can be discovered by browsing the help files. The problem in this case is that there's no real help file for "pd" messages. This needs to be done.

Anyway, "fast-forward" is a very useful feature. Before I've made an external called [batchrecord~] which achieved the same thing. I don't know if Miller became aware of it, or if it was just a coincidence. Either way, I think it's great that it's now part of Pd vanilla!

Christof

Generally: if you encounter issues with Pd, don't just complain on the forum (which only few Pd devs read), but rather file an issue on GitHub!

@Spacechild1 Yeah, I had completely forgotten that x5 was the release notes, been far too long since I actually read the manual. As for reporting issues, I just could not see how a changelog could be forgotten for 12 years and assumed it was on purpose, all my other issues turn out to be issues with me or already known issues like the GUI getting slow when many GUI objects are about. Only issue I have found that I believe is unreported is that under certain situations pd might put in multiple identical #connect messages, as shown here https://forum.pdpatchrepo.info/topic/12507/bang-issues/4 but I have not been able to reproduce it or even figure out if pd was actually the cause so it seems premature to report it. Perhaps not?

@oid Pretty sure the multiple connect messages were on purpose by @oid.
It was a joke thread from beginning to end.
OH>>>> last post was from @oid....... I thought it was Spacechild1....... now I am very confused.
David.

@whale-av Nothing but confusion has resulted from this. The patch from my great confusion filled thread on 3d arrays was the source of the bang patch and that was the bug I mentioned in the array thread, I had greatly reworked that massive patch around those multiple connects without knowing it. I just linked that to show that the multiple connects actually do have an effect in case it was not obvious. I am not good at being obvious if you had not noticed

@oid It's a good one.
I wonder if it resulted from one of the newish keyboard shortcuts for drawing cords between selected objects?