polyphony cpu considerations

MvKeinen

Hi!

Say you want to have 6 of the same monophonic synths of medium to heavy cpu use each having:

• 2 oscs
• 2 filter
• 4 env/lfo
• 1 sequencer
• 2 delays (yes, I want each of the 6 to have 2 delays)
• A LOT of vcas, modulation operators etc.

now, the somewhat special thing is that there is one global voice that is exactly the same but, next to being a voice its modulation sources can also can modulate all the 6 voices.

If core had voice access I'd make a 7 voice polyphony.

As I see it there are two ways: (I'm leaning to A but there might be problems)

A: Single poly corecell

• copy the global voice to any of the single voices. You'd have to calculate 12 voices that way
• benefit: way simpler structure on the primary level
• problems: cpu. deviation in the global voice per channel?*

B: One poly, one mono corecell

• send all the modulators ("CV" and audio) from the mono to the poly corecell
• benefit: cpu
• problems: I like structures to be extensible. even in the proposed example there would be a lot of modulation signals which would have to be sent over the primary level. Solution would be to iterate through the modulation array in the mono cell at any audio sample clock and send all the signals through a []/$ bus. But that might be an even bigger cpu hog. When I tried it the CPU meter of Reaktor stayed low but the CPU meter of my OS went up a lot.

*: now, A would be much simpler but there is the question when I copy the global voice to all the others, would the voices deviate from each other? Is there some kind of digital drift? What about a random LFO?

CPU wise I'm not sure, I find it hard to build a realistic test ensemble. So any insight is welcome.

colB

Probably B, although I would test both to see what the cpu difference is.

The reason I say both is that there are two benefits to using separate core cells. One is potential cpu saving (although you never known until you test), The other is compile time. The core compiler often compiles two smaller core cells faster than one large one. It's a strategy I've used when compile times start to become problematic - refactoring the code into two separate core cells can sometimes have a dramatic effect on this.

I don't think this should effect the extensibility of the code anyway? You still have the same basic thing going on - 6 similar things, and one different that the 6 have a dependency to... bringing them into different core cells shouldn't impact extensibility - might even improve it?

I'd also consider a third strategy 'C', having a polyphonic cell with 7 voices, a separate mono cell with just the special global modulation sources. Then feed in voice ids from the voice info module, so you can handle one of the voices as a special case within that polyphonic cell... This may or may not be more efficient or more extensible.

In general, using Voice ID within a poly core cell can be a useful technique for stuff like oscillator drift, unique seeds for noise, ****** like that :)