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:
1) You have to wait a bit for an estimate of the loudness, so it's always late. 2) 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....@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:
next_power_of_2(Fs / 2*lowest frequency)
but that doesn't work well at low frequency.
So i did that instead:
next_power_of_2(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

Reply via email to