Hello community!

My main question is: how to deal with the i/o-errors, pd chronically suffers from?
I get them on many occasions:

• resizing a table
• sending and processing (routing, splitting into packages) messages/lists of mediocre length
• sending/receiving messages from many objects
• updating gui elements

It's a pain in the ass! processing long messages is a quite basic feature for realtime audio.
Of course the I/O-Error comes with an audio click, which is inacceptable in a live situation.
(I am using pd with jack. There is no xrun in jack, by the way)
Fun fact: pd also prints the I/O-Error message if audio processing is switched of.

My impression is, the problem lies in pd's basic design:
Messages and audio processing is being handled in the same single main loop.
So if message processing takes a little longer, audio gets out of sync.
(Of course this can happen easily on message bursts, e.g. if you want to synchroniously control many objects.)
Can anyone confirm this?

What are the common practices to deal with this flaw on the USER SIDE?
Somewhere I read that I should keep audio processing and gui/message processing in seperate patches/pd instances.
However, this is only possible to some degree.
However, how could this be achieved? How can I force the gui patch to use a seperate thread? do I have to run it in a seperate pd instance?

From the PROGRAMMERS ANGLE: are there any efforts to improve pd's design? (e.g. calculate messages and audio processing concurrently, e.g. in sperate threads). Since this flaw has annoyed me since I have started to use pd, and since I have some experience with programming, I would like to offer my help to fix it!
Has this problem been solved in any of pds "forks" yet?
I love pd, but it still has profound issues, in my humble opinion.

@JackPD Here's a zip with sndfiler and a working threadlib, with help patches for each...sndfiler.zip

You're going to have to do the following:

1. Put that "threadlib.dll" in Program Files\Purr Data\bin (or Program Files (x86)\Purr Data\bin if you're on an amd_64 machine). Windows will ask you for admin privileges.
2. Unzip the folder somewhere.
3. Open sndfiler-help.pd in Purr Data.
4. Test out the object there, or save other test patches to the same folder where sndfiler.dll is located.

You can also set your path/lib preferences accordingly, use declare, etc. But the method I outlined above should be the most straightforward.

And now I can confirm-- [resize(---[soundfiler] will indeed crash Purr Data! Make sure you always provide the array name and new size as arguments for that message. However, I can also confirm that [resize array1 440(---[sndfiler] will indeed resize array1 to the correct size. So you should be able to at least test it out.

@jancsika Thanks for building the sndfiler library, I had no idea on how to do it... Anyways, as you have said, it crashes pure data instantly, not only that, it also crashes ASIO in windows, forcing a restart to make the soundcard work again.

Confirming that sndfiler crashes pure data like crazy and doesn't work in any possible way. I discovered something interesting. 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. It's a huge improvement to my application, Another thing that I would like to do is to actually see the waveform of the recorded array, but having opened the array graphic interrupts the dsp a lot..., But at least the audio functionality is working, so I'm ok for the moment...

It will be interesting to see how large your patch can get before rebuilding the dsp graph (which happens after "resize") starts to cause dropouts...

@jancsika said:

It will be interesting to see how large your patch can get before rebuilding the dsp graph (which happens after "resize") starts to cause dropouts...

It doesn´t get too big, a few seconds from size 0 an it already starts to cause drops on the DSP, I made a little recording of it (samplerate 48000 and updates the array every second):
https://s1.webmshare.com/mYq7e.webm

If I hide the graph, I can record forever and the dsp runs perfect from start to finish. It has to do with the graphical update of the array, which I think is very hard to hold along the dsp the way pure data is made. I love pure data for its simplicity and ease of use, but it doesn´t deal with threading very well, we´ll see if this is solved in the future...

@JackPD said:

If I hide the graph, I can record forever and the dsp runs perfect from start to finish.

What I'm asking is this-- how many signal objects can you add to your patch before you start getting dropouts on every single resize of your array?

You can test it like this:

1. add an [osc~] somewhere in your patch or on a subpatch. Then send your resize messages to [sndfiler] and see if you get a dropout.
2. If no dropouts happen, duplicate the [osc~] so that you have two of them. Then send your resize messages to [sndfiler] and see if you get a dropout.
3. If no dropouts happen, select the two [osc~] objects and duplicate those so you have four of them. Then send your resize messages to [sndfiler] and see if you get a dropout.
4. If no dropouts happen, select the four [osc~] objects and duplicate those so you have eight of them Then send your resize messages to [sndfiler] and see if you get a dropout.

etc.

Keep selecting and duplicating these [osc~] objects until you begin to get dropouts when sending the resize message to [sndfiler]. Then tell me how many [osc~] objects you have in your patch.

@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.