Attack is too fast on exponential envelope en.adsre

[jmidt]

When the attack time is set high on the exponential ADSR envelope, the level saturates very quickly, both not giving the wanted slow increase and also creating a long time with nothing happening before going to the decay stage. I propose something like this as a fix or a separate function

adsre_variable_attack(attT60,decT60,susLvl,relT60,gate) = envelope
  with {
  ugate = gate>0;
  samps = ugate : +~(*(ugate)); // ramp time in samples
  attSamps = int(attT60 * ma.SR);

  //The function for the attack phase. Should go from 0-1 in attSamps samples. Here it is linear
  attLvl = samps/attSamps; 

   //In the attack phase the target moves up following attLvl
  target = select2(ugate, 0.0,
           select2(samps<attSamps, (susLvl)*float(ugate), attLvl));

  //Instead of attT60, we choose some very small number, such that there is virtually no smoothing in the attack phase
  t60 = select2(ugate, relT60, select2(samps<attSamps, decT60, 0.0000001)); 

  pole = ba.tau2pole(t60/6.91);
  envelope = target : si.smooth(pole);

This gives a linear ramp up, but any function could in principle be used. I can make a pull request if you want?

[josmithiii]

So you are saying there is no bug but that you prefer a linear over exponential shape for the first segment? I assume you know about the piecewise linear envelopes such as adsr. For what you describe, I would multiply adsre by asr(attT60,1,100*relT60) or something like that.

…

On Wed, Sep 26, 2018 at 3:10 PM jmidt ***@***.***> wrote: When the attack time is set high on the exponential ADSR envelope, the level saturates very quickly, both not giving the wanted slow increase and also creating a long time with nothing happening before going to the decay stage. I propose something like this as a fix or a separate function adsre_variable_attack(attT60,decT60,susLvl,relT60,gate) = envelope with { ugate = gate>0; samps = ugate : +~(*(ugate)); // ramp time in samples attSamps = int(attT60 * ma.SR); //The function for the attack phase. Should go from 0-1 in attSamps samples. Here it is linear attLvl = samps/attSamps; //In the attack phase the target moves up following attLvl target = select2(ugate, 0.0, select2(samps<attSamps, (susLvl)*float(ugate), attLvl)); //Instead of attT60, we choose some very small number, such that there is virtually no smoothing in the attack phase t60 = select2(ugate, relT60, select2(samps<attSamps, decT60, 0.0000001)); pole = ba.tau2pole(t60/6.91); envelope = target : si.smooth(pole); This gives a linear ramp up, but any function could in principle be used. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFbGAW2lts7ZSIwDdXTV62O4S-uezks5ue_tEgaJpZM4W7lQi> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

[jmidt]

Yes, I guess that is what I am saying :) I do know about the linear adsr envelope, but for most uses I find a linear release to be too slow. This was just my attempt at making something that sits in between the two. I think your approach would indeed give a softer attack slope, but I worry about what happens if the envelopes are engaged again before the second envelope has gone completely down. The attack slope would then be different the second time. I think I misspoke when calling a fix. I rather see it as a possible addition to the library. Den tor. 27. sep. 2018 kl. 20.23 skrev josmithiii <[email protected]

…

: So you are saying there is no bug but that you prefer a linear over exponential shape for the first segment? I assume you know about the piecewise linear envelopes such as adsr. For what you describe, I would multiply adsre by asr(attT60,1,100*relT60) or something like that. On Wed, Sep 26, 2018 at 3:10 PM jmidt ***@***.***> wrote: > When the attack time is set high on the exponential ADSR envelope, the > level saturates very quickly, both not giving the wanted slow increase and > also creating a long time with nothing happening before going to the decay > stage. I propose something like this as a fix or a separate function > > adsre_variable_attack(attT60,decT60,susLvl,relT60,gate) = envelope > with { > ugate = gate>0; > samps = ugate : +~(*(ugate)); // ramp time in samples > attSamps = int(attT60 * ma.SR); > > //The function for the attack phase. Should go from 0-1 in attSamps samples. Here it is linear > attLvl = samps/attSamps; > > //In the attack phase the target moves up following attLvl > target = select2(ugate, 0.0, > select2(samps<attSamps, (susLvl)*float(ugate), attLvl)); > > //Instead of attT60, we choose some very small number, such that there is virtually no smoothing in the attack phase > t60 = select2(ugate, relT60, select2(samps<attSamps, decT60, 0.0000001)); > > pole = ba.tau2pole(t60/6.91); > envelope = target : si.smooth(pole); > > This gives a linear ramp up, but any function could in principle be used. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#6>, or mute the > thread > < https://github.com/notifications/unsubscribe-auth/ACGVFbGAW2lts7ZSIwDdXTV62O4S-uezks5ue_tEgaJpZM4W7lQi > > . > -- Julius O. Smith III ***@***.***> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AfG21oEnG3sGQqrFpfyRntjEYOYi8uGVks5ufReNgaJpZM4W7lQi> .

[jmidt]

Actually, after looking at the code again, I did locate the bug. For the library function adsre: The time spent in the attack phase is calculated as attT60*ma.SR but this should be attT60/6.91*T60 for the correct scaling viz. the calculation for the poles. Then the attack slope will reach ~0.63 in one time-constant. So to bring this to one instead, the calculation for the target could be target = select2(ugate, 0.0,

select2(samps<attSamps, (susLvl)*float(ugate), float(ugate)/0.63));

Meaning the envelope will "aim too high" just like most analog envelopes but in normal operation will go to the decay phase right when it hits 1. To make sure the envelope doesn't go too high if it is retriggered while in the release phase we can limit it by envelope = target : si.smooth(pole) : min(1.0); I believe this is the correct behaviour for the envelope, and for the use case of a synthesizer amplifier envelope, it is much better sounding. I will be happy to provide a pull request if you want. Den tor. 27. sep. 2018 kl. 20.23 skrev josmithiii <[email protected]

…

: So you are saying there is no bug but that you prefer a linear over exponential shape for the first segment? I assume you know about the piecewise linear envelopes such as adsr. For what you describe, I would multiply adsre by asr(attT60,1,100*relT60) or something like that. On Wed, Sep 26, 2018 at 3:10 PM jmidt ***@***.***> wrote: > When the attack time is set high on the exponential ADSR envelope, the > level saturates very quickly, both not giving the wanted slow increase and > also creating a long time with nothing happening before going to the decay > stage. I propose something like this as a fix or a separate function > > adsre_variable_attack(attT60,decT60,susLvl,relT60,gate) = envelope > with { > ugate = gate>0; > samps = ugate : +~(*(ugate)); // ramp time in samples > attSamps = int(attT60 * ma.SR); > > //The function for the attack phase. Should go from 0-1 in attSamps samples. Here it is linear > attLvl = samps/attSamps; > > //In the attack phase the target moves up following attLvl > target = select2(ugate, 0.0, > select2(samps<attSamps, (susLvl)*float(ugate), attLvl)); > > //Instead of attT60, we choose some very small number, such that there is virtually no smoothing in the attack phase > t60 = select2(ugate, relT60, select2(samps<attSamps, decT60, 0.0000001)); > > pole = ba.tau2pole(t60/6.91); > envelope = target : si.smooth(pole); > > This gives a linear ramp up, but any function could in principle be used. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#6>, or mute the > thread > < https://github.com/notifications/unsubscribe-auth/ACGVFbGAW2lts7ZSIwDdXTV62O4S-uezks5ue_tEgaJpZM4W7lQi > > . > -- Julius O. Smith III ***@***.***> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AfG21oEnG3sGQqrFpfyRntjEYOYi8uGVks5ufReNgaJpZM4W7lQi> .

[josmithiii]

In the source I am looking at, T60 is not defined. Dividing a t60 by 6.91 converts it into a standard "time constant of exponential decay", normally denoted "tau". So attT60/6.91 could be called attTau, or attTimeConstantSec, etc. From there, attTauSamples would be attTau * ma.SR, which sounds like what you want. - Julius

…

On Fri, Sep 28, 2018 at 12:48 PM jmidt ***@***.***> wrote: Actually, after looking at the code again, I did locate the bug. For the library function adsre: The time spent in the attack phase is calculated as attT60*ma.SR but this should be attT60/6.91*T60 for the correct scaling viz. the calculation for the poles. Then the attack slope will reach ~0.63 in one time-constant. So to bring this to one instead, the calculation for the target could be target = select2(ugate, 0.0, > select2(samps<attSamps, (susLvl)*float(ugate), float(ugate)/0.63)); Meaning the envelope will "aim too high" just like most analog envelopes but in normal operation will go to the decay phase right when it hits 1. To make sure the envelope doesn't go too high if it is retriggered while in the release phase we can limit it by envelope = target : si.smooth(pole) : min(1.0); I believe this is the correct behaviour for the envelope, and for the use case of a synthesizer amplifier envelope, it is much better sounding. I will be happy to provide a pull request if you want. Den tor. 27. sep. 2018 kl. 20.23 skrev josmithiii < ***@***.*** >: > So you are saying there is no bug but that you prefer a linear over > exponential shape for the first segment? > I assume you know about the piecewise linear envelopes such as adsr. > For what you describe, I would multiply adsre by asr(attT60,1,100*relT60) > or something like that. > > On Wed, Sep 26, 2018 at 3:10 PM jmidt ***@***.***> wrote: > > > When the attack time is set high on the exponential ADSR envelope, the > > level saturates very quickly, both not giving the wanted slow increase > and > > also creating a long time with nothing happening before going to the > decay > > stage. I propose something like this as a fix or a separate function > > > > adsre_variable_attack(attT60,decT60,susLvl,relT60,gate) = envelope > > with { > > ugate = gate>0; > > samps = ugate : +~(*(ugate)); // ramp time in samples > > attSamps = int(attT60 * ma.SR); > > > > //The function for the attack phase. Should go from 0-1 in attSamps > samples. Here it is linear > > attLvl = samps/attSamps; > > > > //In the attack phase the target moves up following attLvl > > target = select2(ugate, 0.0, > > select2(samps<attSamps, (susLvl)*float(ugate), attLvl)); > > > > //Instead of attT60, we choose some very small number, such that there > is virtually no smoothing in the attack phase > > t60 = select2(ugate, relT60, select2(samps<attSamps, decT60, 0.0000001)); > > > > pole = ba.tau2pole(t60/6.91); > > envelope = target : si.smooth(pole); > > > > This gives a linear ramp up, but any function could in principle be used. > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#6>, or mute the > > thread > > < > https://github.com/notifications/unsubscribe-auth/ACGVFbGAW2lts7ZSIwDdXTV62O4S-uezks5ue_tEgaJpZM4W7lQi > > > > . > > > > > -- > > Julius O. Smith III ***@***.***> > Professor of Music and, by courtesy, Electrical Engineering > CCRMA, Stanford University > http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/> > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #6 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AfG21oEnG3sGQqrFpfyRntjEYOYi8uGVks5ufReNgaJpZM4W7lQi > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFYTHnvcC_1hl7qgUBNpa805j_ZWAks5ufnz6gaJpZM4W7lQi> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

[josmithiii]

I feel I should mention that the use of t60 as a measure of "audio decay time" for an exponential came from the literature on artificial reverberation, not analog synth modules. For exponential decay, t60 is much closer to the perceived decay time than tau. For exponential attacks, neither is very good. Since loudness perception is roughly logarithmic, the attack segment should be a _growing_ exponential, instead of the (more practical and safe) 1-decayingExponential that I _think_ everybody uses when not simply linear or polynomial. Some of the history can be found online: https://en.wikipedia.org/wiki/Synthesizer#Attack_Decay_Sustain_Release_(ADSR)_envelope I would be happy to adopt standard precise duration definitions based on some classical circuit such as the first ARP using it (apparently the Moog did not use ADSR terminology). My own background was more computer music, where linear segments ruled. However, exponential segments are nicer to have when event-driven, such as from MIDI. You're always approaching some "target" at some exponential time-constant, and this is robust to unforeseen delays when triggering the advance to the next segment. - Julius

…

On Fri, Sep 28, 2018 at 12:48 PM jmidt ***@***.***> wrote: Actually, after looking at the code again, I did locate the bug. For the library function adsre: The time spent in the attack phase is calculated as attT60*ma.SR but this should be attT60/6.91*T60 for the correct scaling viz. the calculation for the poles. Then the attack slope will reach ~0.63 in one time-constant. So to bring this to one instead, the calculation for the target could be target = select2(ugate, 0.0, > select2(samps<attSamps, (susLvl)*float(ugate), float(ugate)/0.63)); Meaning the envelope will "aim too high" just like most analog envelopes but in normal operation will go to the decay phase right when it hits 1. To make sure the envelope doesn't go too high if it is retriggered while in the release phase we can limit it by envelope = target : si.smooth(pole) : min(1.0); I believe this is the correct behaviour for the envelope, and for the use case of a synthesizer amplifier envelope, it is much better sounding. I will be happy to provide a pull request if you want. Den tor. 27. sep. 2018 kl. 20.23 skrev josmithiii ***@***.*** >: > So you are saying there is no bug but that you prefer a linear over > exponential shape for the first segment? > I assume you know about the piecewise linear envelopes such as adsr. > For what you describe, I would multiply adsre by asr(attT60,1,100*relT60) > or something like that. > > On Wed, Sep 26, 2018 at 3:10 PM jmidt ***@***.***> wrote: > > > When the attack time is set high on the exponential ADSR envelope, the > > level saturates very quickly, both not giving the wanted slow increase > and > > also creating a long time with nothing happening before going to the > decay > > stage. I propose something like this as a fix or a separate function > > > > adsre_variable_attack(attT60,decT60,susLvl,relT60,gate) = envelope > > with { > > ugate = gate>0; > > samps = ugate : +~(*(ugate)); // ramp time in samples > > attSamps = int(attT60 * ma.SR); > > > > //The function for the attack phase. Should go from 0-1 in attSamps > samples. Here it is linear > > attLvl = samps/attSamps; > > > > //In the attack phase the target moves up following attLvl > > target = select2(ugate, 0.0, > > select2(samps<attSamps, (susLvl)*float(ugate), attLvl)); > > > > //Instead of attT60, we choose some very small number, such that there > is virtually no smoothing in the attack phase > > t60 = select2(ugate, relT60, select2(samps<attSamps, decT60, 0.0000001)); > > > > pole = ba.tau2pole(t60/6.91); > > envelope = target : si.smooth(pole); > > > > This gives a linear ramp up, but any function could in principle be used. > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#6>, or mute the > > thread > > < > https://github.com/notifications/unsubscribe-auth/ACGVFbGAW2lts7ZSIwDdXTV62O4S-uezks5ue_tEgaJpZM4W7lQi > > > > . > > > > > -- > > Julius O. Smith III ***@***.***> > Professor of Music and, by courtesy, Electrical Engineering > CCRMA, Stanford University > http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/> > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#6 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AfG21oEnG3sGQqrFpfyRntjEYOYi8uGVks5ufReNgaJpZM4W7lQi> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/

[jmidt]

I did not consider the other use cases that's true, coming mostly from a synth background. But it seems that the typical standard for an ADSR in that case is to let the attack phase take around 1 tau (when the ADSR is made with a one-pole filter, as I believe many of the classic synthesizers were). As it stands now, the attack phase takes 6.71 tau = attT60 which is the input parameter to the function. I think making that change would let the envelope conform to what more people expect. I will be happy to push this upstream if you want to. Your point about T60 being a better measure for decay makes a lot of sense. It would actually explain a few things I have wondered about. By the way, thank you for your work on Faust. It is the DSP backbone for our open-source project. - Jonatan Den fre. 28. sep. 2018 kl. 22.09 skrev josmithiii <[email protected]

…

: I feel I should mention that the use of t60 as a measure of "audio decay time" for an exponential came from the literature on artificial reverberation, not analog synth modules. For exponential decay, t60 is much closer to the perceived decay time than tau. For exponential attacks, neither is very good. Since loudness perception is roughly logarithmic, the attack segment should be a _growing_ exponential, instead of the (more practical and safe) 1-decayingExponential that I _think_ everybody uses when not simply linear or polynomial. Some of the history can be found online: https://en.wikipedia.org/wiki/Synthesizer#Attack_Decay_Sustain_Release_(ADSR)_envelope I would be happy to adopt standard precise duration definitions based on some classical circuit such as the first ARP using it (apparently the Moog did not use ADSR terminology). My own background was more computer music, where linear segments ruled. However, exponential segments are nicer to have when event-driven, such as from MIDI. You're always approaching some "target" at some exponential time-constant, and this is robust to unforeseen delays when triggering the advance to the next segment. - Julius On Fri, Sep 28, 2018 at 12:48 PM jmidt ***@***.***> wrote: > > Actually, after looking at the code again, I did locate the bug. For the > library function adsre: > > The time spent in the attack phase is calculated as > attT60*ma.SR > but this should be > attT60/6.91*T60 > for the correct scaling viz. the calculation for the poles. Then the attack > slope will reach ~0.63 in one time-constant. So to bring this to one > instead, the calculation for the target could be > target = select2(ugate, 0.0, > > select2(samps<attSamps, (susLvl)*float(ugate), float(ugate)/0.63)); > Meaning the envelope will "aim too high" just like most analog envelopes > but in normal operation will go to the decay phase right when it hits 1. To > make sure the envelope doesn't go too high if it is retriggered while in > the release phase we can limit it by > envelope = target : si.smooth(pole) : min(1.0); > > I believe this is the correct behaviour for the envelope, and for the use > case of a synthesizer amplifier envelope, it is much better sounding. I > will be happy to provide a pull request if you want. > > > > Den tor. 27. sep. 2018 kl. 20.23 skrev josmithiii < ***@***.*** > >: > > > So you are saying there is no bug but that you prefer a linear over > > exponential shape for the first segment? > > I assume you know about the piecewise linear envelopes such as adsr. > > For what you describe, I would multiply adsre by asr(attT60,1,100*relT60) > > or something like that. > > > > On Wed, Sep 26, 2018 at 3:10 PM jmidt ***@***.***> wrote: > > > > > When the attack time is set high on the exponential ADSR envelope, the > > > level saturates very quickly, both not giving the wanted slow increase > > and > > > also creating a long time with nothing happening before going to the > > decay > > > stage. I propose something like this as a fix or a separate function > > > > > > adsre_variable_attack(attT60,decT60,susLvl,relT60,gate) = envelope > > > with { > > > ugate = gate>0; > > > samps = ugate : +~(*(ugate)); // ramp time in samples > > > attSamps = int(attT60 * ma.SR); > > > > > > //The function for the attack phase. Should go from 0-1 in attSamps > > samples. Here it is linear > > > attLvl = samps/attSamps; > > > > > > //In the attack phase the target moves up following attLvl > > > target = select2(ugate, 0.0, > > > select2(samps<attSamps, (susLvl)*float(ugate), attLvl)); > > > > > > //Instead of attT60, we choose some very small number, such that there > > is virtually no smoothing in the attack phase > > > t60 = select2(ugate, relT60, select2(samps<attSamps, decT60, 0.0000001)); > > > > > > pole = ba.tau2pole(t60/6.91); > > > envelope = target : si.smooth(pole); > > > > > > This gives a linear ramp up, but any function could in principle be used. > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > <#6>, or mute the > > > thread > > > < > > https://github.com/notifications/unsubscribe-auth/ACGVFbGAW2lts7ZSIwDdXTV62O4S-uezks5ue_tEgaJpZM4W7lQi > > > > > > . > > > > > > > > > -- > > > > Julius O. Smith III ***@***.***> > > Professor of Music and, by courtesy, Electrical Engineering > > CCRMA, Stanford University > > http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/> > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub > > < #6 (comment) >, > > or mute the thread > > < https://github.com/notifications/unsubscribe-auth/AfG21oEnG3sGQqrFpfyRntjEYOYi8uGVks5ufReNgaJpZM4W7lQi > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread. -- Julius O. Smith III ***@***.***> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AfG21ir5XYwTDmuTc-LYawALFxWGjoQrks5ufoINgaJpZM4W7lQi> .

[sletz]

BTW, is your open-source project using Faust visible somewhere? Thanks.

[jmidt]

Hi Stephane. You can check it out on github.com/topisani/OTTO We wanted to write a bit about the project for your list of Faust projects, but we are working towards an alpha version of the software so we were planning on waiting a bit, actually... - jonatan lør. 29. sep. 2018 09.48 skrev Stéphane Letz <[email protected]>:

…

BTW, is your open-source project using Faust visible somewhere? Thanks. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AfG21ueMy6JJQWdjC6E9N6KgS42SNiKCks5ufyXjgaJpZM4W7lQi> .

[josmithiii]

Does anyone have a pointer to doc, or readable schematic, for a classic analog synth or envelope module that specifies envelope segment durations in terms of time constants? In my opinion, it is not too late to change the exponential envelopes such as adsre, because they were introduced so recently and because other backward-incompatible changes have recently occurred, especially in the libraries. It will also be nice to document in the comments what classic case we are following. - Julius

…

On Sat, Sep 29, 2018 at 2:46 AM jmidt ***@***.***> wrote: Hi Stephane. You can check it out on github.com/topisani/OTTO We wanted to write a bit about the project for your list of Faust projects, but we are working towards an alpha version of the software so we were planning on waiting a bit, actually... - jonatan lør. 29. sep. 2018 09.48 skrev Stéphane Letz ***@***.***>: > BTW, is your open-source project using Faust visible somewhere? Thanks. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #6 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AfG21ueMy6JJQWdjC6E9N6KgS42SNiKCks5ufyXjgaJpZM4W7lQi > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFb3aHrjGx8iIl0xBymJC_6o3A8eYks5uf0GHgaJpZM4W7lQi> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

[jmidt]

Looking at page 2-8 of the the service manual for the Minimoog (It really doesn't get much more classic than that) http://manuals.fdiskc.com/tree/Moog/Moog%20Minimoog%20Service%20Manual.pdf The language suggests that the attack phase is one RC time constant. It would fit roughly with the voltages mentioned: An exponentially rising slope (bad wording - they mean exactly what you said earlier) being pulled up by 9.3 volts on a transistor, probably about 0.7-1.0 volts less when accounting for diode losses in the transistor. And then the attack phase terminates when it reaches 5 volts. That fits with approximately 0.6 of the target voltage. - Jonatan lør. 29. sep. 2018 20.30 skrev josmithiii <[email protected]>:

…

Does anyone have a pointer to doc, or readable schematic, for a classic analog synth or envelope module that specifies envelope segment durations in terms of time constants? In my opinion, it is not too late to change the exponential envelopes such as adsre, because they were introduced so recently and because other backward-incompatible changes have recently occurred, especially in the libraries. It will also be nice to document in the comments what classic case we are following. - Julius On Sat, Sep 29, 2018 at 2:46 AM jmidt ***@***.***> wrote: > Hi Stephane. > You can check it out on > github.com/topisani/OTTO > We wanted to write a bit about the project for your list of Faust projects, > but we are working towards an alpha version of the software so we were > planning on waiting a bit, actually... > > - jonatan > > lør. 29. sep. 2018 09.48 skrev Stéphane Letz ***@***.***>: > > > BTW, is your open-source project using Faust visible somewhere? Thanks. > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub > > < > #6 (comment) > >, > > or mute the thread > > < > https://github.com/notifications/unsubscribe-auth/AfG21ueMy6JJQWdjC6E9N6KgS42SNiKCks5ufyXjgaJpZM4W7lQi > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #6 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/ACGVFb3aHrjGx8iIl0xBymJC_6o3A8eYks5uf0GHgaJpZM4W7lQi > > . > -- Julius O. Smith III ***@***.***> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AfG21vwyOZe3THWNY6Ef9PT7zrkhZOPdks5uf7xggaJpZM4W7lQi> .

[josmithiii]

That fits together pretty well I think. Defining attack time as one time-constant corresponds to saying the attack "happens" when the rising envelope comes within 4 dB of the attack amplitude, i.e., 20*log10(1-exp(-1)) ~ -3.984. Similarly, 20*log10(0.6) ~ -4.4370. While this is good for the attack, I think the Release Time should remain defined as the t60 for the final exponential release. For the Decay Time, I could go either way. Having two different duration conventions in the same envelope API is not ideal. Another option is to document in the comments how to easily convert t60 to tau (divide by 7 or so) or even more precisely to what the Minimoog does (with a pointer to the service manual, thanks for that!). A more general question is whether the Faust library APIs should be designed for "users" or "developers". I've been leaning toward developers, who should want anything precise, minimal, and consistent that they can easily convert to whatever they want, or simply copy/paste and rewrite to taste, but in some places there are more user-friendly choices, such as the dB levels in the shelf filters (a choice I have frequently regretted :-) - not "minimal" enough). The libraries are not consistent on this at present. - Julius

…

On Sat, Sep 29, 2018 at 11:50 AM jmidt ***@***.***> wrote: Looking at page 2-8 of the the service manual for the Minimoog (It really doesn't get much more classic than that) http://manuals.fdiskc.com/tree/Moog/Moog%20Minimoog%20Service%20Manual.pdf The language suggests that the attack phase is one RC time constant. It would fit roughly with the voltages mentioned: An exponentially rising slope (bad wording - they mean exactly what you said earlier) being pulled up by 9.3 volts on a transistor, probably about 0.7-1.0 volts less when accounting for diode losses in the transistor. And then the attack phase terminates when it reaches 5 volts. That fits with approximately 0.6 of the target voltage. - Jonatan lør. 29. sep. 2018 20.30 skrev josmithiii ***@***.***>: > Does anyone have a pointer to doc, or readable schematic, for a classic > analog synth or envelope module that specifies envelope segment durations > in terms of time constants? In my opinion, it is not too late to change > the exponential envelopes such as adsre, because they were introduced so > recently and because other backward-incompatible changes have recently > occurred, especially in the libraries. It will also be nice to document in > the comments what classic case we are following. > > - Julius > > > On Sat, Sep 29, 2018 at 2:46 AM jmidt ***@***.***> wrote: > > > Hi Stephane. > > You can check it out on > > github.com/topisani/OTTO > > We wanted to write a bit about the project for your list of Faust > projects, > > but we are working towards an alpha version of the software so we were > > planning on waiting a bit, actually... > > > > - jonatan > > > > lør. 29. sep. 2018 09.48 skrev Stéphane Letz ***@***.*** >: > > > > > BTW, is your open-source project using Faust visible somewhere? Thanks. > > > > > > — > > > You are receiving this because you authored the thread. > > > Reply to this email directly, view it on GitHub > > > < > > > #6 (comment) > > >, > > > or mute the thread > > > < > > > https://github.com/notifications/unsubscribe-auth/AfG21ueMy6JJQWdjC6E9N6KgS42SNiKCks5ufyXjgaJpZM4W7lQi > > > > > > . > > > > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > < > #6 (comment) > >, > > or mute the thread > > < > https://github.com/notifications/unsubscribe-auth/ACGVFb3aHrjGx8iIl0xBymJC_6o3A8eYks5uf0GHgaJpZM4W7lQi > > > > . > > > > > -- > > Julius O. Smith III ***@***.***> > Professor of Music and, by courtesy, Electrical Engineering > CCRMA, Stanford University > http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/> > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #6 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AfG21vwyOZe3THWNY6Ef9PT7zrkhZOPdks5uf7xggaJpZM4W7lQi > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFd5PqgyPy1UFrLqulsA51Z0RrveDks5uf8DkgaJpZM4W7lQi> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>