Supercollider dev question

[Marc Nostromo [M-.-n]]

>
> the balance of 17/15 is fair enough... it gets you less precision than fp,
> though, and... do you use all 17 integer bits? quite possible you do, but if
> not, I'd definitely give myself 24 or more for the fraction. for high
> quality you definitely need >=22 fraction bits.


I'm still a bit confused :)

Suppose I'm using 17/15 like now and my representation of the 'audio' range
(a sample) being +/- 32768. That means that a standard operation on a sample
uses the following bits ( 'i' is the integer part, 'f' the fractional)

0iiiiiiiiiiiiiiii.fffffffffffffff

now, if I use 30 bits for the fractional part and range my audio sample to
be between -1/1 I will use

0i.ffffffffffffffffffffffffffffff

sure, I have more bits in the fractional part but the dynamic range of what
I can represent with respect to the waveform stays exactly the same (31
bits).

The only part where I could see a gain would be if you want to model another
signal (let's suppose it's a gaussian noise) that is in the [1,0] range and
you don't want to scale it and therefore have a loss of resolution there. On
the other hand, injecting a [0 1] signal into a +/-32768 scale isn't the
same as injecting it into a +/- 1 range signal.

Inherently, what I feel is:

1- you have 32 bits available to represent your numbers. No matter where the
'dot' is.
2- you want the audio signal to use a 'major' proportion of the number
representation and that's where the choice is the most important. Something
like 'I need 24 bits for a standard audio signal' (allowing for 8x overshoot
in calculation). All the rest is *relative* to the number of bits you chose
for your signal and not the value it represent (i.e  in the end, it's all
the same :)

I think I'll anyway choose for a +1/-1 audio representation allowing 24 bits
for the fractional part, but I'm still not convinced it's worthwile :)

[snip] whatever you want to create in the future is entirely unlimited by
> the code you have laid down.
>

or 'limited'

:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.music-bar.org/pipermail/music-bar/attachments/20111026/502376d7/attachment-0002.html>