Tempo & Speed simpler than the wiki implies?

General discussion about tracking, help and support.
User avatar
ShrubRustle
Posts: 14
Joined: Thu Jun 04, 2015 9:05 pm
Contact:

Tempo & Speed simpler than the wiki implies?

Postby ShrubRustle » Wed Apr 27, 2016 2:10 pm

So, I'm not sure if this is common knowledge, since I'm fairly new to the scene, and VERY new to these forums, but the Famitracker wiki makes changing the Tempo value seem like a big no-no. It basically tells you that you HAVE to keep the tempo 150 (or 125, but does anybody actually use PAL) and use Fxx to do any tempo changes.

The problem is... that is sometimes just totally unnecessary, and even counterproductive.

Let's take, for example, the BPM of 160. You COULD do F07, F05, F06, F05, F06, F05, F06, F05, but if you're doing any 16th notes (i.e. a note every line) then you get an audible delay.

However, plugging 160 into the BPM equation that the wiki entry for Fxx gives us, (BPM = Tempo * 6 ÷ Speed) it's simple algebra to find out that, no, changing the Tempo value to 160 doesn't result in any non-integer values.

Here, I'll show my work:

160=Tempo*6/Speed
//divide both sides by 6
26.66=Tempo/Speed
//Bear with me, the fraction will resolve itself. If we set Speed=6...
26.66=Tempo/6
//Multiply both sides by 6
160=Tempo

From my math, you can do literally any Tempo value, so long as the Speed remains at 6. Unless, of course, there are other equations at play here. I highly doubt I'm the only one to ever crunch these numbers, so I'm inclined to believe the latter. Does anybody with a more in-depth knowledge of the code have anything to add?
I like to pretend I know what I'm doing. My SoundCloud

User avatar
HertzDevil
Posts: 475
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: Tempo & Speed simpler than the wiki implies?

Postby HertzDevil » Wed Apr 27, 2016 2:37 pm

The default 160 tempo merely expands to F06 F06 F05 F06 F06 F05 F06 F05, since eventually the duration of each row must be an integer. Whether the calculated BPM value is an integer plays no role in the sound engine; the provision of tempo and speed as separate values merely expands the choice for specific BPM values.
refactoring 0cc-famitracker

User avatar
Stratelier
Posts: 378
Joined: Sun Apr 26, 2015 7:46 pm

Re: Tempo & Speed simpler than the wiki implies?

Postby Stratelier » Wed Apr 27, 2016 3:47 pm

Having a fixed (or at least known) # of engine ticks per each row makes certain effects more predictable, because effects measure time relative to engine ticks. For example, if you're strumming a bassline and using Sxx to cut off each note at precisely one tick before the next note hits, if you don't know the tick count for each row then you risk some of your bass notes blurring together (despite the Sxx) because they just happened to get a shorter tick count than the other rows.

BUT if your song doesn't use any of those effects, whether your have an integral tempo or not may not even be a concern. And I agree, the wiki seems to place a HUGE emphasis on a fixed # ticks per row being the "One True Way" of defining song tempo. It needs a more neutral explanation....

BTW, every tempo combination has a certain "stable interval", a specific # of rows that corresponds to a specific # of engine ticks. For example, a tempo 160 is stable across eight rows (as HertzDevil said above), and a tempo 200 is stable across every two rows. However this stat is only useful to know if it's a small value (preferably some integral fraction of a beat, e.g. < 5).

User avatar
ShrubRustle
Posts: 14
Joined: Thu Jun 04, 2015 9:05 pm
Contact:

Re: Tempo & Speed simpler than the wiki implies?

Postby ShrubRustle » Wed Apr 27, 2016 3:55 pm

Hmm, okay so, just so I know I'm getting this right:

Tempo/Speed has to be an integer for it to have absolutely no lagging notes? It sure would be nice to have a coherent equation for that on the wiki, instead of multiple disparate equations, some of which have inconsistent units (the one explaining why 150 is the default uses both "ticks" and "f" [which I can only assume means frames])
I like to pretend I know what I'm doing. My SoundCloud

User avatar
Stratelier
Posts: 378
Joined: Sun Apr 26, 2015 7:46 pm

Re: Tempo & Speed simpler than the wiki implies?

Postby Stratelier » Sat Apr 30, 2016 4:26 am

ShrubRustle wrote:Hmm, okay so, just so I know I'm getting this right:

Tempo/Speed has to be an integer for it to have absolutely no lagging notes?


Basically, yes. If the # of engine ticks isn't consistent from one row to another, FamiTracker's FTM engine will time that row with the closest available engine tick, which may or may not be noticeable in the end result (depending on what effects you use and how closely you listen).

User avatar
HertzDevil
Posts: 475
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: Tempo & Speed simpler than the wiki implies?

Postby HertzDevil » Sat Apr 30, 2016 10:19 pm

By "absolutely no lagging notes" I shall assume that all rows have the same number of ticks (in Stratelier's words, the "stable interval" spans one row). The exact criterion is this:

Code: Select all

floor(60 × rate) - 24 × tempo
is an integer multiple, possibly negative (i.e. ticks-per-row count < speed on average), of
floor(24 × tempo ÷ speed), the speed constant

where
floor(x) = greatest integer not exceeding x
tempo, speed = current values determined by song's default values or Fxx commands
rate = engine speed (0.4.6 and before)
rate = 1000000 ÷ refresh interval (0.5.0 betas)

note: "stable interval" length = speed constant divided by the greatest common divisor of
the speed constant itself
and
floor(60 × rate) - mod(24 × tempo, speed)
One could derive this formula by inspecting the tempo counter variables (CSoundGen::m_iTempo* in tracker and var_Tempo_* in NSF driver) which share the same algorithm to control the song timing, then performing some algebra. In fact, this is one of the few features added to the unofficially released 0.4.6 NSF driver; before that even more rounding errors would result.

In particular, by using this criterion it is possible to show that these combinations are in fact not "absolutely" smooth, even though they appear to be so if real numbers are used: (the same assumption in the OP, albeit not in the same aspect)
  • 60 Hz, tempo 75, speed 7: F0F, followed by 256 F0E's;
  • 5555 μs (180.0 Hz), tempo 150, speed 6: F13, followed by 599 F12's (0.5.0 beta only);
  • 50 Hz, tempo 250, speed 7: 428 pairs of F04 F03, followed by F03. (F04 F03 is by no means "absolutely" smooth, but such two-element sequences have been in widespread usage for all trackers, whether for actual grooves or not.)
About the 0.5.0 beta tempos: in the playback rate dialog, if the calculated standard BPM is not exactly 2.5 times the integer value for the desired refresh rate, then all tempo values will have very large "stable intervals" under that rate. This happens precisely when

Code: Select all

floor(60000000 ÷ floor(1000000 ÷ rate)) ≠ 60 × rate
The values are tabulated here at the bottom. Do not use the beta builds if you need any of these refresh rates at all.

If, on the other hand, the refresh rate is not one of these values, and the tempo is exactly 2.5 times the desired refresh rate, the first expression should become identically zero; the tempo value would match the standard tempo and the ticks-per-row count should be the same as the speed value. As FamiTracker abstracts away the relationchip between these tempo values and the ticks timing, not every refresh rate can do this. (The "fixed tempo" feature from 0CC-FamiTracker 0.3.10 and above is added for this purpose.)

So the tempo and speed calculation are much more complicated than the wiki implies. It certainly would have been updated if new forum users can register at the FamiTracker wiki.
refactoring 0cc-famitracker

User avatar
ShrubRustle
Posts: 14
Joined: Thu Jun 04, 2015 9:05 pm
Contact:

Re: Tempo & Speed simpler than the wiki implies?

Postby ShrubRustle » Mon May 02, 2016 1:35 pm

HertzDevil wrote:

Code: Select all

rate = engine speed (0.4.6 and before)


Ok, I think I'm getting it. Is "rate" measured in Hz?

(also, thank you folks so much for the help!)
Last edited by ShrubRustle on Mon May 02, 2016 2:39 pm, edited 1 time in total.
I like to pretend I know what I'm doing. My SoundCloud

User avatar
HertzDevil
Posts: 475
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: Tempo & Speed simpler than the wiki implies?

Postby HertzDevil » Mon May 02, 2016 2:13 pm

In versions that support it, the rate is:
  • the integer value given in the engine speed dialog, measured in Hz, if a custom engine speed is used;
  • exactly 60 Hz if the default engine speed is used and the machine region is NTSC; (the corresponding refresh interval is 16,666 μs)
  • exactly 50 Hz if the default engine speed is used and the machine region is PAL. (the corresponding refresh interval is 20,000 μs)
0.5.0 beta defines "NES video rate" to be 60.10 Hz and 50.01 Hz for NTSC and PAL respectively, however their actual interval values are not used in exported NSFs, which continue to use the default μs values above. These settings only scale the default refresh rates, as otherwise a custom refresh rate that rounds off also to 60.10 Hz would result in F07 followed by either 99 or 119 F06's.
refactoring 0cc-famitracker


Return to “General Talk”

Who is online

Users browsing this forum: No registered users and 1 guest