[linux-audio-dev] Envelopes

james at dis-dot-dat.net james at dis-dot-dat.net
Fri Jun 30 21:04:40 UTC 2006


Wow.

I just have linear ADSR, which is about all I need.  The exponential
decay and attack are probably a good idea, though.

Cheers.  It's nice to see people thinking!  That sounds wrong.  I
mean, compared to only seeing the result of thought, which is more
usual.

James

On Fri, 30 Jun, 2006 at 10:02PM +0200, Jens M Andreasen spake thus:
> On Thu, 2006-06-29 at 13:38 +0100, james at dis-dot-dat.net wrote:
> > Hi peeps.
> > 
> >   I've been writing an app that requires volume envelopes.  I've
> >   implemented the envelope part myself, but I was wondering if there
> >   was a library about to do it.
> > 
> >   I ask because I realised that probably everyone on this list has
> >   written something that uses envelopes, and probably written it
> >   better and with more features than I have.
> > 
> 
> Well, I don't know what features you have implemented or wish for, but
> for what it is worth, I implemented 8 stage envelopes with looping
> sustainlevels, key- and velocity-follow, the works ... and it is all
> crap! :-D Honestly, I never use all those features (spare the
> key-follow) and am instead returning to a much more basic view of
> envelopes where even the standard ADSR appears to be a bit over-worked.
> 
> The focus on complex envelopes is perhaps a left-over from another era
> when stable oscillators were expensive and envelopes fairly cheap to
> implement, adding a welcomed illusion of complexity. Other
> implementations made from many smaller basic building blocks, like the
> ones from Bucla and EMS, was an exclusive for radio-stations and
> research-centers.
> 
> Bucla only had attack/decay (but you could chain several elements), 
> 
> EMS had attack/decay/release which I believe comes pretty close to an
> ideal minimalist approach:
> 
> * Attack is needed because it may take some time before the system
> stabilizes after we start adding energy.
> 
> * Decay is needed because we may have added a single burst of energy,
> fading away with no further energy being added.
> 
> * Release is needed for damping, or else all our instruments will be
> variations of tubular bells and marimbas. A straight forward Farfisa
> organ has its place too.
> 
> Is this then really enough to cater for all our envel?pe needs? 
> 
> Given we have a few of them, say a small number like four, and a
> patchbay, I believe it is. 
> 
> Say we wanted to use a wobbling complex envelope for a punchy trombone
> bratt? That can still be done with simple envelopes, perhaps even better
> than with a complex, by routing an LFO through a second (shortish)
> envelope, modulating the sounding oscillator on top of the main
> envelope. Combine and conquer! Oscillators are cheap these days and we
> do not need to rely on a single LFO implemented as a shared resource. 
> 
> Or perhaps we would like a bit of envelope delay to make a sudden change
> of the sound after a while? One way of doing this could be to put the
> envelope through a delay line (which we would then need to have made
> part of the synthesizing algorithm.) There is no need to put the delay
> feature into the envelope itself. Delay lines are inexpensive these days
> and, given a patch bay, very flexible and useful little tools also for
> peak and notch filters. Hey, given enough feedback, we can even use them
> as spare oscillators ...
> 
> Another argument in favour of ADR rather than, say ADSR, is if we
> compare by counting the number of knobs to be assigned. Given a finite
> amount of knobs, I am convinced it would be more flexible to have four
> ADR's rather than three ADSR's. And knobs are a finite resource, if for
> no other reason than the lenght of your arms.
> 
> Finally, we could throw in a bit of Bucla wisdom and allow  the
> envelopes to retrigger themselves, so as to get us a bank of LFO's
> instead.
> 
> 
> 
> With all this being said, what would then be a desireable implementation
> of a very basic ADR? 
> 
> The decay and release is probably the easiest to come to terms with,
> because we will simply borrow from physics, which tells us that the
> system should decay exponentially towards zero. And then some ...
> Because of the inner damping, we actually do reach zero in finite time. 
> 
> Following the same strategy backwards for the attack unfortunately does
> not work. Our instruments will sound uninspired and booring ... But if
> we instead allow us to do it upside down, an exponential decay from zero
> towards one so to say, then we appear to come much closer to the desired
> result. Now why is that? 
> 
> I can see two reasons, the first one again having to do with physics.
> Say we were playing the trombone, then the energy applied from the
> buildup of pressure is almost explosive in the initial phase,
> accellerating the system response very quickly, but over time the intial
> pressure diminishes, giving us a smoother rounding into the sustained
> part. So it is in part because that that's the way attacks tend to
> appear naturally. The second reason is that given a choice we wouldn't
> really like to do it any other way, not even in situations where we
> gently fade the notes in ... because it makes no sense to play below the
> hearing-treshold. A fast fade-in to just above hearing-treshold,
> grabbing the attention, followed by a smooth parking at the sustain
> level, allows us to be both soft and distinct at the same time. 
> 
> Although technically not part of the envelope itself, a keyfollow,
> modifying the time of the envelope is a must have. Small high pitced
> systems tends to decay much faster than the huge and low pithed ones.
> One thing to remember here, is to keep the unmodifyed reference note
> within the part of the keyboard that we actually own. Having key zero as
> a reference is an annoying mistake.
> 
> The real kicker would of course be if we have aimed high enough in the
> quality of implementation, as well as applied the re-trigger feature.
> Then the keyfollow could potentially turn the envelope into a pitched
> oscillator with variable shape. Aim even higher and make it a stateless
> function, and we can start implementing FM-synthesis. We could also let
> one envelope re-trigger another, re-triggering the first. With
> appropiate settings we would then be on our way into the realms of the
> Casio CZ-101  ... 
> 
> 
> Oy, this became somewhat lengthier than I intended. I better stop now
> before it turns into a complete design document for a synthesizer based
> on simple envelopes and short delay lines. Also ... It is friday evening
> and I have a beer to attend to :-D
> 
> >   More generally, is there a library/toolkit of audio bits and bobs
> >   about?
> > 
> 
> Well if you like, you can copy/paste the old ones I have. In the
> innermost loop there are  a few mmx instructions adding up progress and
> squaring the current value, but they can easily be rewritten to plain C.
> 
> And like I said, it is perfectly possible to ignore the excess
> parameters and make a simplified UI
>  
> > James
> > 




More information about the Linux-audio-dev mailing list