There is some really great stuff in there, Colin. Fantastic resource!ColinP wrote: ↑Mon May 30, 2022 9:23 am Anyway one way to break through these problems is to modularize by using the plug-in host to run separate instances of VM. You can then build sub-patches, test them and optimize them as best you can in isolation and then build a master patch that connects together these sub-patches with relatively simple high-level wiring between plug-in hosts. This hierarchical approach is far easier to manage than doing everything in one flat space.
My LSSP Tutorial 5 uses this approach and might be worth reviewing https://www.adroitsynthesis.com/lssp-101-tutorial-5/
utdgrant wrote: ↑Mon May 30, 2022 8:38 am That's a BIG patch!
ThatsABigPatch.png
I suppose one general approach you could take is to isolate each 'thread', or 'signal chain' and save it as a unique patch. Run that patch in isolation and see how much processor load you are using. That way, you can narrow down the most processor-hungry element(s) of the total patch.
You can then concentrate more of your optimsation efforts on those parts to help reduce the impact on total CPU load.
Also, I did notice a couple of things which suggest that a bit of housekeeping is in order.
Redundant02.png
The Six-Input Mixer appears to be redundant, here. I'd be inclined to just patch the Oscillator's pulse wave straight into the Ladder Filter's input. It's a tiny saving by itself, I know. However, if you stay alert to these small savings while building a patch, it all adds up. It might make the difference between a complex patch just being able to run or starting to glitch.
ColinP wrote: ↑Mon May 30, 2022 9:23 am OK, you seem to have half apologised for being so rude to people here, so I'm going to give you one more chance. Any comments similar to the obscenities you posted before and it's bye bye permanently.
Your i7 8700 does about 28 GFLOPS so is reasonable powerful. It's about 75% as powerful as my CPU and I can build patches with about 200 basic modules so you ought to be able to do some fairly crazy stuff.
However as Grant points out you need discipline to build large patches. Just throwing another module at a patch isn't going to make it automatically sound better.
Your patch has seven plug-in hosts. I haven't got time to look at exactly what you are running in them but each of those is potentially very expensive.
Your patch doesn't have obvious structure so you'll struggle to modify or debug it. Use a separate cabinet for each sub-system. Ideally label each cabinet using a notes module on the far left. You can also document other stuff with the notes modules so that when you come back to a patch a week or two later any obscure details that you've forgotten about can still be understood.
Your patch is about the limit of what is sane to do without breaking it down into some kind of hierarchy. Again as Grant advises you could isolate things and then look at CPU usage running things standalone. Although as I've stressed in the thread on metering it's difficult to really judge how close you are to buffer overrun without a meter.
Anyway one way to break through these problems is to modularize by using the plug-in host to run separate instances of VM. You can then build sub-patches, test them and optimize them as best you can in isolation and then build a master patch that connects together these sub-patches with relatively simple high-level wiring between plug-in hosts. This hierarchical approach is far easier to manage than doing everything in one flat space.
My LSSP Tutorial 5 uses this approach and might be worth reviewing https://www.adroitsynthesis.com/lssp-101-tutorial-5/
No, just one (of the many!) plug-in hosts trying to load up a VST plug-in that was part of the patch.
I don't know about this specific preset, but I use VM's Plugin Host and Mini Plugin Host extensively for dlls and vst3s, both FX and Instruments, and both in standalone mode and as a plugin. You might want to read about those modules and try them out, if you have them.
