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:


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/KXKGQC63R7AUB5CKEJHBWQLCUFHENTLK/
>
> 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/5D3Q2AYZ6YOHFNGBQLQ3W6T2PN3FF437/

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/BVUCVEVWRPQYTLIPBB4E27BQHHIPGUKA/

To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/