Hi, there... I really need some help.

I'm working on a looper-multi-effects (big) patch. It has more than, more or less, 100 stereo FXs. They are all inside the patch as abstracts. But, to avoid them to consume CPU, each one has a [switch~ 0] if it is not working. So, there're only two FX at a time, where the DSP is on. Something like this:

Main patch:

adc~
| \
|

[catch~ $0-post-l]
| [catch~ $0-post-r]
| /
[dac~]

(the same for

Each FX as file-abstracts (using [fx1 $0] to call them) inside the main patch:

[r $1-pre-l] [r $1-pre-r]
| /
[The-FX-itself.....]
| \
[throw~ $1-post-l] [throw~ $1-post-r]

[0( [1(
| /
[switch~]

This technics DOES work very well. Buuut... when having 100 FX at the same time (even not working), the CPU increase 15-20%. I repeat, there're only two FX working at the time. The rest are "turned-off".

For now, the CPU use is:

Ready-to-use, 2 FXs on, DSP on: 47%
Recorded and playing 8 stereo-banks, 2 FXs being used, DSP on: 60 - 62% (I have quite a few XRUNS)
Ready-to-use, 2 FXs on, DSP off: 7%

As you can see, the non-signal processing is very low.

What I think is that each FX is working when receiving and/or throwing signal (200 [receive~] and [throw~] objects)... even they are sending and/or processing nothing.

Is there any other way to connect all the FXs to the main patch and to have a lower CPU consumption?

Maybe [inlet~] and [outlet~] consume less CPU? (I should connect all the FX at hand... or find a aumotated way to do it)

Thanks a lot.

I really don't think [throw~] and [receive~] are the problem here. From looking at the source, all the summing to [catch~]'s buffer is actually done in each [throw~] object, so if the [throw~] is turned off, it's outright ignored. Similarly, [send~] doesn't write to every [receive~] buffer; each [receive~] just reads from the [send~] buffer. So, again, if [receive~] is turned off, it is ignored.

I just did a test with a simple flanger abstraction, tucked away in a subpatch with [switch~ 0]. Nothing going on in the parent patch, and there's no message processing going on the abstractions. I made 100 copies of it and turned the DSP on. CPU consumption did go up about 2 percentage points on my i3.

I suspect there's likely some overhead involved with just having those abstractions there. Even if they are switched off, Pd still has to check to see whether or not it is switched of before moving on to the next abstraction. I wouldn't think that would cause much trouble, but, then again, that is one of the downsides to real-time interpreters.

I get the impression your computer might be on the weak side. 7% with DSP off is kind of high; that is, unless there is still other stuff going on. So, make sure that any running message processing is also turned off when you aren't using it. Check the abstractions and make sure they are blocking incoming messages when they are switched off. Also, if you're not using jack, use it. And if you're getting xruns, you probably need to bump up your latency if you can get away with it.

EDIT: 3 MESSAGES BELOW THIS, I WROTE WHAT I ACCHIEVE (anyway, if you want to read, you can do it, these are my tests)

By doing some tests, deleting subpatches, one by one, I got these results:

Deleting both FX Consoles (eg "meh_console $0 a"). They contain:

• Receiving signals from input (mic) or banks and sending to output (speakers) or banks.
• ALL THE FXs (inside each FX-abstract, there are switch~)
• the FXs and FX groups selection control
• the X-Y pad, depth, etc
  The CPU consumption decrease: 10-11%

Deleting the 8 Looping Banks (eg "meh_bank $0 a 1"). Each one contains:

• two 1.411.200 size arrays (32 seconds * 44.100, left and right)
• receiving from and sending to FX consoles.
• sampling, resampling, "looping" (as loop-station), overdubbing (using ipoke2~*: is a modification by me of ipoke~, from Katja. It only goes over the array and nothing else, unless I tell it to record to it) control.
• playing control
• main and bank modes control, bank volume, etc.
  The CPU consumption decrease: 18%

Deleting 2 DIY2 stereo EQ7 (by Hardoff) from mic input and speakers out:
The CPU consumption decrease: 9%!

Deleting FXs consoles, 8 banks, 2 EQ7 (that is, almost all), the CPU is 2-3%.

So... 11 + 18 + 9 + 3 = 41%

Maelstorm, I checked if there're no messages processing... and I think little is working. I WILL CHECK IT AGAIN, AND I WILL DO SOME OTHER TESTS.

J Oliver said, by PD-list (I took the dare to post it here):

Hi Mario,
There is a thread somewhere about connections vs. s/r & throw/catch, don't have time right now to search for it, but I'm sure it is there. If I remember correctly the overhead is not that big and you don't want to be connecting all that stuff by hand.
In any case, there are other things to look for.
If you are using graphics objects, or objects like env~ you might want to bring down the refresh rate. Are there any [metro 1] or similar objects lying around which you might have forgotten about?
Do you have a lot of GOP? I am not sure this is entirely relevant, but it might be worth researching...
Also, control operations do take some cpu. do you have a big control layer?

• About connections, s/r, throw/catch, Maelstorm thinks the same.
• Disabling all GOPs in main patch... it doesn't change anything.
• Disabling all env~ or metro-snapshot... maybe it decreases 2-3%.
• The control layer is in the attached PNG, but I will control it with a Tablet. So, if I need to use Pd with no GUI, there would be no problem.

I repeat: I WILL CHECK IT AGAIN, AND I WILL DO SOME OTHER TESTS. But, if someone has a suggestion... I appreciate it.

EDIT: the WIP thread, downloadable patch, DIY2 abstracts folder, KP3-FX list PNG and TouchOSC interface: http://puredata.hurleur.com/viewtopic.php?pid=37430

http://www.pdpatchrepo.info/hurleur/Captura_de_pantalla_de_2013-08-05_22:33:39.png

EDIT: 2 MESSAGES BELOW THIS, I WROTE WHAT I ACCHIEVE (anyway, if you want to read, you can do it, these are my tests)

More tests.

Adding a [toggle]- in main patch and [r $1-switch]-[switch~] inside different subpatches, I can check how much the supatches consume. I first tried with the Sample Banks. IMPORTANT: I did it in this way, to turn all the Banks DSP off (8, in total).

In playback subpatch: a difference of 8% (phasor~, tabread4~)
In sample-resample subpatch: 3% (tawrite~, vline~, and input-selector...)
In "looping" subpatch, 1% (the same as sampler, with no selector)
In overdub subpatch: 4% (ipoke2~, 5 delay lines...)
In the Bank main patch: the sum of previous tests, plus 3% (all the bank)

Maybe, I should play with switch~ objects inside them. At worst, they would be 7 banks playing, and one overdubbing. Supposedly, I could save 8-10%...

I will do the same with the FX Console and I tell you...

EDIT: BELOW THIS MESSAGE, I WROTE WHAT I ACCHIEVE (anyway, if you want to read, you can do it, these are my tests)

With FX console.

Whole: 9%
All FXs (100 abstracts): 6%
Small signal redirection subpatch: no difference.

Maybe... as in Banks, I should play with switch~ inside FXs groups. Maybe I could save son CPU...

I put switch~ everywhere! Well, indeed, I put it inside sampler-resampler subpatch, looping subpatch and overdubbing subpatch of all the Banks. Playing subpatch should not have, because they always be playing... it does not make sense to turn them off, if most of them will be on during performance.

What CPU percent do I have now?

Ready-to-use, 2 FXs on: 25-26% (there are 2 FXs always on, although they are muted)
7 Banks playing, 1 Overdubbing, 2 FXs on: 31-33%
DSP off: 6-7%

Maybe I could improve message managing... but, when it is doing nothing (DSP off), the stuff that is working is:

• metronome (modified cmentronome.pd, by Chris Edwards, posted by screwtop)
• CPU meter
• nothing else (I tested all the patchs with magic glass).

Maelstorm, do you think that having those all abstractions there could consume more CPU than being subpatches? If yes... I could convert them. But is a pity, as they are now, they are very arranged.

I use Jack: 44100Hz, period = 256 frames (5.8 ms), buffer = 4 periods. During the recording of 8 banks, one by one, I got 5-6 XRuns. I have one (sometimes two) any time I select an FX. When I have the Sennheiser headphones (this Thursday), I'll check if the XRuns make any noise.

I forgot to say that each FX that this system use, has 1... or 2 or 3 or sometimes 4 abstracts inside it (most of them, from DIY2). So, there aren't 100 FXs abstracts... possibly there are about 250-300 there.

As I wrote above, here is the WIP: http://puredata.hurleur.com/viewtopic.php?pid=37430. You can download and take a look... if you wish. I have all my patches ordered, so, it is not difficult to understand. Subpatches, abstracts, values and so, are all in english, but comments are in spanish.

Looks like you made a significant improvement, but I'm not really clear what you did with all these updates. What was it that gave you that extra 30% CPU when the patch was running? I thought you already had [switch~] everywhere.

@MarioMey said:

Maelstorm, do you think that having those all abstractions there could consume more CPU than being subpatches? If yes... I could convert them. But is a pity, as they are now, they are very arranged.

I seriously doubt it. Once Pd builds the DSP graph from a patch, I can't imagine it would be much different if they abstractions were subpatches instead. The only big difference between the two would be expanding arguments, but that only needs to be done once. So, no, don't do it.

I use Jack: 44100Hz, period = 256 frames (5.8 ms), buffer = 4 periods.

What interface are you using? I use a USB audio interface, and I've read that they clock better when you set the sample rate to something that easily divides by milliseconds, and it seems to be true. I get less xruns when using 48000 than 44100. Also, I've heard USB cards should be set to 3 periods, though I don't know why that is. At any rate, I believe that most sound cards run at 2 or 3 periods, so you might want to knock that down. With the small amount of xruns you're getting, it's possible that you just have settings that aren't ideal for your audio device and not simply that you're doing too much processing.

I check out your patch later and see how it runs on my system when I get a chance.

The entire patch tree is something like this:

Main patch (meh_system.pd)
• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.
• FXs Console x2 (meh_console.pd)

• • FXs & group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)
• • FXs groups x8 subpatches.
• • • FXs abstracts x100 (fx-*.pd) ***
      • Sample Bank X8 (meh_bank.pd)
• • Control subpatch [pd toggle-color-seteos]
• • Sample - Resample subpatch [pd rec-sample-resample] ***
• • Looping subpatch [pd rec-looping] ***
• • Overdub subpatch [pd overdub] ***
• • Playing subpatch [pd play]

The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts. The difference is 20%, not 30%... but it's a lot for me.

I'm using integrated soundcard
00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40).

I will turn everything to 48000 and "knock periods down". Since I knew that the audio process is a CPU job and, for the moment, I don't need more that 2 input and 2 output channels, I though I don't need an external soundcard. Does a USB soundcard improve performance? If so, why?

Because of my economy and the use I will give it, if I buy an external soundcard, I think I will choose the http://www.encore-usa.com/ar/product/ENMAB-8CM. I know that it is not a very good soundcard... but it's better than the integrated... and I would win more inputs and outputs.

I check out your patch later and see how it runs on my system when I get a chance.

The WIP uses externals from PdExt and the zip includes ipoke2~.pd_linux, for 64bits, but it's only for overdubbing.