I have read a few threads (heh) on Multithreading, and admittedly, it goes beyond my understanding. I have a few questions regarding processing optimization for my specific situation. I apologize in advance if I frustrate any developers with my ignorance (or if I missed the answer in another thread), but here it goes:
I understand that the benefits of multithreading become less important when there are dependencies. Do these same dependencies exist when layering a large amount of plugins simultaneously (as in seperate, individual, chains)?
Would opening more instances allow GP to spread across cores and improve efficiency? Lets say I wanted to play a 32 string ensemble on a 10 core computer. Would spreading the ensemble across 10 instances maximize efficiency?
Would it be better altogether to dump ensemble duties to a static, channel-based application? (Like Reaper, or Blue Cat Patchworks)
Thanks in advance for your patience and guidance! Vive la GP!
For general info on multithreading, here are some that I found interesting:
From everything I have read about this - what works best depends on the specific task you are asking your audio workstation to do. Some tasks can benefit from multiple cores, other tasks are just brute processing speed, and some tasks have just plain vast requirements for both. The balance you need for your audio application depends to a large degree on your application, your understanding of the choices and tradeoffs to be made, and your pocketbook. And if one workstation wonât do it all, there are very specific vendor designs for dedicated networked workstations and specialty sub-servers. And, like a lot of technology things, times change, and the thinking/what is possible changes when new solutions become available.
In the replies I have put on here I try to choose something that is as current as possible, so I hope you might find the explanation linked below interesting. Note - I have no connection with Opus 101 Pro Audio and no knowledge of their products merits or demerits, but their explanation WRT audio processing is in line with many other vendors that I have seen and, as they note, the fundamentals apply to whatever silicone fits your fancy (e.g. Apple, Intel, AMD, etc). In my particular case, single core/single thread power and tons of the fastest RAM available rules the day and buries several other workstations I have that are multithread beasts but not that great on per thread/per core processing. It all come down to what you need for your specific requirements.
I suspect the answer to this is very situation dependent. Likely to depend not only on your instruments, interface, and how you trigger them, but probably also on your PC and what else is running on it.
The nice thing is that you could try out all three of those options without spending money. PatchWorks and Reaper are both free to try forever. (PatchWorks does limit your number of instances, and gives you audio silences in demo mode every now and then.)
My guess is that PatchWorks will be the easiest to use, since you can do it all within one instance of GP and not have to worry about routing audio and midi between apps or instances. Unless itâs coded badly it should also have much lower overhead.
The new âparallel chains multicore proccessingâ in Blue Cat Patchwork seems amazing.
I had a simple sequential chain in GP for guitar fx, amp, cab, reverb that was using cpu intensive plugins (it sat around 50% in GPâs monitor). I put this into Patchwork and then added another two parallel chains with similar plugins.
Without the multicore processing, running the 3 parallel chains at the same time it was ~90% in GPâs monitor - total clicks/pops.
With multicore procecssing enabled, it was ~50% in GPâs monitor - no clicks/pops at all. The cpu % shown in Mac Activity Monitor did go up, but the audio seems really stable.
EDIT: Another use - in the global rackspace I had 3 plugins that were being processed in parallel: delay, reverb, and an instance of EZdrummer. Moving these into Patchwork saved me ~8% on the GP CPU monitor, which was the difference between occasional clicks/pops and none.
Do you ever get any crashing with Patchwork in GP? I had tried it in Reaper (before GP when I thought Reaper would do what I was aiming for) and it would randomly crash in that DAW
Very interesting! My plans for hardware are to buy a solid laptop, RME babyface, and utilize my existing 2012 Mac mini w/FF400 for added outputs/inputs. If I need any additional CPU power, Iâll add the cheapest M1 Mac miniâs I can find to its network. They have very good single thread power, and the minis motherboards are so tiny and heat efficient that I believe that I could fit as many as I need into my rack without having any heat problems.
Thank you for your information. I suspect youâre right. No amount of research will exempt me from serious experimentation. When Iâve acquired my hardware and found a solid solution, Iâll report back to this thread.
In addition to multicore processing, 2.5 introduced 8 inputs/outputs, as opposed to the 2 inputs/outputs with 2 side-chain inputs that was in 2.43. But Iâm not seeing anywhere that the additional 6 inputs/outputs in 2.5 are accessible inside the plugin. Do you have any insight?
If you select a plugin in a slot, click on the name, then select Audio I/O, you can select all of the audio inputs and outputs there, if you want specific routing.
Yep, just came in here to say that I just figured it out. You select manual inputs and outputs (1 or 2, not automatic) and then you can select the channels at that point.
This is a rabbit hole Iâm going to follow for a bit, thanks for the insight!
For six amps in parallel, was able to save about 10% of CPU (5950x), so Patchwork has a lot of promise.
A couple caveats so far:
If using scripts for particular plugins that are now in Patchwork, those parameter numbers are no longer exposed for use. Even the particular plugin Bypass is no longer able to be scripted.
If getting quick access to the Plugin Editor is important, well this adds one more click.
But for âstationaryâ plugins, at least for what Iâm doing, this is definitely a route worth pursuing for the time being. As stated before, 10% or more of CPU savings in GP could mean the difference between clean sound and crackles.
I wonder how common it is to have a patchbay plugin that shows a speed improvement in GP? Blue Cat isnât the only company that has something like this. Melda Productions has it with their MXXXCore plugin, I think their MSoundFactory runs the same way, Waves has a few, NI has equivalents in various areas. I suppose since these companies know their products the best they can make patchbays for their products that work better than their standalone plugins? Would they get the same performance boost if using a different manufactureâs plugin in their patchbay type plugin?
My question to the power users here: is it better - e.g. a âbest practiceâ - to use âpatchbayâ plugins from various vendors where possible to improve the efficiency of GP? Only if using plugins from the same vendor? In all cases?
I see. First plugin I tried mapped all the parameters, but second plugin I tried only did a handful. For now, will stick with the âstationaryâ plugins but have plenty of those for this use. Thanks for the tips
In general, GP is more efficient than any of those patchbay-type products if you can use multiple instances of GP instead. If you are limited to one instance, then you might get some extra mileage out of something like Patchwork (which I used to use extensively before I switched to multiple instances of GP). There are other use-cases where you can use the multicore processing in Patchwork to balance the load more, but those are really limited to specific multiple instances of high-CPU plugins. Most times youâd be better off just loading a separate instance of GP instead. The overhead on each instance of GP is quite low, with all the benefits GP has to offer.
That sounds contradictory. I have a simple setup and run only one instance of GP. So if a single instance is more efficient than a patchbay product there would be no gain to use one. Your second sentence has it both ways it seems if I read it correctly - first you say that you were using Patchwork (and that I might get some extra milage out of that), then you say you switched to multiple instances of GP which is more efficient than a patchbay product?
Thanks for your comment though. Since I have several patchbay type products Iâll set up some tests to see if there is a gain using them for my application - or not. Just a WAG, but I would suspect that they do work more efficiently if using plugins from the same vendor of the patchbay product - like MXXXCore from Melda with all Melda plugins.
As @David-san pointed out, I was referring to several instances of GP vs. one instance using a patchbay plugin. If you are only able to load one instance of GP, then youâd probably benefit from some sort of patchbay plugin that can balance CPU load on cores other that the one GP is running on.
Hereâs an article from BlueCat on its use of multicore processing, and when it is/isnât useful.
