Re: Clarification about [pd~]

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
>
> ---
> [email protected] - the Pure Data mailinglist
> https://lists.iem.at/hyperkitty/list/[email protected]/message/KXKGQC63R7AUB5CKEJHBWQLCUFHENTLK/
>
> To unsubscribe send an email to [email protected] mailing list
> UNSUBSCRIBE and account-management -> https://lists.iem.at/

---
[email protected] - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/5D3Q2AYZ6YOHFNGBQLQ3W6T2PN3FF437/

To unsubscribe send an email to [email protected] mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/