[PD-dev] why must one never send a message from a perform routine ?

[Day Rush]

On Thu, 24 Aug 2023 at 14:12, Christof Ressi <info at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230824/51a64e23/attachment-0001.htm>