From the original SynthMaker forum (2004–2014), with its members’ names and dates.
MegaHurtz ·
Is there a way to gauge bit depth in a schematic. Tho a patch may be running 32 bit the output of 1-(1/32^2) seems to just add up to 1. I need this to calculate a sine with the most accuracy, since 0=0 and 1=0. you get a chance on a double zero every cycle. And the difference is just 1 bit less than 1. Bit lost here..
MegaHurtz ·
Doh nevermind.. Just wasted some time 😀
MegaHurtz ·
Tho it can be very useful for computing reciprocals and such. Any tips for this?
trogluddite ·
MegaHurtz wrote: Tho a patch may be running 32 bit the output of 1-(1/32^2)
I am guessing that you mean 1-(1-2^32) - i.e. changing the final bit of the 32bit number does not change the output. If so, then this is what I would expect, because SM uses 32bit float numbers. Although the range of numbers available is very large, the way the numbers are represented means that there are only 24 significant bits (including one hidden "normalising" bit). The other eight bits are used to store the sign, and the exponent (order of magnitude) of the number. So depending on the exponent, numbers much larger and smaller than will normally fit into 32bits can be represented - but only with 24 significant bits - the precision scales with the magnitude of the numbers. As two number get further apart in magnitude, fewer and fewer bits of the smaller number will appear in the result - if they differ by more that 2^24, then the smaller number just disappears.
MegaHurtz ·
That is the case for a raw 2^32 calculation. Only it seems to be bound to happen on a 16 bits digital to analog conversion of a 24 "bits" number. (on streams) So now im wondering if this would be a thing that`s purely of a graphical nature. But gee i guess ill have to make a patch tomorrow to figure this out. Ill post it when its final.
trogluddite ·
IMHO, the algorithm that you want to use is at least as important than the output format for the precision that you need. For example... If you generate a sine by using a lookup table, then the need for extra precision is not so great. The data has already been calculated, and will play back exactly the same every cycle. OTOH, if you generate a sine wave using a recursive algorithm (variables in a feedback loop), you might want much more precision because the tiny errors accumulate over time and could make the oscillator unstable eventually.
Anyhow back on topic? After I looked at your question again, it seems I went a bit off track - it's not the output resolution, but the angle/time resolution that is the problem, yes? That depends which sine function you are using... From your post I guess you mean the code sin1() function - this is just a look-up table which has 65536 values - the values themselves are precise, but there are only 2^16 of them! I'm not certain, but I imagine that the stock sine oscillator probably uses the same lookup table (the stock oscillators are all tables of some kind). AFAIK, the "green" sine primitive uses the proper FPU instruction, and so is very accurate - it should be pretty much bang on for any float input. The more accurate float sines should also be possible in assembly (it has the "fsincos" FPU opcode) - but in this case, extra accuracy = lots of extra CPU, especially as it is not an SSE instruction; not something you want running at stream rate unless absolutely necessary.
You could use the green (or fsincos) sine to make a more accurate lookup table. In this case, it is the address space that is the limitation. You need a 32bit integer to point to the correct memory address where an array item is stored Each entry in the array needs 16 bytes (4 bytes per 32bit float * 4 SSE channels). As it's very unusual for tables to have negative indexes, the sign bit is no use to us. So, the biggest table that you can index properly will have 2^(32-4-1) = 2^27 entries
MegaHurtz ·
It started out as a bit of a misconception, since I need to use the fsin function as it is for it`s circular nature. So i was looking to do a ramp that did`nt hit 1 ever. (wasting time because it did`nt already) and the space inbetween is just 1. But i revived it because a cilpper based reciprocal does have this issue. And subtracting one bit worth from 1 seems to be the fix. But here you either have to know the bit depth you are at, or subtract two bits to be shure. But then again I have to test if this is the case still. Since its a 32 bit format..
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker