I vote in favor of some standard suffix that means "normalized to
standard volume at full scale and standard presentation level".  Since
it's such a small variation (osc_normalized = osc *
normalizingScaleFactor), I vote for defining them immediately after
the definition of the function being normalized, in the same library.

- Julius

On Tue, Mar 13, 2018 at 2:20 PM, Mykle Hansen <my...@mykle.com> wrote:
>
>> On Mar 12, 2018, at 2:14 PM, Julius Smith <j...@ccrma.stanford.edu> wrote:
>>
>> Hi Mykle,
>>
>> Thanks for sharing your normalizing gains.  As the author of gnoise
>> and pink_noise, I am happy to add two functions to noises.lib such as
>>
>> pink_noise_m = pink_noise * 12.5; // Equalizes loudness to that of
>> no.noise (thanks Mykle Hansen) - beware clipping!
>>
>> gnoisem = gnoise * 0.625; // Equalizes loudness to that of no.noise
>> (thanks Mykle Hansen)
>>
>> where the "m" suffix means "matched loudness" or something like that.
>> Can anyone think of a better naming convention?  Another possibility
>> is "z" for zero-db-loudness, etc.
>
> Hi Julius,
>
> That would be great.  But, OTOH, I should mention that I also needed to do 
> this
> for os.oscsin, which has a normalizing coefficient of 0.8 compared to 
> no.noise.
> So I think a solution that extends across libraries is worth considering,
> if it's not too complicated.
>
> (Also, standardizing everything to the 0dB level of os.oscsin makes at
> least as much sense to me as using no.noise .  I have no preference.)
>
> Since the library system was reorganized last year (very nicely
> IMO), I’m sure the main language contributors have given though to
> standardizing the names and forms of functions.  So I defer to y’all,
> and I would be happy to see any update you suggest.
>
> But if this is a feature that not many people are likely to use,
> one might favor keeping it all in a separate library (zdB.lib ?) that
> wraps & re-exports any functions that want normalizing.  Then it can
> all be documented in one section, it can address the levels of any
> current or future generator in any library, and it won’t clutter the
> rest of the codebase, namespace or documentation.  I would be
> happy to contribute that.
>
> Thanks for considering this,
> -mykle-
>
>
>



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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Reply via email to