[PD] isn't the GUI supposed to have lower priority than process?

Phil Stone pkstone at ucdavis.edu
Tue Jun 5 16:41:05 CEST 2007


Roman Haefeli wrote:
> On Mon, 2007-06-04 at 22:04 +0200, Matteo Sisti Sette wrote:
>   
>> Hi,
>>
>> I always thought that in PD, "process" (i.e. dsp and control processing) had 
>> the priority over GUI rendering, in such a way that drawing the gui would 
>> NEVER cause audio clicks although this means there's no warranty about how 
>> much gui rendering may be delayed.
>>     
>> Do you know of any workarounds?
>> Do you know if this is Windows-specific?
>>     
>
> no, i don't know of any workarounds.
> no, this is not windows specific. 
>
> there are other issues as well, which cause drop outs, that might be
> avoidable:
>
> - reading/saving files to/from disk

Yes, this one gets me very often.   To be clear, I'm not referring to 
loading *sound* files.  Just regular reads of non-sound files will cause 
dropouts.  For live performance, it is necessary to pre-load everything 
to avoid this, which is very inconvenient and not conducive to spontaneity.

I'm wondering if the threaded [sndfiler] object could be adapted to help 
with this particular problem.  Apparently, it doesn't work so well for 
soundfiles (please correct me if I'm wrong), because the dsp tree needs 
to be rebuilt anyway, causing dropouts.  However, could it work as a way 
of loading normal files without glitching the audio output?


Phil Stone








More information about the Pd-list mailing list