On Thu, 24 Aug 2023 at 14:12, Christof Ressi info@christofressi.com wrote:
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.