From the original SynthMaker forum (2004–2014), with its members’ names and dates.
TheAudiophileDutchman ·
Let's start a new thread 😉
Recently, I came across a few issues with the SM functions Sin1 & Cos1 (which have already been reported directly to the Devs last week):
1. These functions are not working (yet) in Stage(0) of a code module.
2. Generated assembler code yields a large footprint, because of multiple FPU <-> SSE instructions with conversions... (max. code size has been increased in v1.06 though)
In general, the calculations are FPU single-precision accurate, but also quite slow.
The above made me browse for an alternative that is (arguably?) better than a regular Taylor approximation in terms of speed and accuracy and yields a small footprint in SM. http://www.devmaster.net/forums/showthread.php?t=5784
Please do let me know for which audio DSP areas you think this is a 'good enough solution' and if/where you see any further room for improvement(s).. Benchmarks would be great. 😇
// SSE SIN-COS: from Devmaster forum, adapted for SM by TheAudiophileDutchman
polyin angle;
polyout out;
float absmask=0;
float F3P4eA038=3.4e+038;
float F0P999999=0.999999;
float F0P1=0.1;
float B=1.27324;
float C=-0.405285;
float P=0.215; // min. absolute error
float pi=3.14159;
float npi=-3.14159;
float pi2=6.28319;
float hpi=1.57080;
If you're using the asm module you can input integers directly, so no need to to the fancy absmask calculation (which is only because we can't input integers in the code module).
Instead just use:
int absmask=2147483647; // 0x7fffffff
I'll have a peep at the rest of the code in a bit..
Sam
exonerate ·
i've just tested the code, and it's not a good approximation of a sine, have you looked at it with an analyzer?
when i feed a ramp though it, i got a ramp coming out of it with a very slight curve, but not enough to change the sound of the ramp, when feeding a triangle though it i could see it was curved slightly, but this is no way usable as a sine approximation.
are you sure you have implemented it correctly?
anyway CPU usage for it is good, in SM i'm getting about 0.6%.
In the task manger i couldn't really tell because it was moving between 1 - 2%
cheers 😉
infuzion ·
There are some links to the CPU technical docs that have the instruction cycles listed, so you can see how many cycles are saved:
[old link]
BTW, If you're using sin1 for a mono signal, you can use the SM non-SSE coding for sine, & knock out the math for the other 3 channels.
You can jump on a graphics programming form to find more that will help; math is math.
TheAudiophileDutchman ·
Thanks for your feedback so far, guys! 🙂
I'm going on a city trip with my girlfriend today, so I'll be back by the time of tomorrow...
TheAudiophileDutchman ·
As promised:
@Exonerate: you were quite right concerning the quality of approximation; the updated code below does come very close to the ideal sine! That is because, by trial and error, I found that a better C value is -0.282 for a sin1/cos1...do try to falsify this again, ok?... 😈 😉
@Sam: thanks, the absmask implementation looks better now and the code footprint has become even smaller 🙂
@Infuzion: I promise to start counting instruction cycles from now on 😇
To all: any further suggestions and findings are welcome, so please perform your analysis one more time on this improved version!
// SSE SIN-COS: from Devmaster forum, adapted for SM by TheAudiophileDutchman
polyin angle;
polyout out;
int absmask=2147483647; // 0x7fffffff;
float B=1.27324;
float C=-0.282; // Optimized by trial and error, instead of taking -4/(pi*pi)
float P=0.225; // min. absolute error
float pi=3.14159; // should be 1
float npi=-3.14159; // -1
float pi2=6.28319; // etc.
float hpi=1.57080; // etc.
Please note that that there's at least still some work to do on the ranges (preferably getting everything to work safely within the same boundaries as sin1 and cos1, i.e. between -1 and 1)
infuzion ·
Yea, I've spent prob 5 hours alone researching the fastest instruction routines to see what set is faster than others. Tricky thing is, AMD processors tend to take sometimes more sometimes less cycles for the same instructions that Intel do. And the Core processors seem to use MUCH fewer cycles for the same SSE commands that a P4 would. So you have to target one, but be aware of the other processors.
Edit: Just test this to get the Absolute Value; works like a charm!
streamin i;streamout o;
int absmask=2147483647; // 0x7fffffff;
movaps xmm0,i;
andps xmm0, absmask;
movaps o,xmm0;
TheAudiophileDutchman ·
@Infuzion: I'm glad the optimized absmask solution works for you too 🙂
In the meantime I've corrected the parabola-coefficients in order to get Sin1/Cos1-like range-behaviour. Absolute accuracy currently seems to be in worst-case <0.001 (3 digits), which could be sufficient for many purposes...
// SSE SIN-COS: from Devmaster forum, adapted for SM by TheAudiophileDutchman
polyin angle;
polyout out;
int absmask=2147483647; // 0x7fffffff;
float B=4;
float C=-4;
float P=0.225; // min. absolute error
float pi=1;
float npi=-1;
float pi2=2;
float hpi=0.5;
heres a picture of the approximation and SM's stock sine osc......
looks exactly the same to me, can you guess which is which?
i don't know what you've done TheAudiophileDutchman but that is a massive inprovement, over the first example you posted.
i will definetley be able to use this 🙂
thankyou 😀
TheAudiophileDutchman ·
i don't know what you've done TheAudiophileDutchman but that is a massive inprovement, over the first example you posted.
Actually, the only major change is that one full period range of the sine/cosine is now complying with the SM audio standard [0..1], instead of the general math standard [0..2*Pi]. By the way, it is possible to tweak at least part of the code (as listed above) a bit further, effectively using only 4 multiplications in total, while keeping similar accuracy and footprint: 🙂
TheAudiophileDutchman wrote: Actually, the only major change is that one full period range of the sine/cosine is now complying with the SM audio standard [0..1]
I thought the SM audio standard was -1..1, I think same as VST standard?
TheAudiophileDutchman ·
Yes, the range of [-1..1] is valid in all cases for (positive and negative) amplitudes of a wave (vertical axis). Especially when passing samples to a VST-host this prevents hard-clipping (SM module), but can also be considered as good design practice. Inside a schematic, the whole single-precision floating-point range is available for the audio-stream though, given that there might be compatibility issues with other SM components. 😉
However, for a single full period (horizontal axis) of a Sin1/Cos1-wave, the normalised SM range is [0..1] (instead of [0..2*Pi]). Of course, this is no hard limitation. Only, outside this range the periodic Sin1/Cos1 function repeats itself. E.g. in the current pure SSE Sin1-implementation, the allowed angle input is in the range [-1.5 .. 1.5] (=3 periods) and this yields output with amplitudes in the range [-1..1].
exonerate ·
i've just knocked up a lowpass filter using this sine/cos approximation.
and i'm happy with the results 🙂 ,
http://www.box.net/shared/io1qx141b3
i haven't noticed much difference in CPU, between using the sin1 function and the approximation but they sound exactly the same and the filter seems very stable.
when i have time i'm going to use the approximation on lots of different filter types and see how it holds up.
and again thanks for sharing the approximation TheAudiophileDutchman 🙂
cheers 😉
TheAudiophileDutchman ·
Great stuff, I'll check it out when I get home by the end of this week...
I'm writing this message from 'Matrix' on Santorini, an internet cafe next to the place where I just returned my Quad (fairly undamaged, considering the kind of usage) 😀 😉
By the way, some preliminary PIII benchmarks I performed earlier showed at least a 2x speed improvement over the Sin1 solution (using the optimised version with 4 multiplications), but checks on other (read: newer) systems are welcome too; I assume overhead is being excluded from the analysis before calculating the speed gain... 😇
MackTuesday ·
It is possible to get similar results with just three multiplies.
Some quick observations:
* This code doesn't have exact solutions at x= 0, 0.5 and 1. The proposed 'improvements' make the error even larger
* The 4 MULS version yields wrong values (could be interesting when it works though)
* The range is only one period x=[0..1] (should be extended to both sides)
* The pure SSE assembler code (in this thread) can be optimized further to use only 3 MULS (at the cost of one extra ADD), while maintaining accuracy
Preliminary conclusion: so far I don't see any clear advantage in using the proposed solution, but please prove me wrong....... 😉
TheAudiophileDutchman ·
Just slightly improved (as indicated before), nevertheless here's the latest and greatest: only one multiplication needed for a low precision pure SSE SIN1 or a total of three multiplications for improved accuracy!
// SSE SIN1: SynthMaker-version by TheAudiophileDutchman
polyin angle;
polyout out;
int absmask=2147483647; // 0x7fffffff;
float P=0.225; // min. absolute error
float pi=1;
float npi=-1;
float tpi=2;
float hpi=0.5;
Tried adding a ramp osc as input but nothin came out.
Tried a knob (floats) as input but still nothing.
I know you coders will laugh your sses off now but hey., i suck at this but I have a suspicion that if I could understand how to use this it could be something really usefull..... or?
Update: Forget it =)
This is niiiice =)
Update 2 :
I still dont get how to change the accuracy.
Was looking to change a 1 to a 3 lol.
But this sounds great.
TheAudiophileDutchman ·
Glad you like it too. 😀
You'll just have to remove this part for a quick and dirty SIN1 (actually it is a parabola that closely resembles a sine):
One minor problem; I'm not sure if it a SM thing, or this is how synths are made, but SM's OSCs are 1 octave (half frequency) lower than your code. It will cost you a move & mult if you want to place your non-Sine OSC along with others side-by-side. Or you can adjust another part of your schematic to compensate if you don't want to use this ASM adjustment:
...
float half=0.5;
//match SM's pitch
movaps xmm0,f;
mulps xmm0,half;
movaps f,xmm0;
//^ put the above before the ramp in the beginning!
//ramp
...
Don't feel bad; if I remember other Code OSCs had to re-adjust their frequency also.
stw ·
sorry for digging this out but...
i'm curious why this code needs almost twice the number of CPU cycles compared to the stock sin on my IntelQuadCore?
Have the stock oscs been updated meanwhile, or do i overlook something?
TheAudiophileDutchman ·
Could you please upload your test-schematic (OSM) here?
stw ·
just the analyser behind it. But some real live testing approved that preformance.
Dozius ·
I'm getting similar results on an Intel core2duo here. The stock primitive is over 50% faster.
TheAudiophileDutchman ·
I found similar results yesterday: weird 😮
I checked with Malc, but he couldn't tell me if/when something improved to the stock Sin1 or a related part of SM or that there is performance loss when using ASM since SM version x.xx (several SM users reported considerable speed gains back in 2007/2008 when using this Sin1 approximation)...
infuzion ·
Dozius wrote: I'm getting similar results on an Intel core2duo here. The stock primitive is over 50% faster.
I used the TheAudiophileDutchman+Eska version, and on my Athlon64, SM's basic Sine is 75 cycles, the 3-multiply Sin1 is under 50 cycles. Core2Duo self-optimizes ASM very well, but in my general experience hand-ASM optimization should be still faster on the C2D, but not as much a the Athlon.
You might want to hit the Calibrate a few times, switch the connectors around, etc.
aliasant ·
On my computer that double cpu analyzer hasnt really worked. I always got different results on A and B even if I connected the same primitive to both A and B ( 1 for each input) I prefer measuring first one prim, hit calc an extra time, remove it and then check the other.
Btw. What kind of stoneage computers do you guys use?
The Sine on my 3 years old mac uses 28 cycles 🙂
infuzion ·
aliasant wrote: I prefer measuring first one prim, hit calc an extra time, remove it and then check the other.
Btw. What kind of stoneage computers do you guys use?
You should leave the CPU Cycle Analyzer on autorun to get a better sample-size. If you just hit "Single Test", then you might hit the start of a Hop(), which may throw your test off.
Obviously you're using a Core2Duo+.
aliasant ·
I always have it on autorun.
I modded one so that I have three readouts from it.
first is actual
second is average
third is lowest
MegaHurtz ·
wasnt this a sine function?.
In that case you should test against sin1, not a sin osc.
aliasant ·
MegaHurtz wrote: wasnt this a sine function?.
In that case you should test against sin1, not a sin osc.
Na. I was talking about Infuzions post:
infuzion wrote: I used the TheAudiophileDutchman+Eska version, and on my Athlon64, SM's basic Sine is 75 cycles, the 3-multiply Sin1 is under 50 cycles. Core2Duo self-optimizes ASM very well, but in my general experience hand-ASM optimization should be still faster on the C2D, but not as much a the Athlon.
You might want to hit the Calibrate a few times, switch the connectors around, etc.
infuzion ·
MegaHurtz wrote: wasnt this a sine function?.
In that case you should test against sin1, not a sin osc.
stw's picture showed a Sine OSC, which I assumed used Sin1 also.
stw ·
that's all very odd.
So i installed SM on my old Athlon64 to verify what's going on here. And i have to confirm infuzions observation.
On my AMD64 i get complete different results than on my Intel machines.
sin osc uses 75 cycles and the sin1 approx. around 34 😮
And that's no matter of a wrong setup of the analyzer tool.
If i compare that AMD result to the Intel measurements of 25cyc sin osc/ 44cyc 3mult-sin1 that would mean the 3mult-sin1 may take only 11cyc to be equal to the AMD.
In other words the AMD runs 4 times faster than the Intel on this asm block (relative not absolute)! Quite shocking....
If one could explain that HUGE differenece or how to handle that i'd be glad...
stw ·
infuzion wrote:
MegaHurtz wrote: wasnt this a sine function?.
In that case you should test against sin1, not a sin osc.
stw's picture showed a Sine OSC, which I assumed used Sin1 also.
the SIN OSC was a stock OSC. But that's of no interest here. To get a OSC from the 3mult-sin1 you have to add a ramp to the input which would even increase the amount of cycles in this enviroment which should be way less than the stock OSC.
MegaHurtz ·
Im guessing it`s a 512 wavetable.
MegaHurtz ·
The test should be eliminating all of the variables leaving only the function to test.
But.. I dont think this difference in "cycles" should be compensated.
If your processor is four times that it still takes half as long.
TheAudiophileDutchman ·
Lets play a game: how well does this newly optimized SIN1 version perform in the benchmarks, guys? 😉
movaps out,xmm0;
// by TheAudiophileDutchman - July 2009
aliasant ·
Are you sure thats a Sin1 ?
Am I not supposed to get a Sine if I hook it up with a ramp? 🙂
If I neglect that, it uses 35 cycles on mine compared to the older but working Sin1 that used 45 with all the bells on.
Disco_Steve ·
If I was writting SM I would use the IPP. (Intel performance perimitives)
these are blindingly fast on an intel machine writen by intel geeks for their cores (you cant get faster!), and in some casses are even faster on an althon!, but in general are slower on an athlon.
more people have intels than athlons so use the intel faster version, unless the athlon version is so much slower and the world ends 🙂
Steve
infuzion ·
Disco_Steve wrote: If I was writing SM I would use the IPP. (Intel performance primitives)
these are blindingly fast on an Intel machine written by Intel geeks for their cores (you cant get faster!)
Do you mean using the Intel compiler? I think Malc has enough issues with Microsofts', let alone trying to reprogram SM to use another compiler. But yes, Intel's compiler is long known to give faster output in general.
TheAudiophileDutchman ·
aliasant wrote: Are you sure thats a Sin1 ?
Am I not supposed to get a Sine if I hook it up with a ramp? 🙂
If I neglect that, it uses 35 cycles on mine compared to the older but working Sin1 that used 45 with all the bells on.
Yes, but with amplitude=0.25 instead of 1 (just put back the two adds of the old version or one mul if you don't like that)
Nope, just hook it up directly with a frequency [0..1] signal (as the ramp-function is integrated & optimized this time).
Allright, that would mean about 22% speed improvement over the previous version... 🙂
aliasant ·
Wow. Nice work!.
I save 1 tiny little cycle by moving F1 and Absmask into xmm6 and 7 at the beginning.
Like this. Not sure if everyone can gain from that though?
movaps out,xmm0;
// by TheAudiophileDutchman - July 2009
aliasant ·
Oops. Something might be wrong. i zoomed in on the waveform and noticed this.
added the osm....
Disco_Steve ·
no the IPP is a set of pre compiled assembler code that can be called via a dll or embended. they are optimised specificly for intel cores, and a new set is released with every core intel bring out. these are writen to be the fastes posible. hence why I would use them if I was writing SM. they also make development very easy, you want to do an FFT, just call the intel one and you know you will be using the fastest FFT in the west. as far as I remember the IPP included a sin(). Im surprised sin() isn't 'writen into' the cores nowadays. so many programs need sin()?
stw ·
TheAudiophileDutchman wrote: Allright, that would mean about 22% speed improvement over the previous version... 🙂
which is good but not enough to beat the stock OSC on intel machines 😉
TheAudiophileDutchman ·
Fixed the bug in the ramp-function and saved one assembler instruction in the process (see below) 🙂
movaps out,xmm0;
// by TheAudiophileDutchman - July 2009
stw ·
TheAudiophileDutchman wrote: Fixed the bug in the ramp-function and saved one assembler instruction in the process (see below) 🙂
Hey that's a good one now!! It works pretty well at low freqs and if the extra precision is taken out it just needs 11 cycles on my Quad.
aliasant ·
WELL DONE M8 🙂
It is actually perfect for LFOs. If hoped by 4 ( or similar) it would barely use any cpu at all.
Stock Sine is still better on my Intel. But not by much.
This one now uses only 30 cycles compared to Stocks 28. Very close!
Edit: Tried to hop it but that didnt work at all. Maybe if one places the hop at the right place.
Hopping everything didnt but might if one adjusts the freq input by the hop amount but I couldnt get it to work.
Thank you VERY much AD!
TheAudiophileDutchman ·
Allright then, what's the benchmark of this hop(4) LFO-version? 😉
movaps out,xmm0;
end0:
// by TheAudiophileDutchman - July 2009
MyCo ·
Due to the ramp that you need for the LFO, it isn't the fastest Sin-LFO... I think therefor other version should be faster, eg. this one:
http://musicdsp.org/showone.php?id=10
TheAudiophileDutchman ·
Well, if you don't have a fixed frequency LFO, but user controlled (sweep) frequencies then, according to the algorithm you'll have to calculate a (hopped?) SINE with this Modified Coupled Form (and 2 muls instead of one). And, if I remember correctly, there can be unwanted amplitude changes when the frequency changes (alternatively, a Digital Waveguide Resonator only uses 1 mul and amplitude could be efficiently controlled during frequency changes) 😉
FYI: here are some MCF & DWR related patent references: U.S. 5,198,779 and U.S. 5,701,393.
By the way, I never intended my SIN1 approximation to be used as an efficient LFO, but as demonstrated it can be done... (still curious about the benchmarks of the latest version though)
infuzion ·
TheAudiophileDutchman wrote: By the way, I never intended my SIN1 approximation to be used as an efficient LFO, but as demonstrated it can be done... (still curious about the benchmarks of the latest version though)
Urm, so can someone please point out the best Sine for LFO with a sweeping frequency please? I'm slightly 😕 😮 😊
TheAudiophileDutchman ·
@aliasant & stw: does the hop(4) version perform as expected?
@aliasant & infuzion: given this excellent forum thread with sine LFO benchmarks (see below), I'm quite curious what a hop(16) with a one pole lowpass would bring in this case... 😉
Reaktor Sine function conversion....
aliasant ·
Sorry AD. I was busy playing ARMA2 yesterday.
🙂
I did try the LFo code but I get nothing from it. Its dead, or did I do something crazy again?
Interesting reading thru that other thread. I had completely forgot that one. Deja Vu almost.
stw ·
Allright then...
as expected it could save additional 3 cycles on the QuadCore and run at approx. 8 cycles. But you messed up your code... 😈
The
addps xmm0,xmm0;
which you implemented to shift the freq according to the hop level doesn't work. You have to xchange to
addps xmm0,freq;
and if you do a 4 hop than you have to do additional 3 addps and not two. If that's done the hop advantage is gone and you get nearly the same result as without hop. For bigger hops it'd be better to multiply the freq input with the hop value to keep the osc in sync.
TheAudiophileDutchman wrote: Allright then, what's the benchmark of this hop(4) LFO-version? 😉
movaps out,xmm0;
end0:
// by TheAudiophileDutchman - July 2009
TheAudiophileDutchman ·
Thanks for your feedback, stw. 🙂
Based on this, I've concluded that CPU-usage is already so low that a hop(4) will not be very beneficial in this case; I'll move up to hop(8) and the frequency multiplication as you suggested... (maybe tomorrow, have to go now)
stw ·
TheAudiophileDutchman wrote: Thanks for your feedback, stw. 🙂
Based on this, I've concluded that CPU-usage is already so low that a hop(4) will not be very beneficial in this case; I'll move up to hop(8) and the frequency multiplication as you suggested... (maybe tomorrow, have to go now)
oh... don't worry. I've done it already. 😉
Here's a hop 32 version which could do it for LFOs. This needs 4-5 cycles here.
movaps xmm0, xmm1;
andps xmm1, absmask;
mulps xmm1, xmm0;
subps xmm0, xmm1; // 0.25*Sin1(X)= X - X * ABS(X))
movaps out,xmm0;
end0:
// by TheAudiophileDutchman - July 2009
aliasant ·
Nice stw.
I added a lowpass code in the sine, after the hop end of course, and that works well.
Without LP filter that sine uses 2 cycles and with LP it uses 5.4. Pretty fast.
MegaHurtz ·
nah sry.. i think i`ll stick to sin1.
this hardly resembles a sine anymore. whats the purpose?
this sucks:D.
btw, a buffer is light. use one of them.
good effort though.
PZ!
aliasant ·
MegaHurtz wrote: nah sry.. i think i`ll stick to sin1.
this hardly resembles a sine anymore. whats the purpose?
this sucks:D.
btw, a buffer is light. use one of them.
good effort though.
PZ!
Duh. Depends on what you wanna use it for.
Slow LFO in Chorus or similar or maybe to control lamps and animations.
MegaHurtz ·
No slow lfo for me, Even stepped over the standard osc.
I agree it would be usefull for gui parts..
MegaHurtz ·
but then again. green is awfully inexistant if hardly used.
hansdump ·
It seems to be exhausted in every dimension.
H.
ROMplERbuDE ·
Hy all
Here is another fast SSE coded sin(x) function using polynomials.
The problem is that u needs many multiplication for calculate polynomials.
For example f(x)= x^4+2x^3+4x^2x+1 = x*x*x*x+2*x*x*x+4*x*x+x+1
Those are many many many many multiplications…..
The simplest way to transform the function f(x) without many many…
Multiplications to do this call “Horner Scheme”.
For example f(x)= x^4+2x^3+4x^2+2x+1 = ((((x+2)*x+4)*x+2)*x+1
There are all multiplications in it.
Thanks for the post 😀 - I think this method could find its way into a lot algorithms round here very quickly!!
It's a beautiful piece of optimisation - incredibly elegant, even interleaves the adds and mults nicely.
My maths isn't great (did my exams 20 years ago!) - I understand the principle of Taylor (polynomial) series OK'ish - but is there an easy method for devising a Horner Scheme for any given Taylor series - or are only some polynomials possible to reduce this way?
The Luddite.
ROMplERbuDE ·
My maths isn't great (did my exams 20 years ago!) - I understand the principle of Taylor (polynomial) series OK'ish - but is there an easy method for devising a Horner Scheme for any given Taylor series - or are only some polynomials possible to reduce this way?
Yes the Horner Scheme can be applied to all Taylor series (sin, cos, exp, Ln….). My old exp (x) module with variable base in the Synthmaker Wiki is based also on it. Further modules are in work and will soon appear.
Thanks for sharing the routine! But I don't understand the reason for rounding the input? Can you explain please?
hansdump ·
Did you check this approach about its accuracy, especially in frequency domain?
My investigations arose that there are a lot of more accurate approximation and curve fitting algos outta there next to the taylor and horner approach. The barrier lies in mathematics... this is a problem for me too... 😊
I would guess, the best and most efficient method is to use a table look up, choosing the right size of the table and kind of interpolation!
So why the hell not find the right "ying and yang" between time complexity and space complexity?
H.
stw ·
hansdump wrote: Did you check this approach about its accuracy, especially in frequency domain?
It's not bad. Though as most approximisations it becomes edgier the higher it goes.
However this code combined with a ramp needs around 100% more cycles than the stock sine. So i guess it's just a mathematical gadget. 😉
infuzion ·
stw wrote:
hansdump wrote: Did you check this approach about its accuracy, especially in frequency domain?
It's not bad. Though as most approximisations it becomes edgier the higher it goes.
However this code combined with a ramp needs around 100% more cycles than the stock sine. So i guess it's just a mathematical gadget. 😉
Do you mean the "ramp" OSC, & you're comparing to the Sine OSC primitive? The Sine OSC is not bad, but I'm thinking the Ramp OSC could be optimized, esp if you do not need phase.
Also, sin1() & cos1() are used in other things than OSCs, like filters.
ROMplERbuDE ·
@infuzion
Thanks for sharing the routine! But I don't understand the reason for rounding the input? Can you explain please?
This approximation is unfortunately only of (- Pi <= x <=Pi) acceptable however with a small trick calls themselves Phasewrapping or Wrapping, can the phase be shifted. The period 2Pi always remains the same thereby and repeats themselves. (0<= x <= 2Pi)
For an oscillator it is irrelevant whereby the phase only of - pi to pi goes. One can also omit the Wrapping function thereby has one then in addition, no more the possibility from a sine to make a Cosinus. Cos (x)=Sin (0.25+x).
But Sin1() and Sin() module supply different results. Sin1() has double frequency???
// Sin(x) for oscilators without Wrapping
streamin in;
streamout sinx;
infuzion wrote: Do you mean the "ramp" OSC, & you're comparing to the Sine OSC primitive?
Doesn't matter. Horner seems to be slower anyway (see pict)
Why do you think the ramp osc has much room for improvement? We did an asm version somewhere here which is only beats the stock osc by a few cycles IIRC.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker