Multithreading suggestions
I would like to improve the performance of a patch by making better use of parallel processing. The main culprit in this case is most certainly jit.desktop, so I'm thinking about isolating it in a specific thread from the rest of the patch (logic, UI, OpenGL rendering...).
I know that in Max 6 each top level patch window gets its own thread but, if possible, I'd prefer for the application to be in just one patch file.
I was thinking about using poly~ (with just 1 voice) as an alternative. I just read in the poly~ documentation that "parallel processing enables the use of multiple threads to run audio processing for all patcher instances. If it is disabled poly~ runs all patcher instances in the audio processing thread". I've used poly~ before with jitter, but does this mean that poly~'s multithreading implementation is only useful for audio?
If so, are there other suggestions? On a side note, I'd love for the [patcher] and [bpatcher] objects to have a simple checkbox on the inspector: "separate thread" or something like it. This way, everything inside it would get its own thread, like a top level patch! Would it be technologically feasible? It would certainly be practical...
Thanks.
Poly only multithreads audio.
My strategy is to split up my system's heavy components in multiple standalone apps and have them communicate via UDP, jit.net.x, syphon and soundflower.
separate max patchers should be enough to get multithreading
Yes splitting up in standalones is an old habit of mine...
Thanks for your responses, vichug and dtr.
I guess I could loadbang a message with ;max openfile 2nd_patch 2nd_patch.maxpat to automatically open the 2nd patch. This way there would be 2 top level patches and I could communicate between the two with regular send/receive pairs.
Can I automatically build an application with this method or do I have to somehow manually include the file of the 2nd patch? I don't want to have to build 2 separate applications...
Thanks.
if you make a max project containing everything you need, then build your app from there, everything should be done easily for you :)
btw when i said 'should be enough', i actually meant that i wasn't sure if it was working for non audio things... now this quote seems to confirm that several toplevel patchers allow for parallel processing of everything : https://cycling74.com/forums/feature-request-expanding-the-scope-of-parallel-processing
Vichug, thanks for the very informative link. I've searched the forums before but didn't come across that topic. Let's hope that this subject improves in the future.