Difference between revisions of "Oscillator Movement/Period"
m (Oscillators/Period moved to Oscillator Movement/Period: Making it a subpage of the main article.) |
(use <syntaxhighlight>) |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
When I was building NanoLauLectrik 1.0, I found that the following movement. | When I was building NanoLauLectrik 1.0, I found that the following movement. | ||
− | + | <syntaxhighlight>setAhead(Math.sin(n/12)*Math.cos(n/6)*200) //n is the moment in time</syntaxhighlight> | |
was performing far worst against pattern matchers that the movement | was performing far worst against pattern matchers that the movement | ||
− | + | <syntaxhighlight>setAhead(Math.sin(n/12)*Math.cos(n/7)*200) //Note that it only changes the 6 for the 7</syntaxhighlight> | |
− | I got quite curious, because I didn't expected such a subtle change to have a great efect on its performance. I plotted some graphs to investigate, and I found that the main difference was the | + | I got quite curious, because I didn't expected such a subtle change to have a great efect on its performance. I plotted some graphs to investigate, and I found that the main difference was the length of the full period of the movement (the full period is the number of ticks it takes for the movement to exactly repeat again). |
for a = 12 and b = 6 the full period is 75 | for a = 12 and b = 6 the full period is 75 | ||
Line 14: | Line 14: | ||
I tested the performance for different periods and it seems that <b> the longer the full period, the better the movement. </b> Of course, there are some more considerations, so it's not enough to just increase a to POSITIVE_INFINITY :-) | I tested the performance for different periods and it seems that <b> the longer the full period, the better the movement. </b> Of course, there are some more considerations, so it's not enough to just increase a to POSITIVE_INFINITY :-) | ||
− | So, the second step was: How could I calculate the | + | So, the second step was: How could I calculate the length of the period? I found a formula you can use to calculate it (note that it works both for multiplicative and additive complex oscillators): |
− | Full Period | + | Full Period Length = 2 * PI * b * (a/m.c.d(a,b)) m.c.d is the maximum common divisor of a and b. |
For example: | For example: |
Latest revision as of 07:23, 1 July 2010
When I was building NanoLauLectrik 1.0, I found that the following movement.
setAhead(Math.sin(n/12)*Math.cos(n/6)*200) //n is the moment in time
was performing far worst against pattern matchers that the movement
setAhead(Math.sin(n/12)*Math.cos(n/7)*200) //Note that it only changes the 6 for the 7
I got quite curious, because I didn't expected such a subtle change to have a great efect on its performance. I plotted some graphs to investigate, and I found that the main difference was the length of the full period of the movement (the full period is the number of ticks it takes for the movement to exactly repeat again).
for a = 12 and b = 6 the full period is 75 for a = 12 and b = 7 the full period is 528
I tested the performance for different periods and it seems that the longer the full period, the better the movement. Of course, there are some more considerations, so it's not enough to just increase a to POSITIVE_INFINITY :-)
So, the second step was: How could I calculate the length of the period? I found a formula you can use to calculate it (note that it works both for multiplicative and additive complex oscillators):
Full Period Length = 2 * PI * b * (a/m.c.d(a,b)) m.c.d is the maximum common divisor of a and b.
For example:
m.c.d(12,7) = 1 -> FPL = 2 * PI * 7 * (12/1) = 527,7 m.c.d(12,6) = 6 -> FPL = 2 * PI * 6 * (12/6) = 75,3
So you can easily see that the best combination of a,b is the one where a and b are relative prime numbers. An easy way to get it is to make sure that either a or b are primes (3,5,7,11,13,etc).
Since these kinds of effects (great changes of performance produced by small changes in parameters) had happened to me in more complex movements, I guess that this kind of (or similar) logic applies to different types of movements... so be careful which parameters you choose.