[sdiy] Schmitz ADSR replace pots with CV control?

Tom Wiltshire tom at electricdruid.net
Sat Nov 30 00:17:51 CET 2013


Hi Damian,

On 29 Nov 2013, at 19:40, "cheater00 ." <cheater00 at gmail.com> wrote:

> On Tue, Nov 26, 2013 at 7:16 PM, Tom Wiltshire <tom at electricdruid.net> wrote:
> 
>> assuming I did have an envelope that was quantized to a 100KHz clock, how does that generate sidebands in my signal? I don't understand how that process works. I'm talking about an analog envelope that's controlled by uP logic here, not a fully-digital envelope, so there's no quantisation of envelope level, only a small degree of time quantisation. I don't understand how that is supposed to harm the signal.
> 
> If a signal has events that are quantised to a clock, the fundamental
> of that clock will be present in the signal. This is basic frequency
> domain math.

Presumably the *amount* of this fundamental would vary significantly depending on the signal, though, right? I'd expect that the more regular the signal, the more fundamental, no?
If it were essentially randomised events that just happen to occur at whole number of X intervals, there wouldn't be half as much fundamental as if it were events that occur every X. Or is my surmise wrong?
Envelopes are in the first case, not the second, so the level of this supposed 100KHz fundamental is low.

>> Sorry, I wasn't clear. 125ns is the time for a "single cycle" instruction to execute on recent 16F1xxx chips. That's an 8MHz rate. It's true that the instruction cycle is a quarter of the clock speed - that's 32MHz. Since nothing actually runs at the clock rate, the Microchip jargon is mostly to talk about the "instruction cycle" instead. So I've actually got nearer 80 instructions rather than 25, although 25 would probably do it.
>> 
>> I don't believe (but am willing to be convinced) that people will hear because the envelope start/end points are quantised to a 100KHz clock. But the situation isn't even that bad - we might have a delay of 10us after a state change before the envelope reacts, but it'll be quantised at the 8MHz instruction rate, not at the speed of the delay.
> 
> That's pretty good. I think 8 MHz isn't going to be audible. I got 100
> kHz from thinking about a busyloop with no branching, but an interrupt
> handler is indeed going to quantize to those 8 MHz.

Yep. So we don't really need to worry about the 100KHz anyway, aside from a few exotic cases like the envelope feedback you suggest.
And at 8MHz, the quantisation *really* isn't an issue.

Have a listen. This demo has the LoopEnv running as the filter envelope from about 1:20 in:

http://vimeo.com/52603835

There's no audible quantising. In fact, I'll bet if you didn't know already, you wouldn't guess that was a fully digital envelope at all.

> One issue left is that at a 100 kHz triggering rate you're only
> looking at a 10 msec attack, and that's going to again change how
> things sound because even if this frequency is inaudible, it's going
> to push inaudible noise into the audio band in the VCA.

No, sorry. This is just you getting in a tangle. 100KHz is 10us before the attack starts. 100*Hz* is 10ms before the attack starts. Neither says anything about how long that attack lasts. that would depend on the sample rate, and the minimum attack would be limited to a single sample.

> However I am not of the opinion you can easily fit the envelope logic
> in 25 cycles. Because of the state transition lag, you'll have to
> deglitch the envelope logic. I believe that if state transitions are
> faster (on the order of gate propagation delay) this can be skipped,
> but now you're talking about really slow transitions, so your envelope
> needs to really be sure it wants to change its state before it does
> so.

The logic for a envelope with Gate is the following:
1) Did the Gate go high? Start the Attack from where we are now if so.
2) Did we reach the top of the Attack? Start the Decay if so.
3) Did we reach the end of the Decay? Hold at the Sustain level if so.
4) Did the Gate go low? Start the Release from where we are now if so.

It's not so much really. 25 instructions is few, I agree, but you're into implementation details at that point. Note that (1) and (4) can be dealt with by an Interrupt-on-change on an IO pin, so they don't need to affect the main code.

The fiddly bits of digital envelopes are more the scaling of the curves to fit the max/min levels of each section, at least on chips with no multiply like the basic PIC. That's much more costly than the logic, which is simple enough.

> I wonder what of the above is apparent with the PIC based envelope
> generator someone posted above. Has anyone got one of those?

I might have one or two…

> Can you run tests like the above? 1) an env in a feedback loop, with the
> shortest attack and decay and no sustain or release - what frequency
> of oscillation do you get?

Around 300Hz on my recent LoopEnv. You can play a baseline on it, if you can be bothered to fine tune the CV to the Time CV input. I've done it for grins. Modulating the Sustain CV whilst so doing gives some basic timbral variations. Modulating other parameters obviously alters the pitch.

> 2) put white noise through a low pass filter, and through a VCA which is in turn controlled by an envelope
> with the lowest ADSR settings you can get (as in 1). Use the output of
> that to drive the PIC based envelope with AD set to 0, sustain at 50%,
> release at 0. Does the envelope glitch out?

No, it gives its shortest attack/decay/release times of about 1ms, just like you asked it to. That's why you get 300Hz in loop mode: 1ms attack+1ms decay+1ms release = 3ms total = 300Hz, give or take.
Of course, spikes that short can be regarded as "glitchy" if you want to describe them as such, but in my view a decent envelope ought to offer you the option of glitchy-short if you want it. After all, you can always slow it down if that's not what you want. Whereas it's impossible to get a glitchy "snap" or "pop" out of a envelope that doesn't output samples fast enough (Wave! Xpander!)).

> I'm still of the opinion that a tiny FPGA could be a better idea. They
> don't cost more. And you aren't venturing onto thin ice with little
> theoretical basis like you do with microprocessor control, since
> you're again working with gates.

I'm not venturing onto any thin ice on any theoretical basis. I'm only sharing what I've learned through trying it. If I didn't *know* the ice would hold me, there's no way I'd have opened my mouth. Whilst I've no doubt it's possible to build a marvellous envelope generator using an FPGA (Scott Gravenhorst could give us both a lot of pointers, I'm sure) I haven't seen such a thing as a stand-alone module. I suspect that even with a bottom-end chip, you'd pay for about a million more gates than you needed for the job in hand, and as such it would only make sense for a multi-envelope or whole synth. But what do I know? - I've never tried it! ;)

Regards,
Tom





More information about the Synth-diy mailing list