<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">1/ you should go over to a (symbolically) fractional numerical range<br>
<br>
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.<br>
</blockquote><div><br></div><div>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).</div>
<div><br></div><div>My original question (which is kind of rethorical but still) was: if I had to choose between</div><div><br></div><div>1- fixed point limit +/- 8 with a 'standard audio dynamic' of +/-1</div><div>
<br></div><div>or</div><div><br></div><div>2- fixed point limit +- 262.144 with a 'standard audio dynamic' of +/- 32768 (also allowing a 8x overshoot)</div><div><br></div><div>Is there one that is better than the other ?</div>
<div><br></div><div>Intrisically, both have the same capabilities and precision but when you do</div><div><br></div><div>fp_mul(a,b)</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.<br>
</blockquote><div><br></div><div>What's MAC operation ? Never heard of it before. And yes, I want to run on cheap arm :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.<br>

<br></blockquote><div><div><br></div><div>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 :)</div>
</div><div><br></div><div>( with the added bonus it's always interesting to ready your replies ^^ )</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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

<br>
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.<br>
</blockquote><div><br></div><div>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</div>
<div><br></div><div>Thanks for the insight.</div><div>Marc.</div></div>