You said “Lightweight”?

Worried about CPU usage or memory consumption with Blue Cat’s PatchWork?

When using a plug-in such as Blue Cat’s PatchWork to host plug-ins, one may be concerned about the overhead added by such a “wrapper” and decreased performance. Indeed, you do not want this plug-in to use too much CPU or memory (RAM) and keep these for the plug-ins that actually process your audio!

For example, when using Blue Cat’s MB-7 Mixer to just host plug-ins, its memory consumption may be a limiting factor, if you are still running a 32-bit host, such as Pro Tools 10. The plug-in was indeed not  designed for this purpose, and many of its features cannot be removed at runtime, even with the special single band skin.

That’s where Blue Cat’s PatchWork is very handy: it was designed to use the strict minimum of memory and CPU, to let most of it for hosted plug-ins and get optimal performance. The consequence? You can host hundreds (even thousands!) of instances into your favorite 32-bit or 64-bit DAW without any problem!

As an example, see below a Pro Tools 10 Session with 1000 instances of Blue Cat’s PatchWork on 100 tracks (level meters disabled to save CPU). Pro Tools’ memory footprint is only 1.5 GB, which gives plenty of room for your own plug-ins!

PT-Patchwork-1000 instances

Feel free to share your own experiments on Facebook, twitter, youtube or on the forum!

6 thoughts on “You said “Lightweight”?

  1. I am trying your demo of v 1.73 and have tried BitWig and Ableton, in both cases each instance of patchwork seems to consume 10MB of RAM without any additional plugins and meters turned off. How did you get 1000 instances with only 1.5gb of memory used? It seems you would need patchwork to consume only about 1 MB per instance to do that. Why am I experiencing different results? Win 10 and 64 bit version of both hosts.

    • The first instance will usually use more memory, because other instances will share most of the heavy data (graphics, code etc.), but I don’t know why you are experiencing such a difference. I guess it may depend on the overhead of the host application. Also, the 64-bit binary is bigger, so it should indeed take more RAM than the 32-bit version (up to twice the RAM). Also, this test was done on Mac, which can make a difference too. Anyway, with a 64-bit application you usually do not care, since there is plenty of virtual memory available: you can load thousands of them. Have you had any issue with the number of plug-ins that you could load?

  2. vers 1.74:
    standalone app running on mac mini late 2012 with OS X 10.12.3, 4 gb ram. 3,72 gb of them are taken by Blue Cat’s PatchWork. Garage Band & Logic use much less…
    Lightweight plugins in stack: waves max volume leveler, psp mixsaturator, waves lineq broadband, psp mixpressor, psp vintagewarmer 2, aom invisible limiter.

    • The PatchWork App itself takes about 40 MB in memory (Mac/64-bit mode). So I guess there is something going on with the loaded plug-ins. The memory may grow a little bit due to undo history in case the plug-ins are heavy on saved data, but it is surprising that you get such a result. Do you have the same memory usage when just starting the app and loading these plug-ins? (without further manipulation)

      • Sorry. That was because of the opened plug-ins windows for a long time. When all plug-in’s windows are closed – only 77 MB of RAM. But if I open some of them – this value starts increasing. Not fast, but up to 3 GB during some time (about 24-36 hours).

        • I guess this particular plug-in is not releasing memory until its GUI is closed. It is likely to be a bug in this plug-in (We could not reproduce the same issue with our own plug-ins for example).

Leave a Reply

Your email address will not be published. Required fields are marked *