Perhaps. But I was definitely able to
manually bump the priority without sudo.
I don't doubt that you can manually bump the priority; that
doesn't necessarily mean that Pd itself can do it.
BTW, if Pd fails to raise the thread priority to RT, you should
get the following error message in the Pd console:
"priority %d scheduling failed; running at
normal priority"
I don't recall seeing that on the console, but I may have seen it on stdout once or twice.
1 - the PD UI will absolutely kill
performance
The Pd GUI runs as a separate process with lower priority. If you
mean the actual network I/O for core <-> GUI communication,
then I don't see how running Pd in callback mode would improve
this - on the contrary!
This has nothing to do with callback mode, as such. it is a general performance note included to illustrate the various things that I discovered, often with much debugging of PD itself, which affect performance.
2 - because of 1, plan to run the sound
gen in [pd~]
In general, it doesn't really make sense to run *all* DSP in
[pd~]; instead, just use the standard polling mode and raise
"delay" accordingly.
This is a very disappointing answer. I really keep hoping to get away from static composition and move towards live performance, and yet you tell me that the main remedy is to increase lag? Is PD really just CSound with a better sound design workflow?
It may very well be an issue with your computer/OS. Did
you try other machines?
As I said earlier, it was quite an old laptop, and the composition had a lot of physically modelled voices. My Win laptop was unilaterally upgraded to Win11 by u$oft and ceased to perform well at anything other than playing video, so I kind of left it behind. The list I provided gave me nice clean sound. The most effective single change was the change to [pd~]. I will freely grant the possibility that the re-architecture of my program necessary to run in that environment may have improved performance, but that still points to UI (and the attendant clunky communication) issues as being a primary performance problem. Running the audio DSP in an execution context separate from UI messaging seems to me to be a crucial performance improvement for PD. My experience with [pd~] certainly shows that. I would hope that a separately threaded DSP engine would do the same.