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 Ok, looking at sndfiler. Let me see if I understand it correctly.

Take the following test patch:

[table foo 128]

[nbx]
|
[; A bang; B resize foo $1; C bang(

[receive B]
|
[sndfiler]
|
[bang]
|
[send SNDFILER_OUT]

[r A] [r SNDFILER_OUT]
|     |
[timer]
|
[print first]

[r C]
|
[print last]

Is it true that I would get output printed in the order "last" then "first"? If so then sndfiler breaks Pd's depth-first message passing rule.

Is it true that [timer] here will output different values depending on the size of the float provided to [nbx]? If so then [sndfiler] breaks Pd's deterministic scheduling rule.

Also, it appears a "resize" message with no arguments would crash Pd. That's a bit alarming given that I just happened upon it while scrolling through the source. Threading issues are extremely difficult to debug so I'm a bit cautious about exploring much further. (Also there's a threading wrapper library dependency by yet another author...)

Just for a thought-experiment: imagine a set of "delay" externals that try to do computation on a separate thread in the time allotted:

[resize foo 256(
|
[sndfiler 50]

In this case "50" would mean to delay output for 50 milliseconds from the time the object receives an input. So you send the resize message, sndfiler does the work in a separate thread, and after 50ms the object gets a callback to send output.

Now, if the thread has finished its work the output would be sent deterministically. If not the object would block until the thread has finished, send the output, then display an error to the console that it missed a deadline.

That's basically just mapping Pd's system scheduling to control objects. I think that would be a very clunky design that would be hard for users to maintain and reason about. But it's still preferable to breaking determinism as sndfiler apparently does.

Btw-- even after sndfiler finishes its threaded array resizing, it still must rebuild the dsp graph for the reasons I mentioned in my last message. So for patches with lots of signal objects you'd probably still generate dropouts.

Hm... here's an idea:

1. Require every class that deals with garrays to have a "set" method
2. Require the "set" method of these classes to bind the object to a symbol that concatenates the array name with something like "_setter". So [set foo(--[tabread] would bind that object to symbol "foo_setter"
3. When array "foo" gets resized, send a message "set foo" to "foo_setter"

Now every table-related object that uses array "foo" will have an updated reference to the newly resized array before the next dsp tick. This is because when you send a message to a receiver symbol in Pd it will dispatch the message to every object that shares this name.

On the other hand, the "set" methods of table-related classes in Pd weren't designed to be realtime safe. For example, some resize values may trigger an runtime error condition that requires rebuilding the graph. I guess the algorithm above could call some kind of "slim-lined" version of "set" that does size-based checks but excludes things like array name lookups, etc. But that would require splitting out every single "set" into a set of two methods.

A combination of that and the delay-based sndfiler could get you array resizing without dropouts. But that's a very clunky interface which is difficult to debug for a lot of work upfront just to get it running.

@jancsika I see, so it's basically "cheating" the system.., I can't test the patches that you wrote because I don't have the sndfiler library, I can't find it and the original repository link is down, if you have the sndfiler.dll, could you upload it? I don't know how to build it from the src...

Thanks

@JackPD It doesn't actually ship with Purr Data. We aren't currently building any of the libraries that weren't originally getting built under Pd-extended.

But I can see later if that lib will build.

@jancsika This is what I have inside the folder externals of the source code. The folder is named tb tb.rar and the sndfiler is inside it. Honestly, I have no idea of how to build the external from those files.

Thanks for your help Jancsika

So the "threadlib" dependency of sndfiler has some core functions full of assembly code. Files are date 2005, meaning they contain no arm assembly and therefore won't compile on my Chromebook.

If I get a chance I'll try compiling it under windows using msys2.

@jancsika I already have threadlib installed and running in pure data, unlike sndfiler this one is still avalaible at http://grh.mur.at/software/threadlib.html

sndfiler is the one that I can't find or build. I will try to build it but I'm not really experienced in this topic.

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