- using Jack in RT mode
- increasing buffer size
- using dual-core computer
- using "renice" on the pd process
this suggestions won't solve the mentioned problems for sure (besides increasing the buffer to a huge amount). since the problems arise withing pd itself, you cannot solve them by giving pd the highest priority. these suggestions do help, when switching workspaces cause drop outs for example or when any other software is disturbing the processing of pd.
but in pd, the audio and the gui are in separate processes:
$ ps -A f 6358 pts/0 Ss 0:00 _ bash 6368 pts/0 S+ 0:00 | _ pd -alsa -alsamidi 6369 pts/0 S+ 0:00 | _ sh -c TCL_LIBRARY="/home/ssteve/.local/li 6370 pts/0 Sl+ 0:00 | _ /home/ssteve/.local/lib/pd/bin/pd-gui
using renice on the audio process or running it in RT mode should indeed make a difference. (i'm talking specifically about Linux, but it should apply to other OS's as well.)
you could even try running the audio and gui processes on different computers.
for a performance environment, you could just discard the GUI and control everything through OSC remotely.
the problem is, that pd does *everything* in zero logical time, that is why reading/files can lead to dropouts: it is just not possible to read a 30MB file in no time.
I agree, I was only referring to the GUI-related problems. File reading could definitely benefit from being in a thread, I think this could be done in an external without too much difficulty. Though another idea is to load the file in chunks, so that only parts of it are loaded on each cycle, giving a chance for audio to run in between.
I'm not sure if readsf~ does this already.
Steve