josmithiii
commented
4 years ago Hi Dario,
Below is our previous thread.
I am fine with "peak envelope", if that name is at least reasonably well established. (It's also a good functional name.)
I vote strongly against "balancing function". I have been in the field of computer music (with Dodge and Jerse) for more than four decades, and I have never seen or heard it used. I vote for "RMS envelope", as "RMS level" is very firmly and widely established, so audio people of all kinds will readily understand it.
Also note that "peak and rms envelope" pairs well with "peak and rms meters", which are also very widely established.
In my opinion, we should not break old code. Instead, after amp_follower, just provide a new synonym:
peak_envelope = amp_follower;
shouldn't the RMS functions be moved in the analyzers library?
Why not the library envelopes.lib ?
- Julius
Earlier thread: From: Julius Smith jos@ccrma.stanford.edu Thu, Jul 18, 2019, 5:43 PM Reply to all to Dario Yes, this is a fundamental trade-off. I normally set it as close as I can to human perception (according to critical bands of hearing). Then there can be more processing beyond that, which of course happens in the brain.
On Thu, Jul 18, 2019 at 2:24 PM Dario Sanfilippo
sanfilippo.dario@gmail.com wrote:
I did try it for onset detection but it's not stable enough when you push the responsiveness high, which is what you'd need for small transients. There's a tradeoff: the faster the responsiveness, the more significant the oscillation around the equilibrium point. I can't remember what the stability limit is but setting the analysis above 10ms (100Hz as the parameter is in Hz) it's less stable and reliable. I guess that the Gabor limit applies to time-domain measurements too and not just FFT.
I can perform some tests and plot the results if you're interested.
D
On Thu, 18 Jul 2019 at 23:06, Julius Smith jos@ccrma.stanford.edu wrote:
That's a nice dynamic "brightness follower" - good for transient detection, e.g.
On Thu, Jul 18, 2019 at 1:01 PM Dario Sanfilippo sanfilippo.dario@gmail.com wrote:
On Thu, 18 Jul 2019 at 21:46, Julius Smith jos@ccrma.stanford.edu wrote:
I believe the power below balances the power above, IIRC
In my algorithm, yes. I do high_spectrum_rms - low_spectrum_rms. So the sign of the difference tells towards which direction the crossover cutoff should move, and the magnitude tells how far from the equilibrium it is. As a typical negative feedback configuration, the system finds a dynamical equilibrium point and minimally oscillates around the equal-power cutoff.
So I'll change my writings and I'll talk about power when discussing RMS. Thanks for the hint.
Dario
On Thu, Jul 18, 2019 at 11:50 AM Dario Sanfilippo sanfilippo.dario@gmail.com wrote:
Hi, Julius.
Yes, it was a typo: I meant MEDIAN against AVERAGE.
I perfectly understand that studying the code might be too much.
As I said, the algorithm simply finds the cutoff of the crossover where the RMS values of the outputs are the same. So it is a balancing point, which would make think of a centroid, but I'm not too sure.
Thanks, Dario
On Thu, 18 Jul 2019 at 20:44, Julius Smith jos@ccrma.stanford.edu wrote:
Mean and average normally mean the same thing.
RMS is the square root of the average power, not energy.
Happy to answer any specific questions, but studying code goes outside my time allotment for email (I spend WAY too much time on email!)
On Wed, Jul 17, 2019 at 3:57 PM Dario Sanfilippo sanfilippo.dario@gmail.com wrote:
On Thu, 18 Jul 2019 at 00:35, Julius Smith < jos@ccrma.stanford.edu> wrote:
Hmmm, I have never heard the term "spectral tendency". A very common term is "spectral centroid". Are they related?
Well, the centroid is one form of spectral tendency. I did formalise the algorithm with difference equations for an article but my math understanding is not good enough to determine if it's a weighted mean or a weighted average (centroid).
The algorithm is an adaptive mechanism that finds the cutoff of a crossover whose RMS of the two outputs is roughly equal. So it is a balancing point, and intuitively I'd say it's like a spectral centroid, but I believe I compared the FFT centroid and my algorithm and they don't quite match in all cases. A guy from the music DSP list claimed that it is a weighted median but he didn't explain why.
I'm attaching the Faust code of the algorithms without dependencies. Perhaps if you have a look at the diagram you can see if it's more of a weighted median or average. If you could explain why that would be great.
Thanks a lot, Dario
I should have seen "balance function" since I own a copy of Dodge and Jerse, but it appears not to have taken hold. I think "average magnitude" would be a nice name.
With Zolzer's use of peak envelope, I am happy to switch to that.
It occurs to me that max(peakEnvelope, averageMagnitude) could be nice to use, blending longer-term averaging with peak sensitivity.
On Wed, Jul 17, 2019 at 1:41 PM Dario Sanfilippo sanfilippo.dario@gmail.com wrote:
Hi, Julius.
For the name peak envelope, we could reference Zölzer's DASP from 2008, page 229. For the rectifier followed by a LP, we could reference Dodge and Jerse's Computer Music, page 181. They call it "balance function" and they describe it as an approximation of average power. Usually, I see RMS being linked to the average energy. So we might choose names based on those references.
Also, as an alternative technique to that implemented in the libraries for RMS calculation, the input can be squares, averaged with a one-pole LP, and then passed through sqrt. For this, we can reference Zölzer too.
I designed a spectral tendency algorithm which is in my libraries that works with a 1p1z crossover, 3 rms units (like those I described above), an integrator, and a couple more multiplications. I must say I'm really happy of how well it works given the computational non-aggressiveness. I'm attaching a couple of plots here to give you an idea. Perhaps we can add that in analyzers.lib? Of course, I can implement a version without dependencies on my other libraries.
The plots show two tests with a 1k sine and white noise at 96kHz. The responsiveness of the system is 15Hz
Cheers, Dario
On Wed, 17 Jul 2019 at 21:46, Julius Smith < jos@ccrma.stanford.edu> wrote:
I like the name "peak envelope", but I have never seen it. However, my knowledge comes from my analog synth DIY days in the 1970s! I never got deeply into compression/limiting/mastering/etc., in part because two other faculty at CCRMA have an entire course on it, plus associated research.
An absolute value can be called a "full-wave rectifier", done in analog using a diode bridge. Lowpassing that is the standard AC-to-DC conversion for power supplies (plus a voltage regulator chip nowadays). It could be called "root mean abs" (RMA) but I've never seen that either. People seem to use it interchangeably with RMS, but it's L1 norm instead of L2 which matters sometimes.
It would be great if someone wanted to overhaul the names in the Faust libraries to make them ideal. We would introduce the new names and retire the old names to a compatibility include.
Cheers,
- Julius
On Wed, Jul 17, 2019 at 2:27 AM Dario Sanfilippo sanfilippo.dario@gmail.com wrote:
Hi, Julius.
I was gonna suggest that too; I usually combine it with a 1-pole LP at the end to smooth out the attack. Also, RMS wouldn't prevent clipping in full-amplitude signals.
I was wondering, is there a name for a lowpass which simply processes the absolute value of the input? I sometimes see that one named "amp follower" and the zero-delay attack with exp. decay "peak envelope", but I guess it might change from author to author.
Cheers, Dario
On Wed, 17 Jul 2019 at 01:48, Julius Smith < jos@ccrma.stanford.edu> wrote:
To get around the delay problem, you could consider an.amp_follower(). It is based on the typical amplitude envelope follower used in analog (zero delay rise to peaks, exponential decay after each local peak)
On Tue, Jul 16, 2019 at 2:07 PM Bart Brouns < bart@magnetophon.nl> wrote:
Hi Benoit,
Sorry for the late reply.
I originally wrote slidingRMSn for usage in compressors, which is in essence what you are doing, so this is certainly an option.
The downsides of using it here are:
You have to wait a bit for an estimate of the loudness, so it's always late. With smaller values of N you get faster reaction, but also more distortion.
If you can find a way to predict the level of your synth before you make the sound, it will sound better, cause you then could avoid these problems.
If you want to use slidingRMSn, I suggest you look at https://github.com/magnetophon/faustCompressors and in particular
https://github.com/magnetophon/faustCompressors/blob/master/RMS_FBFFcompressor_mono.dsp Note: they where written before slidingReduce was merged upstream and I haven't adopted them yet to the new libs, cause I wasn't able to package the new faust release for my distro yet.
As to your other questions:
maxN is a necessary implementation detail: faust needs to know the maximum length of a delayline before it can create it. N can be the same as maxN if you want. It's just that maxN needs to be known at compile-time, and N can vary continuously during use if you want. Choosing N is the hard part. It makes sense to have it related to your lowest freq, but the best value you'll have to determine by ear, afaik. In other synths I've gotten good results by setting the decay-time of the built-in limiter per note.
Hope that helps, let me know if you have any other questions!
Cheers, Bart.
Benoit Delemps benoitdelemps.add@gmail.com writes:
Hello everyone,
i am trying to build the additive synthesis module like illustrated in this example.
https://faust.grame.fr/doc/tutorials/#additive-synthesis
The thing is that the normalization applied at the end of the signal (dividing by the number of harmonics) prevents overloading but in the same time reduces drastically the level output if the energy in the spectrum is low.
So instead of dividing by number of harmonics, i choose to divide by ba.slidingRMSn to prevent overloading and maintain the level ouput.
And here are my questions.
- using slidingRMSn, is this the "good" way to normalize ouput knowing i want to maintain the level output even if i drop some harmonic's energy?
in the documentation, we got: usage
: slidingRMSn(N,maxN) :
- What is the purpose of maxN ?
- N has to be different of maxN ?
- And last question, how i choose N ?
I tought i should do that: nextpowerof2(Fs / 2*lowest frequency) but that doesn't work well at low frequency. So i did that instead: nextpowerof2(Fs / lowest frequency) works fine but don't know really why
here is a sample of my code:
additiveSynth = freq <: par(i,nHarmonics,oscilator(i)):><:,( : ba.slidingRMSn(512,512)) : / :> *gain : envelope with{ freq =
vgroup("[0]control",hgroup("params",hslider("fundamental[style:knob]",440,125,3000,0.01))); gain =
vgroup("[0]control",hgroup("params",hslider("gain[style:knob]",-10,0,-100,0.01): ba.db2linear())); gate = vgroup("[1]control",button("gate")); envelope = *en.asr(0.35,1,0.35,gate); nHarmonics = 10; };
I thank you for you help
bests
Benoit _ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
--
Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/
Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
--
Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/
--
Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/
--
Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/
--
Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/
--
Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/
--
Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/
On Mon, Apr 27, 2020 at 5:57 AM Dario Sanfilippo notifications@github.com wrote:
I vaguely remember discussing this with Julius but I can't find the conversation in my inbox.
I am used to seeing the function "(an.)amp_follower" being called "peak envelope."
On the other hand, amplitude tracking implemented as rectified and low-passed signals, RMS, or instantaneous amplitude are sometimes called "balancing function" (Dodge and Jerse) or "envelope detector" (Wikipedia).
Do you have any information on these naming conventions?
A different but related matter: if doing so wouldn't break any other piece of code, shouldn't the RMS functions be moved in the analyzers library?
Cheers
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/grame-cncm/faustlibraries/issues/33, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQZKFIEFSJZN4M5RS6NBMTROV6M3ANCNFSM4MR4YWGQ .
-- Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/
dariosanfilippo
sletz
I vaguely remember discussing this with Julius but I can't find the conversation in my inbox.
I am used to seeing the function "(an.)amp_follower" being called "peak envelope."
On the other hand, amplitude tracking implemented as rectified and low-passed signals, RMS, or instantaneous amplitude are sometimes called "balancing function" (Dodge and Jerse) or "envelope detector" (Wikipedia).
Do you have any information on these naming conventions?
A different but related matter: if doing so wouldn't break any other piece of code, shouldn't the RMS functions be moved in the analyzers library?
Cheers