envelope follower with hold (AHR)

Nu Audio Science · 25 Mar 2009

Been looking into this myself but i'm not hot with the code like you so i drew a blank I did do a huge serach fo the forum for a couple of days and to be honest there isn't too much to be true Interested to see what you come up with if you end up sharing the OSM at all

Cheers

NAS

aliasant · 26 Mar 2009

Im also a bit interested in this. A hold function would be very cool.

oddson · 26 Mar 2009

Excuse my ignorance... how would that work?

I'm sure it's feasible once someone defines the problem in a precise enough manner.

oddson · 26 Mar 2009

http://www.u-he.com/filterscape/index.p ... #envfollow

A special function is the Env Mode. When this is activated, the envelope follower doesn't work as a normal envelope follower, but as a Attack-Hold-Release envelope. Thus, whenever the input level crosses the threshold, the AHR will be triggered (like a gate), while it will be released when the input level falls below the threshold.

If you mean something like this... it shouldn't be too hard.

Before I try anything, am I on the right track?

aliasant · 26 Mar 2009

oddson wrote: http://www.u-he.com/filterscape/index.php?item=features#envfollow

A special function is the Env Mode. When this is activated, the envelope follower doesn't work as a normal envelope follower, but as a Attack-Hold-Release envelope. Thus, whenever the input level crosses the threshold, the AHR will be triggered (like a gate), while it will be released when the input level falls below the threshold.

If you mean something like this... it shouldn't be too hard.

Before I try anything, am I on the right track?

Maybe. Not sure. The hold function should kick in when the envelope shifts from attack to release / turning downhill so to speak. It should then hold it for as long as wished for and then go to the release or attack stage again depending on the preset stage...

I had to draw it up to see it clearer. Seems to me that the longer hold time the shorter release time?

Maybe ? Im not sure. This is tricky.

oddson · 26 Mar 2009

Well try this...

It should work with any envelope that accepts a boolean gate.

(Edit - seems to have some problems but it might be enough to show someone the way who wants to spend some time on it. I might have an error in the gate generating code.)

bootsy · 26 Mar 2009

Thanks for your efforts so far. It's not that threshold thing that would be indeed easy: Just cut the fullwave rectified signal at threshold level and then put the ordinary envelope follower behind it. The images by aliasant shows the direction. Don't worry about release length or so, that shouldn't be different algorithm wise. The thing is just that when the env follower would normally flips into the release cycle this is delayed for some time and if that time is over it could even be that (depending on the input signal) the curve gets raised again (and so the release cycle is 'skipped'). In a compressor design this could prevent too much modulation action and that way minimize intermodulation distortion, just to give an idea on a typical application for that. A 'naive' design would be to extend the env follower so that the switch from attack to release cycle can be detected and that triggers a timer for some samples so that the current output value is hold for that time. Is that feasable in the code component? Maybe there is a more efficient and elegant way?

oddson · 26 Mar 2009

I thought you might be looking for something more like modified filtering rather than triggering a standard envelope but the above problem looked easier... 😉

The current code does not actually have an attack and release phase... it merely applies two different smoothing rates depending on whether the absolute value of the current sample is above or below the t-1 value of the output (so it's typically jumping between the two around the zero crossings of the fundamental of the wave with one or the other smoothing rates becoming dominant where the signal changes magnitude).

It would be feasible to instead track the direction of the signal over a longer time - possibly comparing the current (t-1) output with some previous state (t-n) and determining the signal is increasing or diminishing - or by comparing two smoothed (and rectified) signals - or any of an unlimited number of other means of judging whether the signal is growing or shrinking.

Then you could look to using this output as in intermediary input in a second process (whether in 2nd code module or not) where once the downward trend has been determined the final output is held until the intermediary value falls below a second threshold condition.

The thing about issues like this is defining the desired results in technical terms is half the battle.

So are you talking about a strict hold (constant value) for a set time before smoothing during release? Then you would need to define the circumstances where this applies. You'd need a criteria to say the attack phase was over hold the signal for x time and then smooth at the relase rate.

Are you talking about a hold period where the smoothing (inertia) is very high until a release phase is triggered and the smoothing lessens? Then you would need two criteria, one to specific the attack phase has ended and another when the hold should end.

Of course it may be possible to offer a range of behaviour.

bootsy · 26 Mar 2009

oddson wrote: I thought you might be looking for something more like modified filtering rather than triggering a standard envelope but the above problem looked easier... 😉

The current code does not actually have an attack and release phase... it merely applies two different smoothing rates depending on whether the absolute value of the current sample is above or below the t-1 value of the output (so it's typically jumping between the two around the zero crossings of the fundamental of the wave with one or the other smoothing rates becoming dominant where the signal changes magnitude).

It would be feasible to instead track the direction of the signal over a longer time - possibly comparing the current (t-1) output with some previous state (t-n) and determining the signal is increasing or diminishing - or by comparing two smoothed (and rectified) signals - or any of an unlimited number of other means of judging whether the signal is growing or shrinking.

Then you could look to using this output as in intermediary input in a second process (whether in 2nd code module or not) where once the downward trend has been determined the final output is held until the intermediary value falls below a second threshold condition.

The thing about issues like this is defining the desired results in technical terms is half the battle.

So are you talking about a strict hold (constant value) for a set time before smoothing during release? Then you would need to define the circumstances where this applies. You'd need a criteria to say the attack phase was over hold the signal for x time and then smooth at the relase rate.

Are you talking about a hold period where the smoothing (inertia) is very high until a release phase is triggered and the smoothing lessens?

I understand and the last statement about smoothing is the thing. I will think about it to get it more precise articulated. oddson, many thanks for your efforts here! bootsy

Zyxoas · 29 Mar 2009

I tried something like that.

streamin in; streamout out; streamin attack; streamin shold; //number of samples to hold streamin release;

float nin, c, oldenv, env, inatt, inrel, inhrel, ninhrel, held; nin=in*(1-in<0&2); //standard absolute value oldenv=env; inatt=(nin>=env); //in attack phase? inrel=(nin<env); //in release phase? //the next two lines are the standard envelope follower c=release+inatt&(attack-release); env=c*(env-nin)+nin; inhrel=inrel&(held<shold);//release phase and holding? ninhrel=inrel|(held>=shold);//not in held release phase? env=env+inhrel&(oldenv-env): //leave envelope unchanged if we're in the held release phase held=inrel&ninhrel&held+inhrel&(held+1);//if in held release phase then increment held sample count, else if in release but not holding then leave count unchanged, else count is zero out=env;

I don't know if a boolean NOT operator exists in the code component, thus the redundancy. This is probably not the best algorithm, and I'd love it if someone would attempt to optimise it and/or convert it to asm.

It does just what the original porter wanted. If the audio goes below the envelope then the detector holds the current output for a few samples before going into release mode. But if the audio increases above the envelope while it is holding then it just goes back to attack mode. Ie, there's a slight delay before the follower starts releasing after the input drops.

Zyxoas · 29 Mar 2009

Oops. That should be

ninhrel=inatt|(held>=shold);

bootsy · 30 Mar 2009

Zyxoas wrote: I tried something like that.

streamin in; streamout out; streamin attack; streamin shold; //number of samples to hold streamin release;

float nin, c, oldenv, env, inatt, inrel, inhrel, ninhrel, held; nin=in*(1-in<0&2); //standard absolute value oldenv=env; inatt=(nin>=env); //in attack phase? inrel=(nin<env); //in release phase? //the next two lines are the standard envelope follower c=release+inatt&(attack-release); env=c*(env-nin)+nin; inhrel=inrel&(held<shold);//release phase and holding? ninhrel=inrel|(held>=shold);//not in held release phase? env=env+inhrel&(oldenv-env): //leave envelope unchanged if we're in the held release phase held=inrel&ninhrel&held+inhrel&(held+1);//if in held release phase then increment held sample count, else if in release but not holding then leave count unchanged, else count is zero out=env;

I don't know if a boolean NOT operator exists in the code component, thus the redundancy. This is probably not the best algorithm, and I'd love it if someone would attempt to optimise it and/or convert it to asm.

It does just what the original porter wanted. If the audio goes below the envelope then the detector holds the current output for a few samples before going into release mode. But if the audio increases above the envelope while it is holding then it just goes back to attack mode. Ie, there's a slight delay before the follower starts releasing after the input drops.

yeah, thats pretty much what I originally intended and maybe it's actually a good starting point after thinking about it a while.

For [0,1] values you could write not(x)=1-x.

Here is some rewriting for simplification and readability, some lines commented out. I will perform some tests later.

streamin in; streamin attack; streamin release; streamin shold; //number of samples to hold streamout out;

float nin, c, oldenv, env, releasing, holding, held;

nin=in*(1-in<0&2); //standard absolute value

// inatt=(nin>=env); //in attack phase? releasing=(nin<env); //does release occur [0|1]?

// the next two lines are the standard envelope follower c=release+(1-releasing)&(attack-release); env=c*(env-nin)+nin;

holding=releasing&(held<shold); //in hold phase [0|1]? // ninhrel=inatt|(held>=shold); //not in held release phase?

env=env+holding&(oldenv-env); //leave envelope unchanged if we're in hold phase

// if in hold phase then increment held sample count // else if in release but not holding then leave count unchanged // else count is zero held=releasing&(1-holding)&held+holding&(held+1);

out=env; oldenv=env;

bootsy · 31 Mar 2009

Ok folks, we do have a working prototype! And it already works like a charm: 😀 Put this in your compressor instead of a AR envelope follower. Now, if you drive your comp together with very short attack and release it distorts on sensitive audio - just dial in now some samples 'shold' to activate the holdstage and the distortion is gone. 10 samples at 44.1k (which is just around 200 mircosecond) already does wonders. It's already definately more then I've expected and now think further about e.g. adding program dependency to the hold function, relate it to release times, additional smoothing etc. - you get the picture?

Here is the further stripped down code:

streamin in; streamin attack; streamin release; streamin shold; //number of samples to hold streamout out;

float nin, c, oldenv, env, releasing, holding, held;

nin=in*(1-in<0&2); //standard absolute value releasing=(nin<env); //does release occur [0|1]?

c=release+nin>=out&(attack-release); // this two lines are the standard envelope follower env=c*(env-nin)+nin;

holding=releasing&(held<shold); // in hold phase [0|1]? env=env+holding&(oldenv-env); // leave envelope unchanged if we're in hold phase

held=holding&(held+1); // if in hold phase then inc(held) otherwise held=0

out=env; oldenv=env;

If you have more ideas to strip down the code feel free ...

thanks so far! Bootsy

Andrew J · 31 Mar 2009

Damn it! There goes another of my ideas I hadn't gotten around to yet 😠

🙂

oddson · 31 Mar 2009

This is very clever really... I keep thinking there would be problems as the rectified signal crosses the envelope signal but when I think them through the seem to disappear.

For example, the inertia applied to upward trends (attack) will be very different from downward (release) even with the same cut-off coefficients.

On attack, low magnitude input signals near zero crossings are effectively ignored as the output will hold where |x(t)| < y(t-1).

While on decay, samples at peaks will return the signal to hold until the highest peaks remain below envelope output and then there will be n additional samples before release actually begins - but thereafter the release will be quick as the average magnitude of the signal will be well below the output.

So the effect on the attack will be to bolster the output all the way up while on the downward it will delay the release but then allow it to plunge right off.

So output will respond more quickly for both attack and release for any given coeffients than in the standard EF but for different reasons.

aliasant · 1 Apr 2009

Andrew J wrote: Damn it! There goes another of my ideas I hadn't gotten around to yet 😠

🙂

Nono Andrew. This one is far from finished so you can still use your wand here. Dont be afraid now.

aliasant · 1 Apr 2009

OK. I did some testing and Im not sure what your latest EnvFoll is trying to do.

I made a testbed with the original EnvFollower, Zyzosas version with hold and yours. Have a look at this.

I have used different techniques for this in my compressor Inerthia. I call it PDR since it is but it is actually a sort of hold function that is program dependent. Id does its thing by manipulating release times just as you said. But I made that with the regular env foll.

Zyxoas · 1 Apr 2009

Hey guys. Thanks for all your work and interest.

@Bootsy: There's a serious logic error in your stripped-down code. The held count HAS to stay above shold once the envelope follower exits the hold phase to go into full releasing. In your code it holds, releases for one sample, holds again (since held samples count have gone to zero -- below the hold samples), then releases for one sample when held is high enough, then holds again, then...

I don't know what it sounds like (probably removes short-release artifacts, because it basically has an infinite release time, so obviously it will remove the crazy distortion produced by extremely short attack and release), but it's not what the original poster wanted.

Zyxoas · 1 Apr 2009

@aliasant: That schematic rocks! I wish I was that talented with graphics. The oscilloscopes show what's happening better with abs off, in my opinion. It's a brilliant tool.

aliasant · 1 Apr 2009

Zyxoas wrote: @aliasant: That schematic rocks! I wish I was that talented with graphics. The oscilloscopes show what's happening better with abs off, in my opinion. It's a brilliant tool.

Thank you. It is very handy indeed. But you know, I made that Abs just to be able to see signals that range from 0 to 1. Just like the Env Follover. If Abs is off the Oscilloscope will range from -1 to +1 and the envelope will never ( unless something is very wrong) go below 0. Anyways. Enjoy the tool. I use it all the time.

Tom7777 · 1 Apr 2009

EnvTest.osm in SM is 3% only but in taskmanager it's 55-60% the toolbox does not load either until i delete all of the Oscilloscope x 2 modules. Seems they are trigger limited already also and this was in 1.1.3 beta3 if that makes much difference.

aliasant · 1 Apr 2009

Tom7777 wrote: EnvTest.osm in SM is 3% only but in taskmanager it's 55-60% the toolbox does not load either until i delete all of the Oscilloscope x 2 modules. Seems they are trigger limited already also and this was in 1.1.3 beta3 if that makes much difference.

You can pause the oscilloscopes by left clicking inside them. This is caused by SM not handling this very well =( You could also set the oscilloscope to 5/sec or so. That will save your cpu and almost bring it down to nothing.

Hmm. Update:

Seems running only one of the scopes is using about 9% (peaks) If I run both of them it takes about 27% ! !? And if I turn them both of ( by pausing them) it runs at 3%

This is something I have been trying to get Malc to improve but I dont think he has had the time right now with the latest Beta running wild.

Update 2: I think I might have made the Scopes work slightly better. each scope has a trigger input to the "mono Wave Draw Sync 1" Use the trigger after the trig divide instead of the 100 tick. That should make it more efficiant but maybe less accurate. Im not sure. Looks ok to me.

The other day I tested this outside SM. I was watching a Blueray quality movie using VLC and my cpu never passed 3%. I was resizing the video window like crazy to try to make it sweat and then it went up to 23%but it went right back to about 1% when I stopped. So why is SM finding this so hard.... anyways. Lets get back on topic. Any progress?

Ok. I had to do it. Had to change those damned Oscilloscopes. Now they use a little less and they also have an automatic Stabilizer.

Tom7777 · 1 Apr 2009

The new ones are much better, toolbox loads ok now. Thanks 🙂

aliasant · 1 Apr 2009

Tom7777 wrote: The new ones are much better, toolbox loads ok now. Thanks 🙂

Hmmmmm. So this is the cause of the slow toolbox loading problem. I didnt know this. Interesting. Maybe Malc should make something so that an .osm doesnt start working UNTIL the toolbox has completed loading?

bootsy · 1 Apr 2009

Zyxoas wrote: Hey guys. Thanks for all your work and interest.

@Bootsy: There's a serious logic error in your stripped-down code. The held count HAS to stay above shold once the envelope follower exits the hold phase to go into full releasing. In your code it holds, releases for one sample, holds again (since held samples count have gone to zero -- below the hold samples), then releases for one sample when held is high enough, then holds again, then...

I don't know what it sounds like (probably removes short-release artifacts, because it basically has an infinite release time, so obviously it will remove the crazy distortion produced by extremely short attack and release), but it's not what the original poster wanted.

Probably the "else if in release but not holding then leave count unchanged" part I've "optimzed away" in the last version 😊 thinking it was not necessary. Will have a look at it later at home.

Tom7777 · 1 Apr 2009

aliasant wrote: Tom7777 wrote: The new ones are much better, toolbox loads ok now. Thanks 🙂

Hmmmmm. So this is the cause of the slow toolbox loading problem. I didnt know this. Interesting. Maybe Malc should make something so that an .osm doesnt start working UNTIL the toolbox has completed loading?

Well when testing i opened EnvTest.osm and it would not fully load the toolbox as well as having the high cpu. Normally it will show a progress of the modules loading for a short time which is usually faster if you have already run SM. It was fine with the second version you posted and the toolbox loaded ok. I don't think it's the main cause however of the normal slow load problem but it could be a part of it depending on how it works.

I think whats happening with that original example was it will instantly load the process and it seems like the triggers might be getting through somehow or some sort of loop is happening. Possibly from a bug but it seems to stop the toolbox from starting or it goes very slow. I agree the toolbox should load first or the option of the order it works is added in somewhere. 🙂

bootsy · 1 Apr 2009

streamin in; streamin attack; streamin release; streamin shold; //number of samples to hold streamout out;

float nin, c, oldenv, env, releasing, holding, held;

nin=in*(1-in<0&2); //standard absolute value releasing=(nin<env); //does release occur [0|1]?

c=release+nin>=out&(attack-release); // this two lines are the standard envelope follower env=c*(env-nin)+nin;

holding=releasing&(held<shold); // in hold phase [0|1]? env=env+holding&(oldenv-env); // leave envelope unchanged if we're in hold phase

// if in hold phase then inc(held) else if releasing but not holding held=held else held=0 held=releasing&(held>=shold)&held+holding&(held+1);

out=env; oldenv=env;

Check this out!

aliasant · 1 Apr 2009

bootsy wrote:

Check this out!

Lol Bootsy. This one is behaves exactly like the one that Zyxoas made. It does however use 2 cycles less on mine 😉

Zyxoas use 58. Yours 56 🙂

If you put them next to each other you will see that their output is identical.

The lower scope shows both Zyxaos and Bootsys on top of eachother. They are identical. I also draw some in the release. What I think would be nice. If possible.

bootsy · 2 Apr 2009

The redline shows a linear release which does not sound that good in a compressor...

aliasant · 2 Apr 2009

bootsy wrote: The redline shows a linear release which does not sound that good in a compressor...

Wouldnt it sound better then the sudden drop you have now? And if its linear maybe it can be tweaked later on?

bootsy · 2 Apr 2009

I wonder where that drop comes from shouldn't that be a exponential release as well?

Zyxoas · 2 Apr 2009

If you increase the release time the drop will be less "sudden". This is a basic model for an envelope follower, as taught in electrical engineering classes, and almost every dynamics processor uses something similar. So...

aliasant · 4 Apr 2009

I made a new version were the shape of the held release is more interesting, sort of. I had to turn the Hold input to MS from samples and move the release MS to coeff into the code. This means it uses more cpu but I think that ís ok for now isnt it?

Have a look.

MichaelBenjamin · 6 Apr 2009

to save some cycles i think you can write instead of: two = 1/((1/one) * 6.28319);

this line: two = one * 0.15915483;

MyCo · 6 Apr 2009

you could replace this part completely:

//calculates release ms to coeff one = relminushold * srcomp * 0.001; two = 1/((1/one) * 6.28319); //doublePi relcoeff = 1- (1/((two * 44100) + 1));

with this:

//calculates release ms to coeff relcoeff = 1- (1/(relminushold * srcomp * 7.018727 + 1));

because one and two are never used again.

MichaelBenjamin · 6 Apr 2009

ah nice, now thats a good amount of saving

aliasant · 7 Apr 2009

MyCo wrote: you could replace this part completely:

//calculates release ms to coeff one = relminushold * srcomp * 0.001; two = 1/((1/one) * 6.28319); //doublePi relcoeff = 1- (1/((two * 44100) + 1));

with this:

//calculates release ms to coeff relcoeff = 1- (1/(relminushold * srcomp * 7.018727 + 1));

because one and two are never used again.

Nice one Myco. What do you guys think. Is this a good one or should we keep looking?

bootsy · 7 Apr 2009

I will do some more audio tests on that around eastern and if I do have any new insights I will share that here ...

Zyxoas · 7 Apr 2009

Here's the original algoa-rhythm, in Assembly Language... :-/

streamin in; streamout out; streamin attack; streamin shold; streamin release;

float not=0; float oldenv=0; float env=0; float held=0; float F1=1; int absmask=2147483647;

movaps xmm7,in; andps xmm7, absmask;

movaps xmm6,env; movaps oldenv,xmm6;

movaps xmm0,xmm7; cmpps xmm0,xmm6,5; //inatt? movaps xmm4,xmm0;

cmpps xmm0,not,0; movaps xmm5,xmm0; //inrel?

andps xmm0,release; andps xmm4,attack; addps xmm0,xmm4; //filter factor

movaps xmm2,xmm6; subps xmm2,xmm7; mulps xmm0,xmm2; movaps xmm6,xmm0; addps xmm6,xmm7;//env

movaps xmm7, held; movaps xmm0,xmm7; cmpps xmm0,shold,1;//held<shold? movaps xmm3,xmm5; andps xmm3,xmm0;//inhrel?

movaps xmm1, xmm3; cmpps xmm1,not,0;//ninhrel?

movaps xmm0,oldenv; subps xmm0,xmm6;//oldenv-env movaps xmm4, xmm3; andps xmm4,xmm0;//&inhrel addps xmm6,xmm4;//+env (==> env)

andps xmm5,xmm1;//ninhrel&inrel andps xmm5,xmm7;//&held

addps xmm7,F1;//held+1 andps xmm3,xmm7;//&inhrel

addps xmm5,xmm3;//ninhrel&inrel&held+inhrel&(held+1)

movaps held,xmm5; movaps env,xmm6; movaps out,xmm6;

Would someone like to tell us what speed improvement there is?

gol · 24 Apr 2009

I fell on this while looking for envelope-related stuff.

Ok an envelope follower with a hold wouldn't work - think of it: you're in holding state, and after this holding state you release. But release to where? You don't know what happened while you were in holding state, there could have been another peak, lower than your holding level, but still a valid level that you should sustain on.

What you want isn't an envelope follower with a hold, but another step before the normal envelope follower. So right after rectifying your signal, you compute a "hold" of all of the peaks. Imagine you take your peaks, and slide them over a window, so that all of the peaks will last some hold time.

Unfortunately, this has a high CPU cost, because for each sample you have to scan the <hold time> following (or surrounding, depending on how you handle your latency) samples. To hold for 1000 samples, you'd have to process 1000 samples per sample.

The trick to speed this up is to keep track of a "peak map". You compute little blocks of peaks, in a circular buffer, so that instead of having to process 1000 samples per sample, if you do it right you'll have to process around the square root of 1000 samples. Think of it as a peak map like an audio editor would use not to have to scan the whole audio data in order to display the peaks.

It's more complex than an envelope on the RMS of the signal - for RMS you simply have to remove the last value out of your average, and add the new one, only 2 additions here.

infuzion · 26 Apr 2009

aliasant wrote: Nice one Myco. What do you guys think. Is this a good one or should we keep looking?

Is hard-coding 44100 a good idea? Is 44100 = Sample Rate?

MichaelBenjamin · 26 Apr 2009

i think the mul srcomp(sr/44100) already adresses this

bootsy · 17 Jun 2009

So, after spending several weeks with envelope curves 🙂 I do have gained indeed some further insights. I will post some stuff in my blog soon and if you have specific questions on that topic just don't hesitate to contact me. Concerning my original quest about AHR curves: It always seems necessary to lowpass such curves due to the fact that the AHR curve is no longer C2 continuous in a given interval. Those curves performances even better if proper pre-delay is applied alltogether with lowpass filtering and so there is a short ramp up right in front of peaks for e.g. gain reduction. However, there are other promising concepts (looking towards gain reduction devices) such as combining several different adjusted followers, releasing to rms curves, attack velocity estimating, program dependencies of parameters and even more esoteric concepts like using pwm for gain reduction circuits and of course the combination of all that stuff. Compression is really a tough business 😉 Thanks to all contributors here! To give something more back to you I'm currently preparing an AGC device but its not stable yet and so no promise on that ...

aliasant · 23 Jun 2009

Sounds very interesting Bootsy.

I have never tried to use an AHR env in any of my compressors. I use another method that has worked pretty good but is a bit harder to control. I modulate the A and R times. Works as a hold and can also shape the attack curve.

bootsy · 23 Jun 2009

aliasant wrote: Sounds very interesting Bootsy.

I have never tried to use an AHR env in any of my compressors. I use another method that has worked pretty good but is a bit harder to control. I modulate the A and R times. Works as a hold and can also shape the attack curve.

AHR can be cool with some pre-delay and filtering, otherwise some other concepts are way stronger - thats one of my conclusions. Program dependency like yours on A and R is always cool and sametime hard to nail. The cool thing (and the bad thing) about compressor design is that it's still an entirely empirical thing at the end. There is almost no theory (math or so) which kinda guarantees a sort of "optimum behaviour" which itself is hard to define 😈 . Similar to reverb design but much harder (imho). Thats a reason why I think that digital compression is a field where some really new and groundbreaking invention still can happen (if the inventor is willing to release those old/established concepts), but thats just a current snapshot from my own limited thoughts here.

bootsy · 21 Jul 2009

I've finally managed to assemble a short compendium on (digital) compression techniques. Maybe it's useful for someone else who will start to dig into dynamic fx programming. Click here

exonerate · 21 Jul 2009

bootsy wrote: I've finally managed to assemble a short compendium on (digital) compression techniques. Maybe it's useful for someone else who will start to dig into dynamic fx programming. Click here

Hey thanks for that. 😀 Makes me want to have a go at a compressor now!.

I think I'll have a stab at one after I've finished a few other things.

aliasant · 22 Jul 2009

bootsy wrote: I've finally managed to assemble a short compendium on (digital) compression techniques. Maybe it's useful for someone else who will start to dig into dynamic fx programming. Click here

Excellent stuff. Even something new for me. The Hilbert Transformer. Never heard of that one. Tried to read about it in the wikipedia but its not my language.... 🙁

MegaHurtz · 23 Jul 2009

Yes it`s killer.. complex numbers always throw me way off. If i have an afternoon to spend i`ll figure it out. It`s kind of usefull to do a patial dft. or yust a peak analysis.

rl · 23 Jul 2009

aliasant wrote: .... The Hilbert Transformer. Never heard of that one. .... 🙁

BTW: the SSB modulator here contains a hilbert transformer

aliasant · 23 Jul 2009

rl wrote: aliasant wrote: .... The Hilbert Transformer. Never heard of that one. .... 🙁

BTW: the SSB modulator here contains a hilbert transformer

Is it the entire SSB module that is the Hilbert transf or just the "90deg phase shift" modules?

Hard to figure out how this could be used but Im trying....

aliasant · 23 Jul 2009

Here is an image of a hilbert curve from a square.

I cant get anything near that all tough Im getting some other more or less interesting results.

bootsy · 24 Jul 2009

the basic idea is to add the 90 degree phase shifted signal to the original to make it level-wise more continous and so the resulting envelope.