Hi there,

I started dealing with GEM and implemented a very simple patch that simply plays back a video. When I run this patch with pd-gem the playback is all good. But with purr-data the playback stutters since the CPU load is too high. Please find attached screenshots of the patch and atop while running the patch with purr-data and pd-gem.

The pd version with purr-data and pd-gem is slightly different, but I assume that this is not the root cause. So, what is the problem with purr-data and how can I solve it?

Thank you in advance!
Andre

-- purr-data --
Purr-Data 2.19.3
Pd version 0.48.0
GEM version 0.94

-- pd-gem --
Pd version 0.52.1
GEM version 0.94

The use case is a granular synth similar to these ones:

Respectively, there is only one sample, but played simultaneously at different positions and with different speed etc. At the moment I'm using multiple sampler instances each with its own array and read by its own tabread4~ object. The granular synth abstraction is used in several patches and I'd like to declare a subfolder for the sample used in the cloned sampler instances in order keep everything structured and clean. But yes, a great idea to use only one array and pass it to all sampler instances! I'll definitively try it out. Thank you!

Yes, adding [declare -path Subfolder] to clonedobject.pd works. Unfortunately, this violates the flexibility of an abstraction since the same directory must be used for one particular abstraction in every patch. But at least this would be helpful to keep the root directory clean.

Hi there,

it seems that a file path declared with the declare object is not forwarded to cloned object. I created a minimal example, see attached "main.pd" and "clonedobject.pd". The folder "Subfolder" is located in the root directory. It is declared, but test.wav is not found if it is located there. Any ideas for a workaround? I'm using Purr-Data 2.19.3.

Thank you in advance!
main.pd
clonedobject.pd

Thanks for your post!

Okay, test2 works if I replace the direct feedback path with send~ and receive~ objects. I understood that test2 fails since there is a signal path from the output to the input of the same object, which is delayline~, Whereas with test1 the feedback path is connected from delread~ to delwrite~, i.e. there is no object with a path from its output to its input.

test1 realizes a simple delay effect. test2 is identical, but the delay buffer is encapsulated in delayline~. test1 works fine, but with test2 a DSP loop is detected. I'm wondering why. Is it a bug or is it defined behavior? I'm using Purr Data 2.19.3 (Pd-0.48.0) and also tested it with Pure Data 0.52.1.

Thank you in advance!
André

test1.pd test2.pd delayline~.pd