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