@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 It was news when 51-1 came out, now it is just another undocumented feature that most have no idea about, think that puts it squarely into the technical issues category. How exactly is one supposed to keep up to date on new features? I just browsed the mailing list some, the fast-forward message was not even mentioned in the 51-1 release announcement, it just starts getting talked about a few posts into the thread for the release announcement as "how do I use this new message?" with no prior mention of what this new message is or that there is even a new message (possibly off list message or broken thread handling in the archives?). The changelog is 12 years out of date. Is following the github commits and learning the code base the only way to really have a clue here?

Edit: Regarding my suggestion of broken thread handling on the mailing list archives, I suspect the mailing list software itself has issues here, gmail certainly can not keep threads from pdlist together.

@oid Looking for help/opinions.
There have been a few questions recently about implementing "busy wait" in Pd.
Could this be used for that when DSP is off, sending the message that should wait after a non zero [;pd fast-forward( message stating the required wait time?
Probably not because the effect would be the same as a delay I suppose.
Asking because I didn't really understand for what purpose "busy wait" was requested, or even what purpose it could serve.
David.
@oid..... it is mentioned in pd/doc/1.manual/x5.htm but without much help as you say.... and luckily nobody ever reads the doc or this forum would be much less successful.
It states that is runs full speed "without waiting for A/D/A or the real-time clock" but when DSP is off it does seem to wait for the real-time clock.

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