# What is the formula for this??



## Thonex (Jul 2, 2006)

on the Time Machine 2 module there is a Speed knob that is displayed in percentages.

I wrote a little script to figure out what the numbers are equal to what percentage is displayed.

Example:

If a script executes the number 500000 the SPeed knob will show 100% so...

500000 = 100.0%
1000000 = 800%
169922 (or thereabouts) = 50%
43945 (or thereabouts) = 10%
1953 = .38%

Since the GUI resolution of turning the knob is not great.... it's hard to land exactly on a round percentage sometimes (hence my use of the word "thereabouts").

Do any of you know the formula to translate from 0-1000000 to 0%-800%

I figure one of you math brainiacs might know this. I can't find it in any manual.

Cheers,

T


oh... here is the script to check the Speed% values -- you have to have a patch using the Time Machine 2 module for this to work:


```
on init

declare $ASD

$ASD := _get_engine_par ($ENGINE_PAR_SPEED,0,0,0)

message ($ASD)

end on
```

The value will be displayed at the bottom left after you hit K2's script editor "Apply"


----------



## ComposerDude (Jul 3, 2006)

I plotted your numbers on graph paper and got a strange looking curve ("piecewise continuous" but not a simple smooth function).

At the two higher values you could compute this by the formula:

((VALUE / 500000) ^ 3 ) x 100 = PERCENT

Which is:

500,000 / 500,000 = 1, cubed yields 1, times 100 equals 100 percent, and
1,000,000 / 500,000 = 2, cubed yields 8, times 100 equals 800 percent.

But that doesn't seem to hold for the lower values.

Anyway, it's a start but keep in mind that within computers a piecewise continuous function can easily be produced with if/then/else statements so you may not be dealing with a simple mathematical function...

-Peter


----------



## Thonex (Jul 3, 2006)

Ok.... 

Here is a "finer" detail look at the values and how they correlate (I tried to get as close as I could to a round Percentile as K2 would let me):


```
Vaue		Percent
1000000		800
988281		697.8
974609		599.5
957031		499
934570		401.9
900391		300.2
841797		200.6
832031		189.6
822266		179.8
811523		170.1
798828		160.1
784180		150.1
766602		140
745117		130.1
716797		120.1
674805		110.1
500000		100
358398		95
321289		90.1
293945		85.1
270508		80
250977		75.1
232422		69.9
215820		65
200195		60
184570		54.9
169922		50
155273		45
140625		40
125977		35
111328		30.1
95703		25
79102		19.9
62500		15
43945		10
23438		5
5859		1.2
1953		0.38
0		   0
```

Does anyone here know how we can figure out what formula is being used to generate these percentile values?

THanks,

T


----------



## kotori (Jul 4, 2006)

I posted a response on the NI Forum. Please see that post for a linearly interpolated lookup-table.


----------



## ComposerDude (Jul 4, 2006)

Here is the graph of the Kotori data table as plotted by some quick custom software I wrote tonight. (Background stippling is a bug in MS Photo Editor and/or the screen capture used to create the .gif...)

Vertical axis is percent, horizontal is that other NI-specific number.

As I said earlier and as Kotori observes in his NI post -- you can see the discontinuities in the curve shape including some apparently linear segments, so this isn't just a simple function.

-Peter


----------



## kotori (Jul 4, 2006)

ComposerDude @ Mon Jul 03 said:


> I plotted your numbers on graph paper and got a strange looking curve ("piecewise continuous" but not a simple smooth function).
> 
> At the two higher values you could compute this by the formula:
> 
> ...



Hi Peter,
Your curve made me realize that Andrew wants to go from the big numbers to percents. I just skimmed the text earlier and got the (incorrect) impression that he wanted to go the other way. Now looking at the non-inverted graph it looks pretty much like a third degree polynomial just like you say. 

This formula is a rough approximation for the whole range:
((VALUE-500000)/500000)^3 * (100+600*(VALUE>500000))+100
where (VALUE>500000) evalutes to 1 or 0 depending on whether it's true or false.

Cheers,
Nils


----------



## Nickie Fønshauge (Jul 4, 2006)

Looks like two formulas. Something like:

0 <= x <= 500000: sin (1.5708*x/500000)*100






and

500000 <= x <= 1000000: ((x-500000)^3/500000^3)*800 + 100





or 

500000 <= x <= 1000000: ((x-500000)^4/500000^4)*800 + 100


----------



## Thonex (Jul 4, 2006)

kotori @ Tue Jul 04 said:


> Your curve made me realize that Andrew wants to go from the big numbers to percents. I just skimmed the text earlier and got the (incorrect) impression that he wanted to go the other way. Now looking at the non-inverted graph it looks pretty much like a third degree polynomial just like you say.
> 
> This formula is a rough approximation for the whole range:
> ((VALUE-500000)/500000)^3 * (100+600*(VALUE>500000))+100
> ...



Actually..... it may be more useful to go from % to the big numbers.

I'm working on a script that if you have a sample performance at (say) 138 BPM and the DAW sends the tempo of (say) 122 BPM via NRPN then the script will figure out the percent difference in the tempos and calculate the "large number" representing the percentage difference and send that as a _set_engine_par command to the Time Machine 2 module.

This way we can synchronize beats and orchestral timed performances in K2 in Stand_alone mode.

Cheers,

T


----------



## Thonex (Jul 4, 2006)

BTW.... THANKS everyone for helping out on this. I have a few friends working on this on my end.... I've directed them to this site.... when we get a good function... I'll post it here.

I'm not saying Kotori's or Nickie's functions aren't good.... I just haven't had time to really go over this stuff .... I have guests coming over for the 4th of July (US Independence day) in a while..... damn social obligations!!! :roll: :lol: :lol: :lol: 

T


----------



## ComposerDude (Jul 4, 2006)

Fortunately I left the labels off the axes so you can consider either one to the be input and the other to be the output...  (whichever way you want to do the conversion)

The main point of my graph was to see the actual shape of Kotori's observed data, and if you look closely you'll notice some linear SEGMENTS with slight points of discontinuity (little "knees" in an otherwise smooth curve). Each data point was produced by literally cutting-and-pasting Kotori's tabular data into an array definition in C, so this is not formulaic output, it's the actual data points.

In other words, if we can develop an actual formula for this, we'll be doing better than NI, who apparently implemented (at least some of) this via line segments.

I leave it as an exercise to the reader, and to those more skilled at curve fitting than I, to determine the mathematical formulae that produce that curve. And there will be a test next period. :shock:

-Peter


----------



## Thonex (Jul 5, 2006)

ok guys.... and Nickie :smile: ,

My brother who does financial analyses agrees it is almost certainly 2 formulas... 1 for 1-100%... the other for 100-800%.

Based on the graphs and whatnot... I would tend to agree. I have some friends that work at JPL (part of NASA) and they haven't responded yet... maybe I can get them to look at this and maybe they can figure this out.

I posted this on NI and.... no response so far from NI.

I wonder... why would NI not want to share all the formulas... it just means better 3rd party support... no?


Cheers,

T


----------



## kotori (Jul 5, 2006)

Wow, this is getting theoretical. :lol: 
A thing to keep in mind here is that even if you find really neat formulae you have to be able to express them in KSP too. So cos/sin/square root won't work unless one uses a lookup table (in which case one might as well use the table of interpolated values I posted). Based on the appearance of the graph I'd say that it shouldn't be too hard to write a formula for going from set_engine_param numbers to percentages, but the other way around is probably quite hard.

So what can we use to build the formula? Basically, polynomials and rational expressions. When you use a polynomial (eg. Ax^2 + Bx + C) the problem is to find the set of coefficients (A,B,C) that best fits the data. This is a linear problem and is easily solvable by the least squares method. Rational expressions are (just) a bit harder since they're not linear. I have a small program that solves the first problem.


----------



## Thonex (Jul 5, 2006)

kotori @ Wed Jul 05 said:


> A thing to keep in mind here is that even if you find really neat formulae you have to be able to express them in KSP too. So cos/sin/square root won't work unless one uses a lookup table (in which case one might as well use the table of interpolated values I posted).



A friend of mine has a Big Boring Book ( :lol: ) of formulas and how they can be expressed in more simple "terms" without the use of Log, COS, SIN etc... the problem is that these formulas are not "efficient"... but I don't care because all of the calculations would be happening on a NRPN call (tempo change) and not during any note calls. The only time there could be a problem is if the note on call is too close to the NRPN call... in that case just move the NRPN call sooner in time on the DAW.

I want to thank all of you guys for helping.

Kotori,

did you great a program to give you all those readings? or did you do it manually like me... and take an hour of hitting "apply"?

Because It would be nice to have a finer detail between 100 and 150%.

If you are doing it manually... then don't bother... I'll do it... but if it's just the matter of hitting "run" on one of your little Python programs... than it would be great to get a finer output between 100 and 150 or 200 percent.

Cheer,

T


----------



## kotori (Jul 5, 2006)

Thonex @ Wed Jul 05 said:


> A friend of mine has a Big Boring Book ( :lol: ) of formulas and how they can be expressed in more simple "terms" without the use of Log, COS, SIN etc... the problem is that these formulas are not "efficient"... but I don't care because all of the calculations would be happening on a NRPN call (tempo change) and not during any note calls.


Yeah, but those are approximations so instead of approximating an approximation it could make more sense to let the computer figure out the best coefficients directly.



Thonex said:


> Kotori,
> did you great a program to give you all those readings? or did you do it manually like me... and take an hour of hitting "apply"?
> 
> Because It would be nice to have a finer detail between 100 and 150%.



I once read a programmer who said he was lazy in the way that makes a person work hard just to make something easy (maybe it was Larry Wall). That is something I can really identify with :smile:, so yes it's only a matter of hitting a button. Here's the data:

```
100 	500000
101 	517307
102 	534614
103 	551922
104 	569229
105 	586537
106 	603844
107 	621151
108 	638459
109 	655766
110 	673074
111 	678584
112 	682783
113 	686982
114 	691181
115 	695381
116 	699580
117 	703779
118 	707978
119 	712177
120 	716377
121 	719345
122 	722177
123 	725009
124 	727841
125 	730673
126 	733505
127 	736337
128 	739169
129 	742001
130 	744833
131 	747070
132 	749240
133 	751410
134 	753580
135 	755750
136 	757921
137 	760091
138 	762261
139 	764431
140 	766602
141 	768342
142 	770082
143 	771823
144 	773563
145 	775303
146 	777044
147 	778784
148 	780525
149 	782265
150 	784005
```

Cheers,
Nils


----------



## Thonex (Jul 5, 2006)

Thanks Kotori!!!  

Man... why can't NI just publish this stuff!!! :???: 

T


----------

