[sdiy] Fast envelope follower circuit needed..

Paul Anderson wackyvorlon at me.com
Sat Mar 30 17:43:44 CET 2013


To add to these comments, the cut off on most filters is often defined at the point of 3dB of attenuation. 3dB roughly equates to a doubling or halving of amplitude. So a 3dB increase on a 6 volt signal makes it 12v. 

Filters look very simple, but the theory is surprisingly complex. 

Sent from my iPhone

On 2013-03-30, at 10:19 AM, cheater cheater <cheater00 at gmail.com> wrote:

> Hi guys,
> there are several points from Tom, Scott, and Brian here I'd like to
> address. I hope it's ok, I would like to point out some errors to
> spare you frustration in the future.
> 
> 1. "the filter does not care about the spikes in the valleys"
> 
> that's incorrect. Bear in mind that this high-frequency content is not
> removed in a low-pass filter, it is attenuated. Quite often the
> rejection is less than the theoretical maximum for many reasons
> (numerical error, incorrect algorithm implementation, etc). In effect,
> that "rejected" signal is still there.
> 
> Especially if you use non-linearities later in your signal path (that
> is, always), whatever program you modulate with such a tainted
> envelope will sound worse than it could otherwise.
> 
> 2. "analog rectification creates wide-band energy bursts anyways"
> 
> not an accurate picture of the situation. In analog, this sound will
> be harmonically related to your input, which is a good thing. In
> digital, it will work exactly against it, which is very bad. Besides,
> the turn-on and turn-off speed is limited, it's not when using abs()
> in a digital signal, but I don't know what the exact difference in
> bandwidth limitation is in analog - it's unlimited in digital (with
> the caveat that it gets mirrored around fs/2 and 0Hz, perhaps several
> times)
> 
> 3. "the peak hold doesn't care about the little valleys"
> 
> not true at all. I believe this comes from the conceptual
> simplification of the filter, which could go like this:
> (i) when the input signal is above the current output, raise the output to match
> (ii) when the input signal is below the current output, drop the
> output at a constant rate
> 
> that is extremely inaccurate. What happens is more similar to this:
> (iii) measure the distance between the current output and current
> input. Move so that during a period of time, say 1 second, you cover a
> fixed percentage of this distance, directly related to a number called
> the time constant. For example, cover 90% in 1 second.
> 
> What does this mean? Say your output is at 1V, and your input is a
> sinewave oscillation between 0V and 0.01V. As your output is falling,
> it'll fall relatively faster when the input is near 0V (because the
> distance is higher), and it'll fall relatively slower when the input
> signal is *closer* to the output signal (i.e. when the input is at its
> 0.01V maximum).
> 
> This is easily described by saying that the peak hold is just a filter
> as well, but it doesn't quite picture it, that's why I described the
> operation above.
> 
> You might ask: "But can't I just use max() of the input and output and
> somehow use that?"
> 
> One might think this code would work:
> if (output < input) {
>  output = input
> }
> else {
>  output -= 0.01
> }
> 
> This is a beginner's mistake. This sort of design will create awful
> amounts of zipper noise. You don't want that. You want to use a
> filter.
> 
> Brian, you first correct Tom on his mistake, then make the same
> mistake yourself elsewhere, then agree with Scott who has made the
> same mistake :)
> 
> 4. "because peak detection allows the output to suddenly change if the
> input is greater than the hold value, and any time a digital algorithm
> allows a sudden discontinuity in its output you have the potential for
> non-band-limited square wave type aliasing"
> 
> Not true. You just use a normal (asymmetric) filter for the peak hold,
> like you usually would, and set its time constant for rising signals
> so that it reacts instantly.
> 
> Your logic is flawed because you're thinking in terms of the "if/else"
> model I described above. It doesn't hold. The transition you describe
> will not be abrupt. There will still be phase delay like in any usual
> filter (that's a good thing), and this phase delay will give the
> filter just enough time buffer for things to happen relatively
> smoothly. It's a different question, though, whether your filter
> aliases *as a whole*.
> 
> 5. "Assuming your audio signal is limited to 20 kHz maximum, and your
> sample rate is 44.1 kHz, then your envelope signal need only have no
> aliases above 2.05 kHz. Bingo, no audio aliasing"
> 
> That's not how it works. If your signal picked up aliasing somewhere
> earlier, it's not going to magically get rid of it by becoming
> band-limited later on. If you have frequencies within your 2.05 kHz
> that do not agree with the harmony of your program, you're going to
> hear it, simple as that. If you said...
> 
> "multiplying two signals, such that the sum of their bandwidth is less
> than fs/2, will not create new aliases"
> 
> ...then I might be partial to agreeing, although due to numerical
> inaccuracies that's not really true either. Depending on what you're
> working with, YMMV.
> 
> 6. "I do not see how that is a problem with an envelope detector. The
> goal is to produce a control signal with basically "no" frequency
> components, or at least they should be as close to DC as possible. In
> practice, there will always be undesired low-frequency components in
> the envelope. My point here is that aliased components are no more
> problematic than non-aliased frequency components."
> 
> Only if you revel in muddy sound that becomes more and more occluded
> and unclear the more processing you apply. It's a fact that
> harmonically unrelated sounds present in your program will deteriorate
> its quality. They're much worse than e.g. white noise, because they're
> concentrated in single, discernible tones, which play melodies that go
> completely against the sounds that you are playing on the keyboard.
> I'm not sure how to better say this; if anyone here is not convinced
> that having this is bad, please read the previous sentence 50 times.
> 
> 7. "The remaining frequency components are all equally undesired, and
> it doesn't really matter whether they're aliases or not, so long as
> they are low enough in frequency."
> 
> It's exactly the other way around: aliased low-frequency components
> are very undesirable and are glaring problems in the final sound.
> Harmonically related frequency components don't work against the sound
> you're building, and are often very desirable. At worst they are
> harmless because they become invisible when surrounded by lots of
> other stuff playing in the same harmony.
> 
> 8. "Perhaps I don't even need to bother rectifying the signal. Why not
> just keep a check on the negative peaks like the positive ones, and
> then use some average of the two as the final output. JP said his
> signal might well be asymmetric (which is not at all uncommon), so we
> can't assume the two envelopes will be the same."
> 
> This is DSP, not analog fx design. DSP is a harsh mistress. You can do
> a lot of learning by experimenting in analog electronics and it works
> out well. The signal degradation which happens when you make errors is
> very musical: nth harmonic distortion, homogenic noise, cross-talk of
> content that is harmonically related. It's all nice and very
> forgiving. In DSP, you have very, very bad degradation modes: i)
> aliasing - takes your melody and makes it sound like it's just random
> notes; ii) through-zero distortion - adds mud and reduces clarity in a
> way that's not related to your sound in any way; iii) time delay -
> makes sure that you will never be able to mix your sound correctly
> again after you've split it; iv) numerical errors - similar to
> aliasing, those create junk in your sound that is harmonically
> unrelated to the sound you're trying to achieve (examples include bit
> errors, zipper noise, clicks, hard clipping, etc).
> 
> Be warned: you really have to go by the book on DSP. There are very
> good books online; Julius Orion Smith's website is the best,
> most-recommended classic. You simply can't "common-sense" your way
> through digital audio. It's daunting. You'll be making errors, and the
> worst thing is that in analog when you make errors they're obvious
> whereas in digital, when you make errors, you might not notice until
> after you've shipped the box; in the end people figure it out though
> and just don't like your design. Granted that doesn't matter if you're
> selling for the masses that buy microcorgi and other junk like that;
> but let's maybe leave this kind of talk off this list and try to think
> about what it takes to do an honest job. As someone said, if
> something's worth doing, it's worth doing well.
> 
> Cheers,
> D.
> 
> On Sat, Mar 30, 2013 at 7:24 AM, Paul Perry <pfperry at melbpc.org.au> wrote:
>> A little philosophy on envelope followers:
>> It's easy to see what the envelope should look like - after the original
>> signal has been! But if you take a typical input signal, graph it, and then
>> cover it with a card, and try to draw an envelope as you slide the card to
>> the right........... you might see that is is not just 'difficult', but
>> actually 'impossible' to have a circuit that behaves as you would wish.
>> 
>> In my experience, there is no envelope follower that suits all applications.
>> In particular, percussion and guitar are very different. I don't doubt that
>> Harry's circuit is ideal for a guitar.. and that if he could have got away
>> with fewer components, he would have (remember, a hex guitar has SIX
>> outputs!)
>> 
>> On the bright side, I have also found that if you are using the derived
>> envelope to control a filter or VCA, the actual audio effect can be quite
>> musically useful, even though the envelope itself looks really unpromising
>> on the scope. In particular, full wave rectification was not much better
>> than half wave.
>> 
>> Real problems arise when the frequencies being enveloped are very low, in
>> this case the low pass filtering is in conflict with the envelope being
>> derived. Again, it is a matter of knowing what the results are going to be
>> with a practical envelope, rather than knocking oneself out trying to
>> produce an 'ideal' envelope.
>> 
>> paul perry Melbourne Australia
>> 
>> 
>> 
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at dropmix.xs4all.nl
>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy



More information about the Synth-diy mailing list