Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
Today I was comparing FT's compiler with ppmck's compiler to see if there were any differences in how they divided and distributed frames toward certain note values when the 'tempo's were set to something other than 150(@60Hz of course).
I found that at tempo 120 there were no differences at all, however there are slight variations at tempo 143(under the nsfimport microscope). I also noticed quite a few interesting things at this tempo in regard to frame skipping patterns.
I measured the frame distribution toward sixteenth notes at tempo 143. The following values indicate how many frames each successive sixteenth note recieved(the beginning of the pattern at least):
It's odd to confirm that the compilers handled frame distribution differently, but I noticed something else about FT's compiler that's a bit interesting.
If I render the same ftm multiple times, the pattern is different each time. For example:
the first render would be: 666 7 66 7 666 7 66 7 ...
and the second render would be: 7 66 7 66 7 666 7 66 7 ...
And if I listen carefully, it seems that each time I start realtime playback, it starts on a different point in the pattern.
Does anyone (rainwarrior? jsr?) know what's up with this? How does FT's realtime playback and compiler handle frame distribution at these kind of tempos?
Also I tried to establish where the pattern actually stopped and repeated itself with tempo 143. It's either ridiculously long or there's some form of randomization going on with the pairs of two and three sixes.
I'd really like to know how these patterns work. There's a musical reason for it, but I'll bring that up later perhaps.
You should notice that ppmck and FT are producing the same pattern, they just started at a different point in the pattern. Similarly with FT doing it differently at different times, it probably just doesn't reset its tempo generating device when you stop or play. (This might be considered a bug.)
It's very similar to [url=http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm]Bresenham's Line Algorithm.
The way you keep your framerate in synch with an arbitrary timing (i.e. your tempo setting) is to always keep a running total of the total time spent, and when it reaches your time per row, play a row and subtract that time from the total. Something like this:
time_accum = 0 ms;
time_per_row = 179 ms;
time_per_frame = 15 ms;
.
for(each frame)
{
... time_accum += time_per_frame; // account for time spent this frame
... if (time_accum >= time_per_row) // we have accumulated enough time to play a row
... {
....... advance_row();
....... time_accum -= time_per_row; // account for time used on row
... }
}
So what this code is doing is adding time to our counter every time a new frame is reached; this tells us how much time has elapsed that hasn't been spent playing a row. When we reach our threshold (time_per_row) we play a row and can subtract the time owed to that row from our counter. This is a fairly standard algorithm for keeping a consistent timing.
When "time_per_row" is a multiple of "time_per_frame" in this example, you will get the same number of frames per row every time, but if they are uneven, the unused portion of each row accumulates until it finally spills over. Consider if they were 7 and 3:
I don't think I have anything more to add, other than that the tempo counter is supposed to be cleared each time the player starts, so I can't tell why it would produce different results. I'll need to check this.
gyms: I checked the tempo code and the counter appeared to be cleared properly, so I could not reproduce the problem. Did you get this problem in the latest version?
After messing around a bit, I figured out what happened: one of my tests had more rows in the frame than the others(hurrr)
Didn't really occur to me at the time I was first doing all this stuff that the length of the song affected the division, which would also explain why the ppmck nsf didn't line up with the FT nsf. I just dropped a big, random number of 16th C notes at tempo 143 into ppmck and then filled up a FT frame with C notes, which I loosely guesstimated to match the uncounted number of notes in the ppmck one(there were more than 64 rows). When I tested FT against itself, I must have just left the default 64 rows on.
haha, jeez...sorry to bother you with my clumsy tests, but thanks for checking, jsr! :-))
