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-le...@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-le...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/
