Advice for poly subpatch CPU efficiency

#1

While preparing a subpatch for use in a poly synth, I am starting to wonder how many of the objects I should be taking out of the subpatch and placing in the main patch. There seems to be quite a lot I could do with inlets and outlets to feed data from the main patch into the poly "voices" - or is this actually not worthwhile to bother with?

#2

It would be nice to know what objects are heavy on the cpu .

(and add their cpu % to that website where all objects are listed )

#3

I agree, it would be nice. Same thing with RAM usage. I wonder if it's that simple though or do the amounts depend on the patching involved.

#4

I can see this would be very useful, but Id say thats going to be very difficult (impossible?) to collect... you'd have to create something to isolate the objects, and instantiate them... measure % cpu, would then require some kind of wrapper, which would be dependent on inlet/outlets types... not only that, but the compiler optimiser could make these measurements invalid.

I don't know any app that publishes this data probably because it tricky (e.g. have you seen this in Max/Reaktor?) ... I think best we see is guidelines which is what this post is about, but users could help improve on.

back to the original question... the answer is simple, only put something in the poly patch if it has to be in there i.e. it needs to be different per voice. if it can be shared across voices, then it should be.
this is where compromises can be made, it might be nice to have an LFO or a delay that is per voice, but if you start hitting limits of cpu/ram ... then you might have to move it out.

so yes, 'is it worth bothering with'... yes, if you are finding you lack resources... but at the same time don't expect miracles smile

compromises like this are part of programming a microcontroller with limited resources.
(actually true to all programming, but perhaps more obvious on these... its why usually FX are usually not per voice on digital synths)

#5

yes, Reaktor has this option, it shows the CPU% per module/macro

How I imagine this could be measured with Axoloti :
for example create a patch with 50 filters, read the CPU usage, divide that by 50 and you'd have a reasonable indication of what a filter uses.
Not sure if it would give the same results in a 50 voice polyphonic patch (with just 1 filter), but that is easy to test.

#6

thats not what i said... i said they don't have a list of what cpu/ram each object uses...

as for Reaktor, its different, is has a debug mode, which shows how much cpu is being used when a patch is running. this is much more valuable because its within context of a real patch.
this is possibly something you can already do, if you connect to the board via SWD (need to solder on header pins), but not realistic for us to program separately, it would be a lot of effort to do instrumentation, and given the resources, the instrumentation could itself possibly be a significant overhead.

(SWD debugging, is not trivial to setup or use, so Id only advise for experience developers, also getting a result is tricky, as it would be at the xpatch level, not the objects which a user is familiar with... I did post something about how to setup SWD some time back)

your 'idea' is basically what I said... creating a wrapper, but as i said doing this so it would work generically for an LFO, a OSC, a filter, a sequencer, a maths object... generically is a huge amount of effort, and as i pointed out how the compiler optimises code for a single instance of a filter vs multiple may be different.
of course, there is nothing stopping a user doing this themselves for an individual object, if they believe there are a few different ways to implement this... and would like to see the impact.

I'll repeat, I like the idea... but just think its a lot of development effort, which is better spent elsewhere,
(of course, @johannes or another developer may feel differently and might 'pick up the baton')

#7

On G2 all the data objects are low on DSP and audio objects like filters, chorus, reverb. etc. takes a lot more DSP.....

Probably the same on this platform since both are DSP based.

#8

personally a cpu meter for stuff isn't really on the top of my wish list.

#9

Naah, not that important to me either.

#10

CPU consumption of an individual object can change when inlets and/or outlets are left unconnected, or even depend on broader context, due to compiler optimizations.
I created a patch/cyclecounter object and associated help patch (on github now), that can be used to measure the number of cpu clock cycles consumed in the dsp function of one or multiple objects.