Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 11-02-2012, 05:29 PM   #81
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

Quote:
Originally Posted by Tom Drinkwater View Post
if you make the attack and release times short relative to the pulse time and the precomp time you will see that there are 2 separate attacks and 2 separate releases, it is NOT just that the first attack hasn't finished when the pulse starts and so continues. this is consistent with the 2 separate "compression cycles" visible when the precomp time is longer than the pulse.
Look at Cases 2, 3, and 4 in the screenshots in my post yesterday. Case 3 the is situation you postulate.

Specifically, look at the leading edges of the pulse. Cases 2 and 4 show the initiation of compression at the leading edge -- note the high starting level. Now look at the leading edge of the pulse in Case 3. It is clearly well into the compression envelope at that point, otherwise the leading edge of the pulse would be at the same level as the leading edges in Cases 2 and 4. This occurs because a release condition was not reached by the time the pulse started. So it continued the compression envelope already in process. As noted by you earlier, once compression starts, it continues until a release condition is seen.

The Case 3 example is a little confusing because the release would have occured at the exact same time the pulse started. But because the pulse occurred, the release condition never occurred. If you ran the same case with Pre-Comp set to 200 ms instead of 250 ms (the pulse width), I think any confusion would disappear.
Baer is offline   Reply With Quote
Old 11-02-2012, 05:32 PM   #82
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

Quote:
Originally Posted by Baer View Post
To me it makes lots of sense. Without it, if you were using Pre-Comp, you may see an extreme spike which will go uncompressed because the offset location requires no compression.
That is exactly what i would expect to see , unless there is a hold function. There could be a release delay or hold function equal to the precomp time, and under some conditions reacomp does actually look like that's what it does.
Tom Drinkwater is offline   Reply With Quote
Old 11-02-2012, 05:35 PM   #83
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

Quote:
Originally Posted by Baer View Post
Look at Cases 2, 3, and 4 in the screenshots in my post yesterday. Case 3 the is situation you postulate.

Specifically, look at the leading edges of the pulse. Cases 2 and 4 show the initiation of compression at the leading edge -- note the high starting level. Now look at the leading edge of the pulse in Case 3. It is clearly well into the compression envelope at that point, otherwise the leading edge of the pulse would be at the same level as the leading edges in Cases 2 and 4. This occurs because a release condition was not reached by the time the pulse started. So it continued the compression envelope already in process. As noted by you earlier, once compression starts, it continues until a release condition is seen.

The Case 3 example is a little confusing because the release would have occured at the exact same time the pulse started. But because the pulse occurred, the release condition never occurred. If you ran the same case with Pre-Comp set to 200 ms instead of 250 ms (the pulse width), I think any confusion would disappear.
if you start from your case 3 and shorten the attack time you'll see that I'm right and there are 2 separate attacks with no release between them, just a period of static compression. i posted a pic on my earlier post about this.
Tom Drinkwater is offline   Reply With Quote
Old 11-02-2012, 05:47 PM   #84
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

Quote:
Originally Posted by karbomusic View Post
Hopefully we are now realizing why many compressors' labeling tends to be "more/less/faster/slower" to begin with. As I hinted before, its musical content, trying to calculate what one expects to hear instead of just moving the slider until it sounds correct will quickly spiral into confusion and wasted time. And even if it all did match, it still takes a back seat to how it sounds. It matters no more than looking at a FFT graph to confirm if a mix sounds good.
I have used reacomp and many other plugins for years in the trial and error way you suggest, and it works fine as long as you are trying to achieve a certain class of outcomes such as musical effects and subjective loudness control, but one day when i wanted a specific technical result, it started to notice that the numbers didn't actually correlate to the behaviour i expected and the more i investigated the more confusing it got.

i have a very clear musical idea of how long a millisecond is. It is the time it takes a sound to travel one foot in air or one cycle of a 1k midrange frequency. If something on my screen is specified in ms i expect to hear results that correspond in some obvious way.... if it doesn't it wastes more time while i start doubting my senses.

EDIT to be clear - It is because no setting I could find sounded correct that i started investigating in a more technical way.
Tom Drinkwater is offline   Reply With Quote
Old 11-02-2012, 06:03 PM   #85
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
EDIT to be clear - It is because no setting I could find sounded correct that i started investigating in a more technical way.
Well that's good to know then.

Quote:
i have a very clear musical idea of how long a millisecond is. It is the time it takes a sound to travel one foot in air or one cycle of a 1k midrange frequency.
I'd probably propose that isn't a "musical idea" of how long a millisecond is, its a mathematical one. However, its just an observation and I'm fully onboard with your investigation. Take care and I'll stop butting in on you guys.
karbomusic is offline   Reply With Quote
Old 11-02-2012, 06:08 PM   #86
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

Quote:
Originally Posted by Tom Drinkwater View Post
if you start from your case 3 and shorten the attack time you'll see that I'm right and there are 2 separate attacks with no release between them. i posted a pic on my earlier post about this.
When I take Case 3 and shorten the Attack from 250 ms to 200 ms, I get nearly identical results. The only difference is the initial reduction rate is slightly quicker and the leading edge of the pulse is slightly lower, as one would expect. If I take the Attack down to 50 ms, same result only more exagerated.

But I'm glad you reposted one of you early screenshots. There is something there that makes no sense, and I believe it is related to some of what you are saying.

The Pre-Comp based compression behavior during the initial low level section makes sense. But the higher level mid-scetion starts with a slightly decreasing trend, levels out, and then SLIGHTLY RISES AGAIN to the end of the mid-section where the level drops and the release begins.

On close inspection, your compressed signal is exactly what I would expect to see if you had two instances of ReaComp on that track -- one with Pre-Comp set and one without. The slight decrease at the start of the mid-section is the second (non-Pre-comp) compressor kicking in. The slight increase later in the mid-section is the first (with Pre-Comp) compressor ending.

Are you sure you didn't have two ReaComp instances on that track?

Can you post the Project and related files?
Baer is offline   Reply With Quote
Old 11-03-2012, 04:16 AM   #87
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

sorry i forgot in my last post that it doesn't do the double attack and release on a DC pulse, nor does it do it with a rms value set.

for it to happen rms must be very low or 0 and the signal must be a wave not DC

yes it looks exactly like 2 instances of reacomp. but then in a way so does the situation where it completes an attack and release early by the preacomp time and then does it again at the actual time.

I'm sure there weren't 2 instances of reacomp. it has happened consistently on many tests on different computers and sessions, it is the main thing that is really hard to understand that we are discussing in this thread.

we've come full circle, this double attack and release is the weirdest behaviour from my earliest posts, and it is what i tried to explain in my long posts.

i will try to post a session later today, i'll need to make a simpler session containing only that example as the one i've been using is cluttered with many tests. it is easy enough to reproduce though, and the settings are in the picture.
Tom Drinkwater is offline   Reply With Quote
Old 11-03-2012, 04:27 AM   #88
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

to clarify - that wasn't a repost of my early screenshot, it is a new test with a new test signal, showing the same phenomenon.
Tom Drinkwater is offline   Reply With Quote
Old 11-03-2012, 04:40 AM   #89
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

Quote:
Originally Posted by karbomusic View Post
Well that's good to know then.



I'd probably propose that isn't a "musical idea" of how long a millisecond is, its a mathematical one. However, its just an observation and I'm fully onboard with your investigation. Take care and I'll stop butting in on you guys.
it is a physical idea of what a millisecond means in the real physical world that music inhabits.

if i'm 10 feet from the the fiddler i will hear them after 10ms - that's musically useful knowledge.

if i have 2 mics on a source and one is 10feet further from the source than the other i know to expect 10ms delay between the mics, if i see something else i know something is wrong, that's also musically useful knowledge.

i like to cross check my senses with my knowledge of reality as often as possible, it is too easy to fool myself otherwise.
Tom Drinkwater is offline   Reply With Quote
Old 11-03-2012, 04:43 AM   #90
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

here's my test session corresponding to the pic i posted showing the double attack and release

http://www.tomdrinkwater.com/forumpics/reacomptest.zip
Tom Drinkwater is offline   Reply With Quote
Old 11-03-2012, 12:03 PM   #91
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

Tom, I think I understand what’s happening.

First, a couple things I noticed about your files. Using Sony Sound Forge I checked the low and high levels of your input signal – low was peaking at -15.6db and high was peaking at -5.4db. Your threshold was -14.9db, so it appeared compression should be starting based on the step increase in the mid-section.

When I opened your Reaper project, the header label on your input file was the following.

[+3.80db] Take 1/2: test2 level short

Also, when watching the ReaComp screen during playback of the project, compression started at the start of your file, about 1.1db of compression during the low level sections and 10.5db of compression during the mid-section.

Apparently somewhere in the process you had done some Item Processing on your source file item and raised the level of the entire item by 3.8db so it was actually running at higher levels and compressing constantly. And when rendering the processed file, there were small blips at the beginning and end of the where a small amount of compression level was kicking in and releasing much like what was happening on the mid-section. Turns out to be a bit irrelevant. I changed the threshold so that compression occurred only due to the mid-section, and the basic issue is still there. And it still disappeared when RMS was changed from 0 to 1.

But I think this goes back to the Rules 2 and 3 in which ReaComp first determines if compression is required because of Pre-Comp conditions and, if not, determines if compression is required because of the conditions at the current sample.

For sure, what you refer to as the “first release” during the second half of the mid-section is due to compression triggered through Pre-Comp settings giving way to compression based on current conditions. Phasing issues related to interactions of Pre-Comp size and the constant attack/release going on with wave-based signals result in a slightly different compression level during Pre-comp compression than with current sample compression. This difference creates the “bump”. Using 192khz sampling rates to minimize this phasing and varying Re-Comp intervals, I was able to noticeably lower the bump. And there was no bump when using a nice clean combination like a 5khz input signal with a 250ms for Pre-Comp.

I still see issues with that explanation, but it’s the best one I have. And I’ve already spent way too much time on what is just an academic exercise, so I’m bowing out at this point.

Time to go make music instead.
Baer is offline   Reply With Quote
Old 11-03-2012, 02:49 PM   #92
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

thanks for all your input!

your explanation is along the same lines as I was thinking in my long explanation. I was assuming that attack was tracking the future wave and release was tracking the current wave , and i think we've now shown that both could be tracking either depending on conditions, but the interaction with the pumping of the comp on every cycle has to be part of the cause.

I think we've proved that reacomp does monitor and react to both the future and current signal in precomp mode, which i would never have guessed.

I'd really love the developers to step in and say what really happens / what they were trying to achieve / what the exact rules are for deciding when to compress based on the future signal and when based on the present signal. oh and what the formula for attack and release time is..

for myself, i think i've established that i don't trust recomp in precomp mode and will avoid using it with precomp in future, or at least keep well within the settings that I now know to have predictable/useful results.

the search continues for a compressor I can set in ways that seem obvious to me....
Tom Drinkwater is offline   Reply With Quote
Old 11-04-2012, 01:35 PM   #93
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

Quote:
Originally Posted by Tom Drinkwater View Post
the search continues for a compressor I can set in ways that seem obvious to me....
I hope you find it.

I woke up this morning realizing there was a quick way to run a lot a test cases quicky and easily. And with the extra hour from ending Daylight Savings Time, I did so. It confirmed that what you were seeing is completely due to the phase differences between the Pre-Comp application and look-ahead points. Here's a summary.

https://stash.reaper.fm/14498/ReaComp...%20Summary.jpg


If it's too small to read when you open it, there should be a zoom control in the lower right corner of your window (or available somewhere in your browser).

Last edited by Baer; 11-04-2012 at 02:01 PM.
Baer is offline   Reply With Quote
Old 11-04-2012, 03:49 PM   #94
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

brilliant! great clear explanation! next time i have some time I will also check this and work through the reasoning, but it seems quite clear now we've worked through so many examples.

now that we understand it (I think) the 2 changes that would make reacomp with lookahead more useful and predictable for me, would be:

* a hold function so that 0rms can be used to detect peaks but the compressor can be prevented from tracking the waveform.

* have the lookahead respond only to the lookahead signal, not the current signal as well, or, make the behaviour switchable between the current behaviour and lookahead only.


there's a bunch of other features I'd also love to see but they are much less important. I might start a FR thread on that once I've thought a bit more about it, and played some more with DMG Compassion, which has many many features, but I find the interface less than ideal.

I don't yet understand exactly when reacomp responds to the current signal and when it uses the future signal, I'll have to think some more about that. Does it always use whichever would result in greater compression?
Tom Drinkwater is offline   Reply With Quote
Old 11-04-2012, 03:53 PM   #95
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

to nitpick a little... i hesitate because it's great work, but that explanation page could be even better.

you haven't explicitly explained the attack visible at the beginning of section C. If it was simply the precomp compression continuing I wouldn't expect to see an attack curve there. I think there is some interaction with the current signal going on at that point too.

your diagrams also don't show the release based on current levels between sections D and E
Tom Drinkwater is offline   Reply With Quote
Old 11-04-2012, 06:43 PM   #96
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

Quote:
Originally Posted by Tom Drinkwater View Post
* have the lookahead respond only to the lookahead signal, not the current signal as well, or, make the behaviour switchable between the current behaviour and lookahead only.

I don't yet understand exactly when reacomp responds to the current signal and when it uses the future signal, I'll have to think some more about that. Does it always use whichever would result in greater compression?
If compression (call it Comp-A) is in process, regardless if from current or Pre-Comp conditions, it will continue until it reaches a release condition at which point its release begins. As soon as it hits that release point, it also begins to check the current signal as well as the look-ahead signal for a new compression trigger. When it finds one, it starts the compression envelope from whatever state it's at. And if it finds one at the first sample of the release (e.g., Pre-Comp says release, but current conditions says compress), compression takes precedence and it continues Comp-A.

What's interesting about the example is the bump on the latter part of the mid-section. The leading edge of the bump is the start of the compression envelope due to the CURRENT conditions. It is a compressor going from a lower level to a higher level, hence the "inverted envelope".

Regarding your suggestions, the second one would absolutely have to be switchable with the current design as the default. With your change, there would be many situations like Section D of the example in the Summary where compression is needed because of current conditions but would not be applied if checked only by the Pre-Comp conditions.
Baer is offline   Reply With Quote
Old 11-04-2012, 07:17 PM   #97
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

Quote:
Originally Posted by Tom Drinkwater View Post
to nitpick a little... i hesitate because it's great work, but that explanation page could be even better.

you haven't explicitly explained the attack visible at the beginning of section C. If it was simply the precomp compression continuing I wouldn't expect to see an attack curve there. I think there is some interaction with the current signal going on at that point too.
It's due to the initial Pre-Comp compression.

I do not know what the compression equation is, but it must be some manipulation of logarithmic, db, and linear parameters. For sake of understanding, let's pretend the vertical db scale of the graph is a linear scale where the left and right lower sections of the input signal are at a value of 5 while the mid-section is at a value of 8.

At the start of Section C, compression has reached a steady state of some amount of compression which is based on the B level. For the sake of understanding, call it 20%. Section A is at 5 and so B was driven down 20% to 4. That's a drop of 1. Section C starts and is dropped by 1, from 8 to 7. But the compressor recognizes that 20% of 8 is 1.6, so it has to start compressing further, from 7.0 down to 6.4.


Quote:
Originally Posted by Tom Drinkwater View Post
your diagrams also don't show the release based on current levels between sections D and E
It's there, but it was short and only barely visible on the last couple examples. It's visible on the last couple if you zoom in on the graphic to about 400% of what initially shows up. (... and maybe use a magnifying glass.) The graphic definitely would have been better with a longer release time.

Last edited by Baer; 11-04-2012 at 07:23 PM.
Baer is offline   Reply With Quote
Old 11-04-2012, 09:07 PM   #98
the all new rob
Human being with feelings
 
the all new rob's Avatar
 
Join Date: Dec 2007
Location: east coast of Kansas
Posts: 681
Default

Great thread, it took a very educational turn.

I've done similar tests, but never delved in to the pre-comp realm with it like you guys have. Very engaging.
__________________
"Well feeling (emotion) combined with an artist's discipline is the rarest thing in the world."
-- Ursula Nordstrom
the all new rob is offline   Reply With Quote
Old 11-05-2012, 04:26 AM   #99
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

to clarify what I meant about the hold function and sensing at once place only.

think of the hold function as a release delay.

the normal case with precomp would be to set the hold to the same value as the precomp. (there could even be a button linking them for convenience)

then the release is effectively delayed back to the current position, but the attack attacks ahead of time by the precomp amount. I'm pretty sure this would catch all peaks, avoiding some of the situations we have seen.

This is in fact how I assumed precomp worked before I started thinking about it and looking into it.

you could say that this means the compressor is sensing the signal at both the current and precomp position. I prefer to think of it as sensing ahead and then delaying the release. The key thing is that is is not sensing it twice, it is just delaying the release by the hold amount, so there can never be a double attack or a double release as long as the hold is equal to or larger than precomp.

allowing the hold to be set to shorter values would be great for flexibility, but would allow strange things to happen and peaks to escape, but this might be a useful creative effect, so i would say it should be possible, just not the default.

hold with no precomp would have no such problems, but would allow peak tracking compression without wave tracking with rms=0.
Tom Drinkwater is offline   Reply With Quote
Old 11-05-2012, 04:54 AM   #100
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

Quote:
Originally Posted by Baer View Post

At the start of Section C, compression has reached a steady state of some amount of compression which is based on the B level.
section B should be compressed based on the C input level, not on the B level, that's what precomp is all about.

more precisely I would argue that section B should not just be compressed at the ratio determined by section C - the actual same amount of dB reduction should be applied in advance, so there should be no attack visible at the start of the loud section.

If it needs to react to the louder section C, the time to do it is at the beginning of section B, that is what precomp IS.

for me the whole point of precomp is to move artifacts caused by the compression attack away from the loudness increase that causes them, into a part of the signal where they will be less audible. This doesn't achieve that.

however, the above is just explaining my frustration with this behaviour, not getting at the core of what is happening, because I'm looking at the graphs and the peak level and ignoring the fact that the compressor is pumping every cycle, out of phase with itself.

This effect doesn't happen when rms is engaged and the pumping is prevented, or in your 5000hz example where the precomp and current position are in phase. We know that the relationship between section D and section C levels depends on the phase of the pre and current signals.

I think that the beginning of the attack at section B is actually analogous to section D. I will trail off there while i think some more...
Tom Drinkwater is offline   Reply With Quote
Old 11-05-2012, 05:39 AM   #101
l0calh05t
Human being with feelings
 
l0calh05t's Avatar
 
Join Date: Nov 2008
Location: Darmstadt, Germany
Posts: 673
Default

Just FYI, if you need a compressor with a hold function, my jsComp VST has it.
__________________
Raw data for raw nerves | 1.05946309...
My Blog | My free VST plugins | WDL-OL CMake fork
l0calh05t is offline   Reply With Quote
Old 11-05-2012, 06:26 AM   #102
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

Quote:
Originally Posted by l0calh05t View Post
Just FYI, if you need a compressor with a hold function, my jsComp VST has it.
I'd certainly try it, but it appears to be windows only...
Tom Drinkwater is offline   Reply With Quote
Old 11-05-2012, 06:47 AM   #103
l0calh05t
Human being with feelings
 
l0calh05t's Avatar
 
Join Date: Nov 2008
Location: Darmstadt, Germany
Posts: 673
Default

Quote:
Originally Posted by Tom Drinkwater View Post
I'd certainly try it, but it appears to be windows only...
It is. Send me a Mac and you'll have a Mac version in a few weeks
__________________
Raw data for raw nerves | 1.05946309...
My Blog | My free VST plugins | WDL-OL CMake fork
l0calh05t is offline   Reply With Quote
Old 11-05-2012, 07:00 AM   #104
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

Quote:
Originally Posted by l0calh05t View Post
It is. Send me a Mac and you'll have a Mac version in a few weeks
osx will run on generic hardware with a modest bit of hacking.

Not sure i'd actually buy another apple product now as their attempts to control their customers get ever more extreme.

I'm quite fed up with apple and looking for alternatives, but i've been a mac user since 88 and it's a big change, and the alternatives don't appeal much. anyway we are getting rather OT...

does your compressor also have a precomp function? EDIT actually - feel free to PM or email me but we should probably keep this thread clear for discussion of the behaviour of reacomp.
Tom Drinkwater is offline   Reply With Quote
Old 11-05-2012, 08:24 AM   #105
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

Quote:
Originally Posted by Tom Drinkwater View Post
section B should be compressed based on the C input level, not on the B level, that's what precomp is all about.
It is using C to determine the amount. Using the pretend numbers above, the 20% comes from the conditions in C and D (the stepped up level) and that 20% is used for all compression in the example. ReaComp applies that 20% at the onset of compression in the beginning of B by gradually (over the attack) increasing the compression from 0 to 1. The gradual application over the attack period avoids abrupt drops which would be unmusical in the real world. When it reaches C ReaComp is still applying the 20% and it recognizes at the onset of C that 20% of 8 is now 1.6. But it won't abruptly increase the compression from -1 to -1.6 because that would be a step drop in volume (very unmusical), it will use the attack parameter to ease into it.

Recognize that these test conditions are nothing like what one would use in the real world. They were used simply to help understand how the function works.
Baer is offline   Reply With Quote
Old 11-05-2012, 11:43 AM   #106
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

Quote:
Originally Posted by Baer View Post
It is using C to determine the amount. Using the pretend numbers above, the 20% comes from the conditions in C and D (the stepped up level) and that 20% is used for all compression in the example. ReaComp applies that 20% at the onset of compression in the beginning of B by gradually (over the attack) increasing the compression from 0 to 1. The gradual application over the attack period avoids abrupt drops which would be unmusical in the real world. When it reaches C ReaComp is still applying the 20% and it recognizes at the onset of C that 20% of 8 is now 1.6. But it won't abruptly increase the compression from -1 to -1.6 because that would be a step drop in volume (very unmusical), it will use the attack parameter to ease into it.
No I think this is wrong. remember that the attack at the beginning of C does not occur with rms engaged. I think it is caused by the comp getting confused about the correct level of compression to apply because of phasing. Or more accurately it is not applying a steady level at all but pumping on every cycle and the peak levels we see are actually incidental to that.

In a normal precomp situation, if there is 3dB gain reduction in section B there should be 3dB gain reduction in section C too, no transition is necessary or desirable (and the fact that 3dB is actually a proportion is irrelevant), but reacting to both present and future signals while pumping on every cycle creates a more complex situation.

at the start of C before it settles and in D it is reacting to out of phase precomp signal at a different level to the out of phase precomp signal it is reacting to in C, so it creates a different peak level.

the level in C is determined by 2 high level signals interacting out of phase the level in D and at the beginning of C is caused by the same phase relationship, but one signal is high and one is low, but in the case of the attack at the start of C it is attacking up from low, it is analogous to the attack attthe start of D
Tom Drinkwater is offline   Reply With Quote
Old 11-05-2012, 01:25 PM   #107
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

Quote:
Originally Posted by Tom Drinkwater View Post
No I think this is wrong. remember that the attack at the beginning of C does not occur with rms engaged. I think it is caused by the comp getting confused about the correct level of compression to apply because of phasing. Or more accurately it is not applying a steady level at all but pumping on every cycle and the peak levels we see are actually incidental to that.

In a normal precomp situation, if there is 3dB gain reduction in section B there should be 3dB gain reduction in section C too, no transition is necessary or desirable (and the fact that 3dB is actually a proportion is irrelevant), but reacting to both present and future signals while pumping on every cycle creates a more complex situation.

at the start of C before it settles and in D it is reacting to out of phase precomp signal at a different level to the out of phase precomp signal it is reacting to in C, so it creates a different peak level.

the level in C is determined by 2 high level signals interacting out of phase the level in D and at the beginning of C is caused by the same phase relationship, but one signal is high and one is low, but in the case of the attack at the start of C it is attacking up from low, it is analogous to the attack attthe start of D
Without knowing the design, we'll never know. But from all the testing I've done, I am quite sure that there is only one compressor acting at any point in time and that it is getting its input from either the Pre-Comp condition or the current condition, not both. And everything I see supports my conclusion.

The compressor does not get confused. It has a hardcoded set of rules it uses to determine which conditions it is responding to. If I have time, I'll put together a flowchart of what I (strongly) believe is going on.

I don't think the compression rate is straight db reduction as in your -3db example. I believe it is more complicated and results in some db reduction as a result of the compression rate and the current condition. I don't know this, and I could be wrong.

Yes, it is "pumping" with every cycle, but it does reach steady states of pumping leading to a repeated, cyclic waves. But it is not reacting to present and future conditions concurrently. It picks whichever creates a compression condition first, and it sticks with that one until it sees a release condition.

One millisecond represent five full cycles of a 5000 hz sinewave. When RMS is engaged even at a value of 1 ms, the whole scheme changes. Phase issues disappear, and the controlling signal is a constant at the high level and a different constant at the low level. BTW, the compressed levels in D are different (-6.99db vs -6.34ddb) with RMS=1 than with RMS=0 reflecting the difference in the controlling levels relative to the threshold.

Attack is not from low to high or high to low. Attack is from the current level to the target fully compressed level. At the start of C, the level is higher than the target, so the attack is from the higher level to the lower target.
Baer is offline   Reply With Quote
Old 11-05-2012, 04:21 PM   #108
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

Here is how I believe ReaComp is performing its decisions about compression attack and release.






Note also that this says nothing about the actual calculation of compression rates. Without input from the Cockos folks or someone in the know, I think we've exhausted that subject.
Baer is offline   Reply With Quote
Old 11-05-2012, 05:10 PM   #109
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

Quote:
Originally Posted by Baer View Post
I am quite sure that there is only one compressor acting at any point in time and that it is getting its input from either the Pre-Comp condition or the current condition, not both.
yes, I never meant otherwise, interacting doesn't imply that both are active at once, just that they both have an effect on the visible peak level for any given peak.

The detector circuit/algorithm could well be (and i believe must be) switching between reacting to current and future position on every cycle, when phasing between future and current waves is affecting the peak level we see.

Quote:
Originally Posted by Baer View Post
The compressor does not get confused. It has a hardcoded set of rules it uses to determine which conditions it is responding to.
I know, that's why I continued with "more accurately".

Quote:
Originally Posted by Baer View Post
I don't think the compression rate is straight db reduction as in your -3db example. I believe it is more complicated and results in some db reduction as a result of the compression rate and the current condition. I don't know this, and I could be wrong.
I think you are using rate to mean ratio - in the version of english I speak they mean quite different things, but that's fine, as long as we are clear about what is meant.

I'm not entirely sure what you mean by the rest of the statement.

I wasn't talking about compression ratio I was referencing the actual gain reduction applied. This should be, and is, static between sections B and C when rms>half cycle.

When rms=0 the gain reduction pumps - but there is still a visible peak gain reduction amount, which is not the same thing at all, though it looks the same, and is subject to all the complex behaviour we are trying to unpick. This visible peak gain reduction amount is different between sections B and C, (I explain why below) which creates an attack curve, or more accurately a series of partial attack curves on each loud side of the pumping cycle....

Quote:
Originally Posted by Baer View Post
Yes, it is "pumping" with every cycle, but it does reach steady states of pumping leading to a repeated, cyclic waves. But it is not reacting to present and future conditions concurrently. It picks whichever creates a compression condition first, and it sticks with that one until it sees a release condition.
I agree with all that, but if the pumping leads to it switching between current and future monitoring on every cycle, (which it MUST do or the phasing would not affect the peak level), then the peak level we see on the graph will be affected by both present and future conditions.

Remember the attack and release times are smoothing the pumping so the compressor may reach equilibrium without fully attacking or releasing, and the point at which the attack or release start from is likely to be the same point that the control wave switches from current to future or vice versa, so both current and future waves affect the changeover point and thus affect the attack or release start point and so affect the peak level the wave reaches. This is the only way that we can explain the level changing when rms=0 and being steady when it is non 0.


Quote:
Originally Posted by Baer View Post
One millisecond represent five full cycles of a 5000 hz sinewave. When RMS is engaged even at a value of 1 ms, the whole scheme changes. Phase issues disappear, and the controlling signal is a constant at the high level and a different constant at the low level. BTW, the compressed levels in D are different (-6.99db vs -6.34ddb) with RMS=1 than with RMS=0 reflecting the difference in the controlling levels relative to the threshold.
Note that the control level in this situation (rms=>1) is static from section B to section C so no attack occurs at the start of section C.

I totally agree with all of that paragragh except some aspects of the last phrase. The controlling level is fluctuating in a way caused by the switching between the current and future input waves, which is affected by the phasing between them and the result smoothed somewhat by the attack and release times, the affect of all that on the apparent peak level is certainly deterministic, but is not obvious or easy to visualise.


Quote:
Originally Posted by Baer View Post
Attack is not from low to high or high to low. Attack is from the current level to the target fully compressed level. At the start of C, the level is higher than the target, so the attack is from the higher level to the lower target.
This bit I find misleading. The target is moving constantly, as I mentioned above, so there is no static target level. The phase relationship between current and future wave should be the same in section B and section C (and throughout each individual test), what is different between B and C is the level of the current wave (the level of the future wave is the same for sections B and C). The static level in the middle of any of the sections is an equilibrium arrived at through the rapid switching between attack and release and between monitoring the current and future waves.

The attack and release at the start and end of section C result from changes in the pumping/switching caused by changes in the level relationship between the current and future waves.

This will affect where attack and release conditions apply in each cycle and therefore affect the switching between current and future wave as well as attack release switching and so will affect the peak level we see. So although the compressor is only reacting to either current or future wave at any instant/sample, the levels of every peak on every cycle (which is what is most visible in the graphs) are influenced by both.

It is basically the same explanation I made in my long posts much earlier in the thread, the difference being that I thought the attack always followed the future wave and the release always followed the current wave, and we now know thanks to your experiments with DC pulses that the rules are not what I initially thought, it is something more like it attacks if either current or future wave have an attack condition and only releases if both have a release condition. Either way it must be switching between current and future wave on every cycle or the phase between them could not be affecting the visible peak level equilibrium that it arrives at.
Tom Drinkwater is offline   Reply With Quote
Old 11-05-2012, 05:41 PM   #110
Tom Drinkwater
Human being with feelings
 
Join Date: Apr 2008
Posts: 262
Default

I think, based on a quick look, that I agree with your logic chart. It doesn't contradict any of my theories, but it may possibly be more complex than it need be.

I'm not sure if there is any difference between 'continue attack' and 'initiate attack' - same for release. Whether there is would depend on the types of curves used for attack and release envelopes, but assuming them to be simple linear or geometric curves, then the compressors possible actions for each sample could be simplified to just "attack" or "release" or "continue at current compression ratio".

speed of attack and release may depend on the destination level as well as the specified times?

I would like to suggest that rules (maybe) boil down to:

1. is there a attack condition in either the future or current waves? If so attack.

2. Is there a release condition in both the current and future waves? If so release.

3. If neither of the above apply continue at current compression ratio. (which may be 1:1)

of course neither these rules nor your flow chart define and attack or release condition - but I think that's clear enough.

at risk of sidetracking us a bit I tried to define attack and release conditions as well.

An attack condition is when the control signal is higher than the target level. The target level is the threshold plus the amount of control signal over the threshold divided by the compression ratio.

target level = threshold + ((controlsignal - threshold) / ratio)

of course if there's a knee then the ratio is not constant but the same principle applies.

a release condition is when the control signal is lower than the target level and some compression is still occurring.

a do nothing condition is when the signal is exactly the target level, or it is below threshold and no compression is currently occurring (no release tail)
Tom Drinkwater is offline   Reply With Quote
Old 11-06-2012, 08:08 PM   #111
Baer
Human being with feelings
 
Baer's Avatar
 
Join Date: Sep 2006
Location: San Francisco, CA
Posts: 335
Default

If compression being applied to the current sample is dependent on only the ReaComp parameters and the current sample level (or "current" lookahead sample level), I believe you're right in your simplification. And I think this is probably the case, but I don't know what algorithm is being used. My model allows for some dependence on previous compression amounts in the algorithm.
Baer is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 06:34 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.