Understanding Gain Stages in Orac 2.0

I have a couple questions about how the gain stages work in Orac. One thing I have noticed happening is that some limiting / compression is occurring when I have multiple modules making sound. What I am imagining is that to avoid clipping there is a compressor somewhere under the hood that reduces levels when the combined gain stages exceed 0db.

Is the best way to avoid this by reducing the gain and/or thru gain in each of the modules by a certain amount? The levels default to 100% and range from 0% to 200%. I often have two modules playing sound at once and and additional input from a hardware synth through an effect. I will try some more tests tonight, but one of those modules is sampler24 with a set of normalized samples. Is there a simple formula to estimate gain reduction per module based on how many modules are producing sound?

I noticed that thru gain is not necessary on effect modules, so I have turned it down to 0% on all of those. I also added a scope to P2 but it’s hard to see the limiting or compression. For that I have to trust my ears. It’s a bit like flying blind with no instruments. How are you Orac veterans managing this? Thanks!

the master “peak compressor” (in mother.pd / audioIO) threshold is set at -3db (with 8:1 ratio, 10ms attack, 100ms release), so any normalized sound is compressed by default, and with these default settings most of patches/modules trigger it easily. Setting down the volume of the last module in the chain is the simplest way to avoid this obviously, while turning up the Organelle volume for compensation… (i released 2 modules made to be at the end of the chain, and they divide the output volume by [/~ 3] to avoid triggering the master compressor, but they are compressors… at least they have compression monitoring :sweat_smile:) :v:

1 Like

Awesome! Thanks @electrafa. I will definitely try those. Another issue might be that I have clds at the end of my first chain (A w/parallel router) and its output is about 50% of other fx modules, so I turned up the gain to 200% on A3 to make up for it. Maybe it would have been better to just reduce the output at the end of the other two chains (B & C)? clds seems to be pretty sensitive to input levels, so I have them cropped around 47% as well.

1 Like

there can be modules that clip their audio inputs (samplers of delays maybe, anything writing audio files i guess…), turning up the A3 to 200% is safe depending what module is on P2, personally i need compression there, it’s a part of the music i like so i usually turn up volumes with Parallel also, sometimes at 200% within the chains without issues so far, but if wouldn’t want compression i think the best trick would be to turn the Organelle volume at max, turn down volumes in Orac and check the master VU meter on the screen, there shouldn’t be compression bellow the 2 or 3 last “squares” (need to check this, could be useful…) :v:

1 Like

i spent a little time on this, apparently (with the Organelle at max volume) audio starts compressing when reaching near 50% of the VU-meters (over 6 active “squares”, there are 11 per channel)

1 Like

You could just take the master organelle compressor out of orac. There’s some threads on this, and it’s pretty straightforward once you open up pd and look at it.

Gain staging in orac is tricky, with some modules having a volume parameter inside them, and each module also having its own gain, as well as each chain. Basically, if something sounds like it’s clipping, just experiment to see where this is happening.

Idk if any of this is helpful, but it’s my 2 cents :man_farmer::ghost::jack_o_lantern:

1 Like

While working on the sequencer stuff I found myself gravitating to the master chain output gains…when using the parallel router with 3 chains (tracks), the chain output gains are akin to channel faders on a mixer.

I made a very simple modification to the stock parallel router module adding all three chain output gains to a single page, and making this the first page… then when you select the router the first thing that pops up are the chain levels so you can tweak them all at once.

parallel2.zip (2.9 KB)

put this in /sdcard/media/orac/usermodules/router then select ‘parallel2’ for s1 in Orac.

4 Likes

That’s pretty useful, thanks!

to those not familiar with developing modules on orac.
I’d like to point out its very easy for end-users to move pages around, or add parameters onto different pages - you simply need to edit the modules.json file of the module.
(orac doesn’t even care if you place the same parameter on two or more pages!)


@oweno im not sure id put it on the first page, as this means all the module pages are now offset. - that’s the reason the id had them in this order, so they match the module keys used for activation… i think this is very important.
what you could do, is place this straight after the modules - this would mean its still on a ‘known’ key, so quick to access.

generally what i do for gain staging is…
a) turn up/down individual modules that i know are quiet/loud
b) use the chains gain to balance ‘the tracks’
c) use P2 as main output gain.

so i could see if we had a page with gain for ch1, ch2,ch3,final out … that would cover most of my use-cases…
its 1 page for the chain and final out on a known key, and then individual gains are on the respective module key.


Orac uses its own mother.pd , so there is nothing stopping me adding parameters to control the master compressor if that’s desirable.
(just let me know what parameters and what there ranges should be… id use current values as the default

alternatively (perhaps preferable?) i could remove compressor from mother.pd, and

  • have a compressor in new module slot (out)
  • move compressor into the router

yeah I’m still grappling with the best way to give access to gain of modules.
currently its done in the most ‘modular/flexible’ way possible, as its under complete control of the router module - but that does limit the UI mechanism available.

however, I do recognise gain is a very important aspect, so perhaps it needs to be handled separately… e.g. i could imagine something ‘fancy’ where i could switch the vu-meters to present the input output of the ‘selected module’ when in mixer mode

of course, im still limited by UI ,
the main goal of orac, was that patches were easy to convert … so therefore ive not made any assumptions about the use of the keys, and in particular about the AUX key.
this mean most orac functionality end up in the menu - but this is not appropriate for something like a mixer which we need fast access too.

however, now that Orac is maturing, i’m thinking about ‘reconsidering’ this, and focus on allowing Orac to have a UI which is coherent, rather than just being compatible :wink:

in particular, I think @oweno and @chrisk have shown on recent patches some really creative use of the AUX key to form a ‘function’ key … and I like the way its consistent across patches.
I could see something similar in Orac, where AUX is used to:

  • toggle things (arm/play)
  • be a shortcut into other functionality, like a specialised mixer.

this would mean changes to some modules, but Ive some ideas on how to minimise that.

it seems like a good way forward for Orac, as the aux key/aux line and status have been a bit of misnomer in Aux, which means its tending to be under-utilised (imo)

1 Like

I actually added a +1 before the key module selection, so the pages are still mapped correctly… not the most simple modification, but still pretty easy. I like the idea of having it at the end too, although it adds one more interaction.

I’ve been thinking more about phasing out the compressor generally. The mother.pd patch for Organelle M no longer has the compressor. For the next OS update, I’m considering removing it from the Organelle 1 too, or perhaps making it a system setting to turn it on / off… For Orac, yeah I think it makes more sense as a module since it really shouldn’t be needed if you have all your gains adjusted correctly. So quickly being able to adjust these gains is important.

Implementing the Aux as a shift key in Orac is an interesting idea…so when you press Aux, it shifts function of the top 10 keys (at least that is how we have been using it, mostly because it fit nicely having 10 items on the small screen).

In Orac, the function buttons could be used to control both module functions and Orac functions. Say the first 5 (or fewer) keys get passed to the module as generic ‘button controls’, and these would change depending on the module. The remaining keys would control Orac functions (many would be shortcuts really) and would remain the same no matter what module you are on… some useful shortcuts might be:

  • preset save
  • preset new
  • preset reload
  • preset next / previous
  • empty module (replaces module with utility/empty)
  • jump to module gain / pan settings
  • jump to chain gain / pan settings
  • global start / stop
  • change module (jumps to module list)
  • go to home menu
2 Likes

Hi! i’m really interested by this conversation, i was looking forward to talk about this with you, so i’ll jump on the occasion to share my thoughts :slight_smile:

in my opinion, there shouldn’t be any digital music machine that doesn’t prevent output audio from clipping in 2019, especially the Organelle because it can do it pretty powerfully…! I think we (people) shouldn’t complain of having a compressor/limiter but should do in these situations :

  • if it sounds bad (of course nobody want a cheap master compressor, the actual tb_peakcomp is not bad but can be improved)

  • if it compresses too much (the actual one has its threshold at -3dbFS without an input volume control setting : i don’t really understand why it’s not set it at 0dbFS with a -3db make up gain for the same headroom with less compression but anyway that wouldn’t solve everything)

  • if there’s no monitoring over compression (actually we don’t know when it starts compressing, if we could see that more easily i guess patches would have a much lower output volume generally)

Take the OP-1 just for example (don’t buy it…), there is a cheap master compressor in it but the system is made so even with the 4 tape tracks at max volume it doesn’t compress until gain is applied on its dedicated page. The Organelle already have a more capable compressor/limiter than the OP-1 (and a lot less background noise) but doesn’t exploit its possibilities by default, i think it could be improved just by being easily configurable (at least its input volume, witch would be the patch output volume) and all problems about it would be solved. In facts i’d love to work on this with you to contribute for this machine and this community, i spent a lot of time on the tb_peakcomp and i could explain everything i did in SuperCompress/Capture to enhance it… In this case, i would think about a script in the SYSTEM -> Settings menu (or maybe create an Audio menu for few other purposes also) that would show a Compressor page, and from there tweak its parameters without killing the patch.

For Orac i think it’s different… while i believe there should be a limiter also for safety, the P2 slot is also perfectly made for it, but, thinking about this, i would like more « Post » slots where we could use more tools (equalizer, effects…) and the last module of the chain would stay the master module of the user’s choice (a compressor/limiter for me).

I hope i’m not looking like i’m complaining or attacking anyone (except TE but that’s personnal :sweat_smile:), i’m just looking to contribute for the best… :v:

Anyway i love the Organelle because even if you decide to change anything about this, we will always be able to configure it to our needs… and that, it’s good !

unfortunately not so simple - even a daw will clip on the final output stage… and that is the place that the organelle is clipping. prior to that PD is quite happy to process stuff ’ in the red’ ( aka > 1/-1 , assuming externals are written to cope with this :wink: )

but I do agree, the final compressor really should not really be being hit, id really like it to be nothing more than a brick wall limiter… but Id advocate control, as it might be useful on some patches to let the compressor push a little.

its interesting, organelle users have noticed the effect its having, but ive not seen many complaints about it - so its generally seems good…

I’ll admit I’m not a big fan of compressors, because when abused, they tend to ‘rob’ the sound of dynamics - just to be loud :wink:


so the issue is as per this topic… how do you gain stage? and what are the current ‘issues’.

first. I think gain staging on a in my experience of modular systems (eurorack/AE) is always tricky - the issue is some modules are ‘hotter’ than others, some of this is the nature of the beast e.g. an FX might be louder when its dryer than wet, a square wave oscillator is louder than a triangle/sine.

BUT this is also an area we could improve , by perhaps trying to balance the levels better , and/or even doing compression at the module level.
(this also has benefits, because things like filters/fx often are expecting a certain level of input - or might behave differently e.g. thing about overdriving a filter)

a good example of this issue is a polyphonic module… currently each voice is added together - hence playing one note is much quieter than playing 3 notes. this we could compensate for in the patch (e.g. rather than divide by a constant, divide by number of active voices)
Ive a suspicion that, perhaps, this is why the compressors exists in mother.pd, to even out these differences wihout the patch developer having to think about it too much.
(ive noticed before when I removed the compressor, gain staging becomes more important)


EDIT: chains are also a good example of above…
so I don’t do anything (automatically) to mess with the gains between chains.

so if you use only one chain, then its might be ‘quiet’, but if you have 3 chains producing a signal, it could be clipping.
the issue is ‘it could clip’ … it’ll clip if you have lots of overlapping sounds, but if they don’t overlap so much you wont.
or say, you are using 3 chains that are only being used one at a time (e.g. different synth on each) … you don’t need the chains to compensate for others.
(orac has no idea how you are going to use things)

then there is the issue if you compress to allow for this.
say you have a sequence running on ch1, and other thing running on ch2 and 3.
so ch1 is compressed… if stop 2 and 3, ch1 level is going to jump up…
this might not be what you want … you might want it to stay at exactly the same level.

1 Like

that’s true i said that a bit quickly… audio cards aswell, in fact a lot of professionnal stuff won’t include a limiter with reasons but it’s depending the context : a daw lets you to put the compressor/limiter of your choice on the master, and almost every daw includes one because it’s a fundamental feature. i believe that the master (digital) audio clipping is never wanted…

it is good as a compressor, unfortunately not as a limiter :wink:

i understand, i’m a big fan though but the amount used (if used) really depends of the kind of music or purpose…

I tried making a brickwall only but i didn’t had the results i hoped yet, i would need to create an Automatic Release Control like on the L2 that would adapt the release time from the incoming signal frequency…(tricky) so the best results for me now are when combining one with knee and ± soft release before a real brickwall with lookahead and short release only for peaks that goes thru the first one…

:v:

1 Like

This is exactly what was happening in my setup, and I mostly solved it by reducing the gain of individual modules as well as the last module in each chain as @electrafa suggested.

Would it be better/easier if I were adjusting the gain on the chains to prevent the compressor from going into effect?

For my purposes I would find it valuable if the master compressor could be disabled in the interface. I’d actually rather hear the clipping, know there is a problem, and then solve it by adjusting the levels rather than allow the compressor to activate.

For now it seems like every single issue I run into with Orac there’s a solution, which blows my mind! Perhaps I’ll disable the compressor in mother.pd or try @oweno’s mod, or focus on gain staging to prevent the compressor from activation. So many possibilities!

EDIT: I have disconnected the compressor in mother.pd and after a bit of adjusting the gain stages on chains and individual module slots I have things pretty well under control. One way I’m managing this is by reducing the range of values sent from my controller, and watching a scope on P2. Thanks for all the feedback!

3 Likes

Interesting,
I’m getting the feeling when things are simple, the compressor produces nice results, but when it gets a bit more complex it can get in the way.
So seems like bringing it under some control, including a bypass, is the way forward.
( default behavior as-is so existing presets sound the same)

1 Like

I found a pretty simple solution for this topic, in fact we just need to move the limiter post-volknob so it will only be active if the volume knob is set to max (only to prevent the dac to clip), this way there shouldn’t be compression applied it most of the cases. i will send you @thetechnobear a copy of your Orac 2.0 mother.pd for you to check and try this soon :slight_smile:

1 Like

This is the way it is now on the standard mother.pd on the Organelle M…although the ‘limiter’ is just a -1,1 clipper.

That is why I like the new mother.pd, no settings, no need for visual indication you are hitting the ceiling, you just hear it and turn the volume down. And patches should be designed to never output 0dbFS anyway… but admittedly more complicated for Orac where a user can easily string things together and hit the limit, so maybe a softer clipping limiter would be more appropriate for Orac’s mother.pd.

3 Likes

I have the M but i don’t have this setup, is this included in the OS 3.2 if i re-install it today ? i’d like to make my mother.pd mods from the very last mother.pd that you release (even if i guess this was the only change you made to it)

I think i have to apologize to everyone, i should stop assuming in the name of all, so i’d like to correct my statement and say : i personally prefer to have a visual feedback of peaks than having to hear audio clipping (some tiny peaks can’t be heared while it can be easily monitored with the eye) but i won’t be sad about that if you all leave your mother.pd as they are actually, i’ll keep on trying making this for my mods :wink: .

1 Like

hmm, this is what mine looks like (there haven’t been any updates on M, so this should be the one it ships with):

Is this what you have?

That is a good point…always good to have some visual, and I think the VU meters could be improved a little around this idea too… like a peak bar at the end that remains sticky for a few seconds any time it is hit.

2 Likes

sorry for being a bit off topic, thanks @oweno , i have this one since the beginning i think (i re-installed my system last month with the 3.2 .iso from C&G) EDIT : it is the same in /home/music/fw_dir as in /home/music/Organelle_OS/fw_dir :

If that’s the only thing that changed since i can keep mine for mods.

oh yes :slight_smile: i’m 100% for this!! :fist: