Hi all,
I've been out of the loop a bit, but maybe I'll get back to some projects soon. This is one of my interests as well: how to handle asynchronous processing of expensive things that are dangerous to real-time
The basic conclusion I have: start a 2nd fully independent pd process with -noaudio and read/write data with Cyrille's shmem tools. That 2nd process can also make use of the fast forward mode, as long as it returns to the regular scheduler when it needs to communicate synchronously.
shmem is *the* tool for writing control of asynchronous processes. One process, no matter what clock it's using, can poll a shmem location and get an instruction. I'll try to catch up and see what the list has been talking about, and if the topic has been visited lately.
Best, Chuck
On Fri, Mar 28, 2025, 5:18 AM Antoine Rousseau antoine@metalu.net wrote:
Btw this has already been discussed a few years ago, including the possibility of making an "asynchronous" pd~, which would be definitely useful:
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/thread/35ERXCVVPVE...
Antoine
Le ven. 28 mars 2025 à 10:19, Christof Ressi info@christofressi.com a écrit :
On 27.03.2025 16:39, IOhannes m zmoelnig wrote:
On 3/24/25 18:23, Pier Bar wrote:
You would typically use it for offloading audio processing to another CPU core, in particular if a single CPU cannot handle the full workload.
So it seems intended for audio rather than control signal operations...
i see how you come to this conclusion by christof's wording.
however, i wouldn't say that this is necessarily true.
Sorry for giving the wrong impression that [pd~] is only for audio processing. Of course, you can (also) do control operations!
the important fact to understand is, that the output of [pd~] is still fully deterministic (by keeping the operations *synchronous* with the parent Pd).
therefore, it is ill-suited for asynchronous offline processing (like training a neural network for 10 minutes at "full speed").
instead i would say that it is a good tool if you can formulate the problem like this: "I have a cool patch X that works great with the desired latency. I have another cool patch Y that also works nicely. But if I use them together, things start to fall apart." then you could run e.g. patch Y in a separate [pd~] instance.
That's actually a pretty good explanation. And that's exactly how I've been using [pd~] myself.
fgdam IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/KXKGQC63R7...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/5D3Q2AYZ6Y...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/BVUCVEVWRP...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/