Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

First play with global chain + 6 channel recorder: did I get this right?

I just had a play with global chains, and would like to get some input on whether I set this up correctly:

Pre global chain:
Channel 1: Two mixer units, one doing some sample playback, one a synth.
Channel 3+4: Clocked delay, input from channel 1, wet/dry adjusted to taste, channel 3+4 was my stereo output.

Using global chains:
I created moved the two mixer units from channel 1 to a mono global chain each. The Clocked delay was moved to a global stereo channel. So at this point all the non-global channels were empty, so in order to get output i inserted three mixer units on channel 3+4 (still linked for stereo output), each grabbing the output of the strings, the synth and the delay, the idea being this is where I mix how much of the strings, synth and delay I want to hear.
Then in the global chain for the delay I placed two mixer units before the delay, one with the strings global channel as input, one with the synth global channel as input, acting like individual sends to the delay.

Obviously this gives much more flexibility (actually I was doing all this to be able to record things individually with the 6 channel recorder), but I was surprised to see the CPU usage go up from 42% to 49%. The only point where I felt “now I’m doing something more expensive” was when adding inputs to the mixer units acting as effect sends (so on the global stereo chain), I had to assign both left and right to be coming from the appropriate global mono chain.

So did I miss something here? Anyway to lower the CPU penalty? Any thoughts or advice?

BTW: I hope the above is clear, it’s a bit hard to explain in words, but I hope it comes across :smiley:

This sounds very similar to my use of global chains in my newest project. In global: 4 dub loopers, some slew limiters, many SC.CV units, etc. In channels 1-4: mixers, VCAs. I’m pushing the CPU a bit too hard (78%) so I might try experimenting with moving some of the chains away from global chains. I will let you know if there is a significant impact on CPU usage. Unless @odevices wants to give a general comment on the matter? The new routing options in v0.4+ make globals less necessary (but I’d prefer not to make a bunch of local connections).

Thanks!

So you’re suggesting that units consume more cpu in global chains than in channels? Never thought about that, might have to test it out, however unscientific if might be.

I’m contemplating relying heavily on the 301 as mixer (besides sound generation) for my next live appearance, excited to see how far I can get with the available horsepower.

i found this little piece of information usefull/interesting

EDIT: especially the last “command”

1 Like

hey @mopoco i almost forgot that discussion! thanks for bringing it up, it was a very nice re-read :slight_smile:
also, i’m now reading it after delving a bit into max msp and supercollider so i can now comprehend more clearly what @odevices said about topological sorting! his point of view now makes much much more sense to me.
damn i really love this forum and this little beast of a sound computer!!

1 Like

The answer to that should definitely be no. A unit’s cost does not depend on where you insert it except to the extent that mono vs stereo might affect it. The number of connections should not matter either. CPU load will usually be the sum of the fixed cost of all units in use (plus the 3% of overhead).

The cases where this is violated (in order of severity) are:

  • Manual Grains: CPU load grows as more grains are overlapping (i.e. polyphony).
  • All random-access sample playing units and delay units with a speed control: L1/L2 cache misses caused by non-sequential access to sample memory will result in increased CPU load (stalling). Layman translation: Randomly jumping around in the buffer at audio rates, or playback at really high speeds (>10x). This forces the ER-301 to repeatedly query the RAM (slow) for necessary data because it is not in the L1/L2 memory cache (fastest).

All other units are designed to have fixed CPU cost that does not change in response to changes in their inputs.

4 Likes