Attack is too fast on exponential envelope en.adsre
jmidt opened this issue · comments
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?
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 <jos@ccrma.stanford.edu>
Professor of Music and, by courtesy, Electrical Engineering
CCRMA, Stanford University
http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>
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 <notifications@github.com
…:
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>
.
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 <notifications@github.com
…:
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>
.
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 <jos@ccrma.stanford.edu>
Professor of Music and, by courtesy, Electrical Engineering
CCRMA, Stanford University
http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>
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 <jos@ccrma.stanford.edu>
Professor of Music and, by courtesy, Electrical Engineering
CCRMA, Stanford University
http://ccrma.stanford.edu/~jos/
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 <notifications@github.com
…:
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>
.
BTW, is your open-source project using Faust visible somewhere? Thanks.
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 <notifications@github.com>:
… 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>
.
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 <jos@ccrma.stanford.edu>
Professor of Music and, by courtesy, Electrical Engineering
CCRMA, Stanford University
http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>
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 <notifications@github.com>:
… 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>
.
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 <jos@ccrma.stanford.edu>
Professor of Music and, by courtesy, Electrical Engineering
CCRMA, Stanford University
http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>