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 Faudiostreamfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/faudiostream-users