Supercollider dev question

[Tony Hardie-Bick]

On 26/10/11 14:25, Marc Nostromo [M-.-n] wrote:
>
> I guess I could try myself but since there's people here working with SC, I'll
> take the lazy way :)
>
> Can anyone tell me what's the dynamic range of the audio representation in
> SuperCollider ? My current framework is currently using a fixed point reflection
> of 16bit range (i.e. +/-32767) but I was wondering if +1/-1 wouldn't be better.
> The main point would be that implementing signal multiplication (for
> modulation,ring mod, and so on) wouldn't need some kind of additional processing
> to normalise the result.
>
> Anyone with a clever point ? :)

Well, I can try ;)

Prob this is getting a bit tech. for the list. OTOH, if I say something dumb, 
others can correct me :)

sc uses single precision fp for all its audio and control data, ie, 24 bits of 
precision (if you include the sign) plus 8 bits telling you the range these 
values cover.

it's also possible to use other formats within a ugen, which is important if you 
really want transparent audio quality from an algorithm that includes feedback 
(filters, reverbs etc). sc generally sounds better than some other single 
precision platforms, like max and pd, so clearly implementation is as much of an 
issue as precision, and precision must be used wisely to gain the best 
performance and quality without ending up with an abused cache and not much 
advantage (particularly on ARM).

so, to fixed point....

in theory, fixed point 32bit will give you better than single precision floats, 
because, obviously, the precision is 32bits rather than 24. However, the 
difference becomes *very* significant, if you can code a 32x32->64 multiply 
accumulate, and keep the 64-bit product sitting around during a calculation.

obviously you can do such things using whatever numerical range you like, but if 
you really want to get your framework absolutely rock-solid, and somewhat ready 
for the inundation of cheap ARM cheaps that's going to engulf the planet in the 
next couple of years, then:

1/ you should go over to a (symbolically) fractional numerical range

but for DSP work, you really gain a huge advantage from 32bits, because you can 
afford to extend the range from +-1.0 to, say, +-8.0, and this gives you a 
considerable advantage because many calculations (accumulations of signals in 
filters, etc etc) easily trip over the unity magnitude limit, and (while I know 
some love this kind of distortion, I reckon it should be deliberate, rather than 
the result of sloppy DSP) you can avoid having to take extreme care with every 
calculation, if you have this extended range.

when i was thinking about ARM, i reckoned a range of +-16 or +-8 was good, and 
you still end up with a wonderful precision, and if you have the MAC operation 
to hand, then really, you should be able to code the best sounding audio in the 
world - actually better than double precision fp, because even double precision 
fp cannot accumulate products to more than 54 bits, unless there is a 
specialised DSP MAC operation.

regarding the MAC operation - you may be wondering what you do with all those 
bits. You keep them around until you're finished accumulating, and then you 
truncate with dither.

if you do this, you're framework will be awesome, and there will be a distinct 
absence of sloppy DSP code.

it really depends on what you're after. if you're happy with the usual DSP 
platform distortions, that can be heard in a huge range of products, then such 
matters will not concern you, and these are obviously a feature within the 
chiptunes context.

if you want to compete with MOOG's new software (in terms of quality), then you 
have no choice. and if you want both, then your platform will require this kind 
of attention to detail, because adding distortion is easy. removing it without a 
rewrite from the ground up, would be impossible.

as to novelty - you're in a great position, because sc (which i admire) and 
other platforms are using floating point, whereas fractional fixed point gives 
you great possibilities for making very efficient use of the ARM 32-bit 
architecture.

one other note: one can implement fractional fixed point with an arbitrary 
precision, ie with a template which can specify the location of the binary point 
(such libraries exist, although I'd suggest you write your own), so if you 
decide you need to use more or less precision in a particular calculation, its 
available to you. These various types are remarkably compatible; one simply adds 
the number of integer bits to determine a shift in a product, for example. 
Preferably one sticks with one particular integer size, simply to avoid 
unnecessary shift operations, until these are actually necessary.

Tony (HB)