Voxengo Premium Membership - All Voxengo Plugins For a Fixed One-Time Fee
Forums     Plugins     Marquis Compressor Program-Dependent Release Contour

This topic was created before release of the latest product version, and it may contain details irrelevant to this version.  Replying is disabled for this topic.

bmanic: So, a setting of 10,0.1,10 makes the drums pump a bit weirdly as the first part of the release is quite fast, and then suddenly in the middle of the release it slows down a lot (''pumps'') and then again suddenly continues on it's fast release.

Thanks bmanic - that is essential information and very telling concerning the param controls themselves.  I just didn't pick that up earlier!!!


Inverse phase test with different knob configurations.  See above post for further explanations.

***********************************************************************************************

Settings - length (ms 0 = sample start) - dB (peak)

001vs010 - 0/277/1480 - -54.19

001vs100 - 0/260/1480 - -48.35

001vs010 - 0/270/1480 - -54.19

011vs101 - 0/240/1140 - -46.23

011vs110 - 0/270/1100 - -69.48 (0.05db signal in 16bit!)

101vs110 - 0/240/1140 - -45.7

For some reason all phase inversion comparisons came out with a 0.4dB pan to the right.  Is this

another well kept secret of Marquis?

Nonetheless.  The numbers don't lie.

***

Once again i rest my case.


I noticed that too Dabuek - I just put the stereo field whereever I like using C_SuperStereo when I'm done.  Lot's of things shift some of the stereo field - I can't say Marquis does it more or less than any others but it does it.

Marquis does make the stereo field a bit smaller I think.  At least some of the stuff I've compressed seemed smaller but I didn't notice a shift to either side.  I usually compensate the stereo loss (very rarely an issue) with the MSED plugin.

Cheers!

bManic


By the way, the 'Clean' coloration mode should not 'shrink' the stereo field in the same way as the 'Soft' and 'Sharp' modes do it.

In fact, this stereo field adjustment was an intentional thing.  I believe this feature added a lot to the first impression you had with this compressor.  This is not a stereo field shrinking - it is 'adjustment' hard do describe (it has nothing to do with Mid/Side techniques or anything else).

It's just an effect of using valve circuitry.  Valves are generally not equal - there are differences between valves.  And so, output on L and R channels is different even if the input is the same.  If you substract L from R you'll get some residual signal.

bmanic, you've sent me a drum loop sample processed by some vintage analog prototype compressor a while ago - I think it demonstates this 'effect' well.

I would not describe that as a 'bad' effect.

On the PDRC param issue we are having here I wanted to add one more thing.  To describe these params even deeper I'll have to reveal program-dependent algorithm in full detail (where Params are used and why).  Of course, I would not want to do that.


I agree, I never said it is bad. :) I personally like compressors that are not 100% stereo 'tight'.  Like with Elephant, I always use a stereo link setting around 50 to 80% as I like the slight movement.

It does seem like most vintage compressors or any analogue compressors for that matter, touch the stereo information a bit (usually making it more compact).  The only analogue compressor that I heard doing the exact opposite was the Millenia TCL-2 switchable tube/jfet compressor which actually widened and enlivened the stereo field but I suspect this is created intentionally within the circuit (it was a rather nice effect).

Aleksey, is it possible to implement user selectable stereo linking somehow?  Also, another idea: how would the compressor sound if you added that "linear phase option for important internal components", like you did with warmifier.

These are just wild ideas, nothing more, so take em as such. :)

Cheers!

bManic


This is an answer that I think I can respect.

As a side note, I had the following suggestion on another forum. (Or feature idea if you want to call it that):

Personally, I would prefer a release contour with control points.  Sort of like the way most EQ's do it.  Three points on the curve that you could place, and vary the sloping function (curve) of each control point with one of those three knobs.  Then you could contour the curve and actually see what you were doing to the release over time.  Then I believe not too many explanations would be needed.

Aleksey Vaneev: On the PDRC param issue we are having here I wanted to add one more thing.  To describe these params even deeper I'll have to reveal program-dependent algorithm in full detail (where Params are used and why).  Of course, I would not want to do that.


bmanic, I do not plan to implement selectable stereo-linking due to high CPU loads.

Elvenking, it's not possible to 'draw' release contour - it can only go down with different slopes.  So, there's no logical way to place any control points on that screen.


Aleksey Vaneev: Elvenking, it's not possible to 'draw' release contour - it can only go down with different slopes.

That says to me that the current PDRC graph is more like an upside down meter with its' needle pointing down.  When the curve swings to the left there is less program dependence - to the right more program dependence.  The graph does not depict time nor is it dynamic but like a static indicator type meter or guage.  Is all that correct?


With what I was thinking, I wasn't even refering to his graph. (In all seriousness, I do not know what his graph represents.  I assumed that the x-axis was time.)

With my idea, I was thinking that x-axis would be time, and y-axis would be gain reduction.  Of course during release, we are moving to 0db of gain reduction. (As the far right of the graph would always represent the end of the release time.  To me, there is no reason to vary that time anywhere else other than the "release" control.) So at the extreme right of the graph, we would be locked at 0-db.  The three control points would have control over slopes in the middle of the curve.  For example, if the max GR happened to be -9db, you could release the first 3db fast, then slow down for the next 3db, and finally release the last 3db fast again.  So if your overall release time was 500ms, it would take 100ms for the first stage, 300 for the second, and another 100ms for the final.  Makes sense to me in theory.  Whether its possible or not, who knows.  Just sounded like a cool idea to me.

Aleksey Vaneev: Elvenking, it's not possible to 'draw' release contour - it can only go down with different slopes.

kylen: That says to me that the current PDRC graph is more like an upside down meter with its' needle pointing down.  When the curve swings to the left there is less program dependence - to the right more program dependence.  The graph does not depict time nor is it dynamic but like a static indicator type meter or guage.  Is all that correct?

This topic was created before release of the latest product version, and it may contain details irrelevant to this version.  Replying is disabled for this topic.