On Tue, Jan 6, 2015 at 4:11 AM, Julius Smith <j...@ccrma.stanford.edu> wrote:
> At 12:33 PM 1/4/2015, Jonatan Liljedahl wrote:
>
> ...
>> Would you mind explaining this line, changing time from /2 to /10?
>
>> inlevel = amp_follower_ud(att/10,rel/10.0);
>
>> I've been thinking about that line. What's the thought about coupling
>> it to the noise gate attack and release, instead of having fixed times
>> for this level detector? Why not a zero attack time and shortest
>> possible release but long enough to handle low frequencies, since the
>> sharp attack will be filtered by the final envelope anyway?
>
> I think your proposal sounds reasonable. My thinking was to do as much
> filtering as possible in the level estimation without noticeably adding to
> the attack or release (to maximize noise immunity and minimize "chatter"
> around the threshold).
I see, that makes sense! If the time/10.0 doesn't add any noticeable
duration to the response, then filtering as much as possible in that
stage can only be good.
>> Also, I saw your commit touched the comment about the fact that
>> amp_follower_ud needs slower release than attack. And it occurred to
>> me that one could replace the amp_follower_ud(att,rel) at the end of
>> gate_gain_mono with a synth-style AR envelope, since the input is a
>> boolean gate signal. Then one would get rid of the limitation of
>> slower release than attack, in this specific case. (could be used for
>> "reversed gate" effect, etc)
>
> Yes, a synth-style AR envelope would be more general, and it is even
> implemented already in music.lib (see 'adsr' there). In the classic audio
> amplitude follower, however, the assumption holds due to audio perception
> working the way it does, and the implementation is simplified accordingly
> (replacing a "release stage" envelope segment by a simple "smooth" function.
> That said, I don't think the computational expense is very different.
I'll try that and see how it works.
>> BTW, any idea of how to make an amp follower where attack and release are
>> fully separated?
>
> A friend of mine once said "anything is possible in software". :-)
>
> I think your idea of triggering phases of a general ASR envelope makes
> sense.
>
> I suggest implementing whatever seems ideal for your situation, and if it
> generalizes to cover common cases, let's drop it into effect.lib!
Yeah, but I can't really wrap my head around how it would work, or how
to express it in faust code (I'm more used to imperative programming).
Possibly something like this:
if input is higher than output, then:
rise with attack-time
reset hold counter to N frames
sample the output with a S&H
else if input is lower than output, then:
if hold counter is zero, then:
decay with release-time
else if hold counter is still counting, then:
output the signal from the S&H above
end if
end if
--
/Jonatan
http://kymatica.com
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Faudiostream-devel mailing list
Faudiostream-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
