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, [EMAIL PROTECTED] 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 > >
