geddonn

Hi there, I've been planning out the next development for my main performance patch for a while now and wanted to clear this up before I begin.

The general idea is a modular environment for creating music, in previous versions I have organised these modules as separate patches that open in their own windows. I have been under the impression that there is some CPU benefit in doing this, perhaps something to do with multi-threading? I'm not sure where I got this idea from, perhaps from this very forum.

However, for the latest version I am leaning towards an all in one patch window approach, though don't want to go down this path if it is less efficient as I want to squeeze as much DSP goodness out of my old 2-core Intel MacBook Pro as I can.

Can someone confirm for me if there is a CPU benefit either way or if it doesn't matter at all?

multiple-patch-windows-vs-all-in-one

I believe it doesn't make any difference. You may be able to squeeze more performance by taking advantage of multi-threading if you use poly~, and/or if some elements of the performance are partitioned off into a separate patch built as a standalone, but if you only have a 2-core CPU this will probably be of little or no benefit.

If you are using a modular environment, you may want to look at dynamically loading sub-patches when required, if not all modules are used at the same time.

It does make a difference for MSP patches. Top-level patches (ie. separate patches opening in separate windows) run their audio in separate schedulers, thus making better use of multi-threading. poly~ does too, though the first voice runs in the main scheduler, so there' only benefits with at least 2 voices (real performance gain/loss depends on the actual patch).

So yes, do keep the separate patches approach for better performance. You can even consider exporting 'm all as stand-alone apps. Could give you some more gains but whether it's feasible depends on what and how much data you need to send between 'm. udpsend/receive, jit.net.send/rec and soundflower can help inter-patch communication.

It does make a difference for MSP patches. Top-level patches (ie. separate patches opening in separate windows) run their audio in separate schedulers, thus making better use of multi-threading. poly~ does too, though the first voice runs in the main scheduler, so there' only benefits with at least 2 voices (real performance gain/loss depends on the actual patch).  

So yes, do keep the separate patches approach for better performance. You can even consider exporting 'm all as stand-alone apps. Could give you some more gains but whether it's feasible depends on what and how much data you need to send between 'm. udpsend/receive, jit.net.send/rec and soundflower can help inter-patch communication.


Thanks for the input guys. I knew it wasn't a hallucination!

Throws a bit of a spanner in the works though..

My idea was to wrap each module in a poly~ so that I can swap out modules without having to rebuild DSP. I was going to use the 'open 1' message to each poly~ to display the modules GUI.

So if I have each module in a different window I will have both the poly~ and GUI windows floating around the screen. Not bad for a few modules but quite bad as you start using more.

I think what I'm looking for is a non-existent poly~/bpatcher hybrid....

https://cycling74.com/forums/ann-share-aharker-externals-convolution-dynamic-dsp-and-more/

it includes externals which manage "Enhanced audio multi-threading / dynamic patch loading"

the first voice of a poly~ runs in the main scheduler, so it might be tricky to use poly solely for the aim of one module instance in another scheduler - though it might be possible, surely, if you have a 2-voices poly~ and mute the first one ?

I suspect that separate patches will only give a performance benefit if they aren't sharing audio with send~/receive~. If you're intending it to function like a modular, this might be a problem.

There's not a great solution to this problem; I was working a while ago on a modular synth that could be used with polyphony. Dict helps but still...

I suspect that separate patches will only give a performance benefit if they aren't sharing audio with send~/receive~.  If you're intending it to function like a modular, this might be a problem.  

There's not a great solution to this problem; I was working a while ago on a modular synth that could be used with polyphony.  Dict  helps but still...


I suspect that separate patches will only give a performance benefit if they aren’t sharing audio with send~/receive~. If you’re intending it to function like a modular, this might be a problem.

Interesting, I didn't consider that. Worth a test. I guess channeling audio thru soundflower circumvents it if it's really the case.

I suspect that separate patches will only give a performance benefit if they aren’t sharing audio with send~/receive~. If you’re intending it to function like a modular, this might be a problem. 

Interesting, I didn't consider that. Worth a test. I guess channeling audio thru soundflower circumvents it if it's really the case.


Thanks for the continued input, I'm going to have a look at Alex Harkers externals over the weekend.

The way I have had it set up before is that every module can both receive and send audio to any other module using Matrixctrl in dial mode as a mixer (precautions have of course been taken to avoid feedback).

So every module has been using send~/receive~ to get audio to and from this 'global mixer'. This has proven quite flexible and pleasing in how much I can get out of each module.

Are you saying it would be more efficient having these modules hardwired and in one patch then?

Thanks for the continued input, I'm going to have a look at Alex Harkers externals over the weekend. 

So every module has been using send~/receive~ to get audio to and from this 'global mixer'. This has proven quite flexible and pleasing in how much I can get out of each module.  

Are you saying it would be more efficient having these modules hardwired and in one patch then?


No. Peter suspects that the benefits of separate patches is negated by the send~/receive~ connections, though it shouldn't make it worse. This should be confirmed by testing. Any chance you wanna throw all your patches in 1 big one and check the difference? You can leave the send~/receive~'s as they are, no need to repatch.

Send~/receive~ mean that the two patches aren't isolated from each other, so you won't get the benefits that you would for parallelism. It won't be any worse, as dtr indicates. You could probably patch through Soundflower, but this will (AFAIK) probably introduce a little latency.

One of the best ways to reduce CPU usage is to downsample via poly~. You can't do this with audio signals without degradation, but you can get away with it for envelopes and LFOs.

Send~/receive~ mean that the two patches aren't isolated from each other, so you won't get the benefits that you would for parallelism.  It won't be any worse, as dtr indicates.  You could probably patch through Soundflower, but this will (AFAIK) probably introduce a little latency.  

One of the best ways to reduce CPU usage is to downsample via poly~.  You can't do this with audio signals without degradation, but you can get away with it for envelopes and LFOs.


I see. I think I'll avoid the soundflower work around as it would be a lot of hassle to set up each time and I'm already getting enough of a delay from increased vectorsize (really should upgrade computers sometime soon).

I've defaulted to another idea I had where I will have the DSP algorithm in a poly~ and the GUI in a bpatcher so I can dynamically load both in a single window.

Would it be more efficient to get rid of send~ receives~ completely then and hard wire it all?

I haven't got to my automation/modulation section yet but will keep the downsampling idea in mind thanks, Peter.

I'll let you all know when I finish testing things. There are quite a lot of complicated modules so it's going to take a while to transfer things over, especially as I am setting everything up for OSC now and trying to implement some kind of Jamoma-esque parameter handling.

I think send~ receives~ introduce a vector's worth of latency,so if you're dong send->process->return etc in a modular fashion, those latencies will add up ie 2 vector's worth per module

otherwise I believe there's no practical difference

I think I can live with 2 vector's worth of delay for now. The flexibility of having things sectioned off in windows eg. Instruments, effects, modulators etc. could be worth it.

I'll try and get a version running using both methods over the week and see what task manager says!

I think I can live with 2 vector's worth of delay for now. The flexibility of having things sectioned off in windows eg. Instruments, effects, modulators etc. could be worth it.
I'll try and get a version running using both methods over the week and see what task manager says!


Multiple patch windows vs all in one