Supercollider dev question

[Marc Nostromo [M-.-n]]

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

Do you mean something like using 32x32 as default fixed 'representation' but
that if your processing implies a multiplication you have another type that
uses 64 and keep playing with that one until you are finished with your
processing (or need another multiply) ? In theory is seems valid, I'm just
wondering how tricky the code might end up with. It's an interesting point,
I don't know if any of my current processing is good enough to justify it
but maybe when I get to port the DFM code, I'll keep that in mind.



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

Maybe there's something I didn't explain thouroughly. My current framework
uses a fractional representation with 17bits for the integer part and 15 for
the fractional part. So I've got a range of +/- 65535 and chose to represent
the 'bus dynamic' of my audio to +/- 32768 (i.e. at the end of the
computation, when it's sent to the audio card, any part of the wave above
that level will be clipped). This gives me the possibility of x2 overshoot
during processing (which I agreed might be extended and that a factor 8
looks goood).

My original question (which is kind of rethorical but still) was: if I had
to choose between

1- fixed point limit +/- 8 with a 'standard audio dynamic' of +/-1

or

2- fixed point limit +- 262.144 with a 'standard audio dynamic' of +/- 32768
(also allowing a 8x overshoot)

Is there one that is better than the other ?

Intrisically, both have the same capabilities and precision but when you do

fp_mul(a,b)

if a and b are in the +/-1 range you don't need to normalise them to stay in
the +/-1 range while if you use 32768, you do.



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

What's MAC operation ? Never heard of it before. And yes, I want to run on
cheap arm :)


> 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.
>
>
I, personally, don't want to compete with moog, and much of what I like
relies on artifacts. On the other hand, if the goal is to provide a
framework that can last and cope with as much versatiliy as possible, I
don't find it to be a waste to think that one day someone might want to do
some hi quality stuff with it and I'd rather put the effort now when I got
only a few modules at hand than when I have to port 20 of them :)

( with the added bonus it's always interesting to ready your replies ^^ )

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

I know about templatized versions for fixed point library. My biggest
concern with them was the introduction of possible inefficiency due to their
generality. I've never taken the time to benchmark them though

Thanks for the insight.
Marc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.music-bar.org/pipermail/music-bar/attachments/20111026/4f5d6b0c/attachment-0002.html>