Supercollider dev question

[Tony Hardie-Bick]

On 26/10/11 17:37, Marc Nostromo [M-.-n] wrote:
>     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 :)

i'll pop over to berlin once you're moved in, and it'll become perfectly obvious 
in less than one espresso.

> 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).

yeah, correct. it's a bit subtle, and it really is down to metaphor. what we're 
doing here is taking a step away from the bits themselves, and more into the 
maths domain, which, the engineer in me doesn't like, although i have found it's 
worthwhile if you're writing for more than one numerical format or one 
particular chip.

> 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.

like I say, it really is more about metaphor than what's happening in the chip, 
and yeah, if that sounds suspicious, i reckon it fundamentally is. all maths is 
suspicious until you can describe it as bits moving around a circuit.

> 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 :)

I would almost certainly go for that. I think it's probably not worthwhile right 
now, but if you can get the code working with it, and totally compatible with 
swapping to floating point (or whatever) in the future, then i think you give 
your framework something valuable.

Perhaps I'll hold off on my suggestions for loading every audio multiply with 
gaussian dither, although I did wonder about writing it so that each audio 
multiply is a member function which could, either as a compile or run-time 
option, actually do all that..... like, even to an extreme.... ;)

> or 'limited'

by time? ;)

Tony (HB)