What, never? I see a few problems with this:

you will need to normalize the data in order to play it on a real-world sound
card - and be limited by that card's resolution;

A floating-point number does not have unlimited precision (especially the 32bit
variety), so it is not too hard to make Csound create numbers that are
pathologically small or huge. I have recently found a hitherto dormant bug in
the standard implementation of the phase vocoder - in the resynthesis, floats
are used to store the accumulating instantaneous frequency of each bin.
Eventually the numbers get too big, and overflow, and the audio progressively
distorts. Depending on the system, this may happen after about 15minutes of
performance, or later - but it will happen. By changing the calculation to keep
the value wrapped around (dare I say it, 'normalized' to) 2*PI (as is done in
the analysis stage), the problem disappears.

The range of amplitudes becomes crucial when any non-linear processing is
carried out on the signal. For example,  when squaring a sample, or otherwise
raising it to a power, with normalized values (+- 1) the result will always
remain normalized. As soon as values exceed 1, amplitudes can grow without bound
(this is the basis of the 'nlfilt' opcode, for example). Such processing is by
no means esoteric: taking the square root (then restoring the sign of the
original afterwards) boosts low amplitudes in relation to high ones - if applied
to the normalized amplitude envelope, a possible basis for a 'maximizer'. 

A floating-point number is really little more than a bigger saucepan - it can
still boil over.

So, let it be 'hardly ever...' instead.


Richard Dobson


Matt J. Ingalls wrote:
> 
> my hope is to move to using floating pt. files ALWAYS in EVERYTHING
> you would never normalize again...

> you will need to normalize the data in order to play it on a real-world sound
> card - and be limited by that card's resolution;

	of course-but from a "user" point of view there would be no
normalization-the playback would just be "right" leaving her file
untouched

> A floating-point number does not have unlimited precision (especially the 32bit
> The range of amplitudes becomes crucial when any non-linear processing is
> A floating-point number is really little more than a bigger saucepan - it can
> still boil over.

	your right, but again i was thinking from a user point of view.
It is the process' problem for handling overflow - but it shouldnt matter
to the user one bit-as long as it spits out a float file containing the
proper peak value- think of this as "never" normalizing or "always"
normalizing its the same thing

	(this kind of spills over from the music-dsp discussion on AIFF-C
and WAV format for floating pt files).  I guess what i was trying to say
in my previous comment about "hoping that EVERYONE uses floats ALWAYS" was
that i hope floatingpt w/ peak value stored becomes a standard use - and
every application just knows to handle the data with the peak value ALWAYS
(in fact soundin/diskin/loscil/gen1 should have options to either
autmatically normalize to peak value in AIFF-C/WAV float or someway to
return that value inside an orc)
- whether that means doing the divide to "normalize" while processing or
whatever - this will save on calculation times as normalizing always has
to do be done as post-process--so should just wait till it is
needed(during next process/playback) then immediately after..

-matt