List of tricks to avoid running out of voices

[hermitnerd]

Hi Philippe,

I often find myself making very complex Origin programs, and then finding that I only have 3 or 4 or 5 voices of polyphony.

Could you or someone in the Origin team post a list of things, or tricks, we can use to conserve CPU and have the maximum polyphony? Let's assume that we are using the maximum number of modules allowed in a Program (20?), so the number of modules is not a variable.

For example (these are just guesses)

- use "Origin" modules wherever possible. CS-80 modules are the most expensive, followed by Jupiter 8, Minimoog, etc. (again, just guesses)
- keep the TAE knob at minimum
- if you don't need FX, have all three FX slots set to "Bypass"
- Outputs are more expensive than MiniMixers, so use MiniMixers whenever possible instead of Outputs
- filters are the most expensive, followed by oscillators, followed by Outputs, followed by envelopes
- etc.
- etc.

These kinds of criteria should be available to us. We don't have access to the source code, so we can only guess at these things. If you were to give your loyal Origin users access to the source code, it would solve a lot of problems!

I've also found that the limit on polyphony is inconsistent, for example I'll be working on a Program and have only 3 voices available, but when I save and re-load, there will be 4 or 5 available. It would help to have these kinds of things explained too. Thanks!

[Philippe]

Well, it’s not that simple....

Let’s take the example of an oscillator. The processing is separated in 3 parts:
1- process modulation inputs
2- generate the waveform
3- apply some sort of spectral shaping (in fact some kind of filtering)

The step 1 cpu usage depends on:
- the number of connections from a source to an input of the oscillator
- the nature of the signal flowing thru this connection: in the Origin engine we use 3 kinds of signal:
    - TRIG
    - SLOW
    - FAST
Each kind of signal has its own processing, the FAST one being the more costly.

The step2 cpu usage depends on the selected wave shape and wether the composite “FM” modulation is SLOW or FAST. Some of the wave generation algorithms are constant time with respect to frequency, some others are not. For instance one of the algorithm we use is a variant of the minBLEP algo. The cost of this algo is directly proportional to the number of (anti-aliased) transitions that have to be computed.

When using an “Origin” oscillator there is a greater usage of constant time algos, and - if I remember correctly - no post filtering. When using a “typed” oscillator - say a cs80 one - we make a greater usage of minBLEP algo which is more costly than the constant time one as soon as you play medium to high frequency notes, and comparable when playing low frequency notes. Also there’s a post-filtering.

So the answer to your question is not easy. There is a piece of code - around 500 lines of code - inside the micro-controller firmware that estimates a typical and max cost of a voice. These cpu estimations are used by the DSP kernel to manage voices allocation. I’ll try to find some time to translate this code into a readable document by all of you. Don’t know when though.....

[hermitnerd]

So the answer to your question is not easy. There is a piece of code - around 500 lines of code - inside the micro-controller firmware that estimates a typical and max cost of a voice. These cpu estimations are used by the DSP kernel to manage voices allocation. I’ll try to find some time to translate this code into a readable document by all of you. Don’t know when though.....

Thank you Philippe!

[JavaLaurence]

Here's another user with an interest in that promised document.........