I'll check vb-audio.com but I think I will give a try to puredata aoo (audio over osc) external .

I'm not sure what your setup is, but at the moment Aoo only allows to interconnect Pd and Supercollider instances (over local networks or the public internet). You would still need something like Jack or vb cable to connect Pd and VCV locally, right? Or are some people using only Pd and some only VCV?

You can use the Jack ASIO driver.

Like iemlib's [iem_receive] or iemgut's [oreceive] ?

Note the following caveat with settable receives: https://github.com/pure-data/pure-data/pull/604#issuecomment-487890771

TL;DR: settable receives work fine most of time, but under specific circumstances they can crash Pd. Use with care.

I know that using send~ and receive~ introduce latency

Not necessarily. You can in fact force the receive~ to be scheduled after the send~, in which case there is no latency, just like with delwrite~ and delread~.

and am wondering whether using subpatches via inlet~ and outlet~ also introduce latency.

No, unless the inner patch has a bigger blocksize than the outer patch. In that case, the latency is the difference between the two block sizes.

Does send (without tilde) introduce any latency?

"latency" doesn't exist in the message domain. When you send a message to [send], it is delivered instantly to all receivers. There is no semantic difference between using [send] or patch cords.

Does using subpatches rather than one big page introduce latency?

No.

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!

@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

Finally, Pd 0.51-1 now has a fast-forward message, which allows batch processing while in interactive mode.

It works similar to my [batchrecord] external.

-batch means "run Pd as fast as possible". This is similar to NRT mode in SuperCollider.

-nrt means "run Pd without realtime priority". Usually, you would only use that for debugging (especially on Linux, to disable the watchdog). Otherwise, it has only downsides (e.g. higher risk of audio dropouts).

So -batch and -nrt are really not related.

The whole situation is complicated by the fact that many plugins have their own preset management, which is often only accessible via the plugin GUI.

I would suggest to always use [preset_save( + [preset_load( instead, because it allows to load/save presets programmatically via Pd messages and it's the same for all plugins.

BTW, you can use [preset_list( to output all user presets for the given plugin. program_list only lists built-in factory presets