@jancsika With only one osc the dsp drops out directly, It doesn't matter how many osc objects are present, the update of the graphical array freezes the dsp everytime it resizes independently of the number of audio sources and active objects.

Sndfiler crashes my pure data in every situation I've tried, so I can't use it.

I think the solution has to be solved by it's core, maybe in future versions the engine can treat threads better and separate more operations like resizing arrays from the dsp threads, but since I'm not a developer I don't know about this.

Sorry, I'm having trouble making sense of what you've written:

Sndfiler crashes my pure data in every situation I've tried, so I can't use it.

then this:

If I put the array in another patch and I don't open the graphics of it, the [resize( message doesn't affect to the dsp performance, so now I can record arrays and resize them at the same time whatever the duration of the recording is.

Which is true?

@EsGeh: I just finished to multithread my fork ; beta-testers are welcomed!

< https://forum.pdpatchrepo.info/topic/11738/spaghettis-yet-another-fork-of-pure-data >

@Nicolas-Danet Hey Nicolas, that's very cool! I will test my patches with your fork for sure, let's see how it handles my array craziness...

@jancsika said:

Sorry, I'm having trouble making sense of what you've written:

Sndfiler crashes my pure data in every situation I've tried, so I can't use it.

then this:

If I put the array in another patch and I don't open the graphics of it, the [resize( message doesn't affect to the dsp performance, so now I can record arrays and resize them at the same time whatever the duration of the recording is.

Which is true?

Both are true. If I use sndfiler the patch crashes directly. Then, without using sndfiler, if I put the array in another patch or embedded window outside the main patch, it seems to help with the dsp performance, not perfect but much better. I supose that opening a new pd window helps a little with multithreading.