thanks to both of you, i will look into nice as well since i am on linux. as a note to myself and anybody who might read this: as i mentioned i have some vstplugin~ in there, like trackspacer which consumes a lot of CPU. i just read the vstplugin~ help file and you have optional flags to run the plugins in individual subprocesses. i will try these and it should solve my issues for now. thank you all for the great info. i learned a lot by not reading the manual first

@whale-av I disagree, you should absolutely comment without seeing my patch. maybe i shouldn't ask these questions without posting my patch. but my patch is confusing with many layers and self-made modules, some of them dating years back. back to when i started with pd and thought it is not so important to keep everything clean and tidy. i am already on the slow side regarding latency. thank you for the help. i am curious, how did you find the problems with adobe updater? sounds like you have a plan when it comes to debugging?
it's a different topic but since you mentioned sound cards: have you experienced less drop-outs with a much better quality soundcard? in my mind this shouldn't be an issue with only virtual inputs and a modern interface, but i have no clue about that.

hey thank you so much for your insight. it is a tricky question indeed. the more i learn about computers the more i am loosing my mind. with each evolutional step in a patch i amount more variables on my path to failure. i hadn't considered that there even could be different ways of measuring CPU load. so thank you, that gives me some hope. do you know about any other way of multi-tasking the DSP thread? other than pd~ subprocesses? i am using vst and ladspa plugins in my patch. some, like the trackspacer plugin, are very expensive in terms of CPU. I am starting to find other options like florah lite. but still, do you know a way of encapsulating/delegating specific operations of a patch to individual tasks other than pd~? it seems (i have no proof at all) pd doesn't make good use of multiple cores.

hi,

i have a huge patch and noticed a big difference in cpu load shown by the load meter of the purr data window and the load shown by my system monitor. the system monitor shows around 4 % and four subprocesses (that are part of my patch with four pd~) at 4% each.
if i check the included load meter of purr datas main process i get up to 50 % though. i do get audio dropouts when i run it. everything should check out.
do NOT visible gui elements that are parts of subpatches have an effect on load even when you can't see them? is there a limit to what the program can handle regardless of the cpu? what could be the reason for the difference in numbers?