Polyphony limited even with nearly half CPU still available

#1

I'm building a big synth to be played (notes) via din MIDI, and manipulations (cc) made by Launchcontrol XL. I can map everything fine, and I have two instances of the same subpatch in the parent to enable me to switch between mono/poly performance.

The problem I'm encountering is, even though the CPU reaches just 55% with 4 voices in one subpatch and 1 voice in the other, whenever I try to increase voices on the poly subpatch (I'd ideally like 6-note poly) the patcher disconnects because it takes too long to go live.

I've noticed the oscillators I'm using (2 of beat's 'Multiwave' in each voice) makes the CPU change by about 5% depending on what waveform I select. Could this fluctuation be causing the issue? I realise with the polyphony I want I'd be using 14 instances of the same (slightly unstable?) oscillator.

Thanks for reading - I really hope there's a fix

#2

Try with 1.0.10 if your not already on it

It's also possible it could be a memory issue rather than CPU. Trying reducing number of presets and modulation sources in patch settings.

Hard to say without patch, and also I don't know how
Beats object works/scales.

#3

Thanks for the reply. I was considering tinkering with the preset settings/mod sources. What does it mean by modulation sources? I'm doing all of my control from the parent patch with all needed parameters on the parent, so does that mean I can set presets and mod sources in the subpatch to zero and it wouldn't matter when using presets on the parent patch?

I want to save 8 presets to be recalled by buttons on the Launchcontrol. This is the last thing I need to add so I haven't researched presets in a lot of depth yet.

Here is the patch (bigman) and subpatch (doubleMW). I can only apologise for how messy some of it is! Still not sure I'm doing everything the most efficient way.

bigman.axp (26.4 KB)
doubleMW.axs (27.5 KB)

#4

Oh, and I'm using 1.0.10

#5

Ok, I took a look it something to do with the 'extreme' number of dials that are used in the sub patches.
it appears to be taking a long time to start the patch due to this... i.e. if I delete a bunch of them its starts working.

perhaps try using constants instead of dials where you are not exposing to the parent since they cannot be changed. this would be much more efficient for the patch, and use less cpu too.

@johannes, quite interesting, looks like the watchdog is assuming the patch is having issues.
I guess its probably not the most efficient, since there are so many dials which are essentially constants.
... not sure if the timeout perhaps could be a patch option on startup? or if its worth exploring what is taking so much time at startup.

to make it easier for you to test (open via url) I've embedded the voice patch.

bigman_emb.axp (91.3 KB)

#6

You are so helpful, thank you for such quick testing/response. As you can see (I assume) most of the dials are cc assigned so they are actually being used, so constants are not an option for the most part. What this makes me wonder though, is - will creating inlets instead of knobs for the subpatch object be less (or more) axo-intensive?

I know very little about what makes the patch efficient or otherwise. Thanks again for your help

#7

actually there are still quite a few dials in your sub patch that are not assigned to CCs. :slight_smile:

anything you put it a polyphonic voice is duplicated, so only include in the voice patch anything that changes per voice, anything that is the same for all voices should be outside, and as you said fed through via inlet/outlets.
(also watch out for not only cpu load, but also memory/resource wastage)

also consider 'nothing is for free', so you can assume constants (attributes in axoloti, i.e. things you cannot alter when live) are much more efficient due to the compiler being able to optimise code paths.
unfortunately UI components like dials/switches can never be optimised by the compiler since although you might have no intention of changing the value the compiler does not know this
(hmm given me an idea for johannes :slight_smile: )

with audio processing and particular with axoloti efficiency is important, and if your are building anything 'complex' its worth considering, and trying to be efficient as you 'go along'
of course, practically we don't always do this, out of convenience or due to limitations etc, but its worth at least worth doing this consciously.

#8

I see what you mean now - the knobs IN the subpatch which are just being used to scale or set values. I'll go tweak accordingly. Thanks again for the info!

#9

Changing knobs to constants worked, by the way. It can go 6 voice poly no problem now!