Supercollider dev question

[Tony Hardie-Bick]

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

ok i think this is the heart of your question... yes, get the code written so 
the normalisation (ie shift) is hidden and implicit.

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.

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

when you multiply two numbers together, eg 16x16, you end up with twice as many 
bits, eg 32. A MAC (multiply-accumulate) operation is used when the results of 
two or more products need to be added together without losing precision. Same 
applies with 32x32->64: you accumulate the results in a 64 bit register (bit 
messy in portable C, fairly elegant in assembler).

i really don't think this is necessary, if your goal is less than extreme 
quality. otoh I know your coding is extremely sound (pun intended), and, i 
dunno, if you want to make it really future-proof, something that might find its 
way even further than your existing well-defined target, then taking this stuff 
into account may be worthwhile.

btw MAC is a native operation on DSP chips, and also in some of the vector 
instructions on Intel and ARM (not *entirely* sure to what degree this is 
supported, but probably it's there for floats). basically in any significant 
amount of audio code, you'll find a portion of operations that are MAC 
operations, and if you go the extra mile, then *every* audio multiplication 
involves at least one MAC, because you need to add in some noise to do the 
dithering... (I'm not explaining this fully, cos it may not be all that helpful 
to go into complete detail).

> I, personally, don't want to compete with moog, and much of what I like relies

well, i don't think there's much point, because they're doing a great job there. 
what I mean is that, they really have laid down a benchmark in terms of audio 
quality (i think the code sounds better than the iMS20, although both filters 
capture a lot of their respective analogue originals' behaviour), and if you 
ever wanted to aim for that level of quality, it would be nice to have a 
framework ready and waiting. although i think probably sc is a good framework, 
and three yrs from now, no big deal for the available CPUs.

for example, the iMS20 code requires more than a tweak, probably. Entire 
frameworks of commercial products (i shall mention no names), have actually 
suffered this disconnect, and needed a rewrite of a very large code base....

other examples: pretty much all commercially available synth hardware ignores 
these matters completely.

> 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

yeah - that's why I'd say write your own. it's not a lot of code.

> Thanks for the insight.

i think i could explain it more clearly, but not so quickly... ;)

-

Actually, underlying it is something i perceive as a poetry of numbers making 
sound, and it appears effortless and amazing that there is this virtual world, 
which cpus are capable of creating, where everything is smooth and clear to the 
ear, and where whatever you want to create in the future is entirely unlimited 
by the code you have laid down.

admittedly the one example i can cite of this, took a good while to write.

and it (DFM1) would still sound just great, if you keep the internal precision 
really high, and use 16-bits in and out. you'd probably want to preserve the 
quality of the output (even if it's just 16 bits, there are ways of preserving 
the quality), if you want the thing to sound like an analogue filter when it's 
actually part of the main mix. This is where it gets interesting ;)

if you don't need analogue, maybe you could scavenge bits (pun intended) of DFM1 
and just get a good screaming filter.

Tony (HB)