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?

## Tempo & Speed simpler than the wiki implies?

- ShrubRustle
**Posts:**14**Joined:**Thu Jun 04, 2015 9:05 pm-
**Contact:**

### Tempo & Speed simpler than the wiki implies?

I like to pretend I know what I'm doing. My SoundCloud

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

### Re: Tempo & Speed simpler than the wiki implies?

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

- Stratelier
**Posts:**378**Joined:**Sun Apr 26, 2015 7:46 pm

### Re: Tempo & Speed simpler than the wiki implies?

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).

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).

- ShrubRustle
**Posts:**14**Joined:**Thu Jun 04, 2015 9:05 pm-
**Contact:**

### Re: Tempo & Speed simpler than the wiki implies?

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])

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

- Stratelier
**Posts:**378**Joined:**Sun Apr 26, 2015 7:46 pm

### Re: Tempo & Speed simpler than the wiki implies?

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).

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

### Re: Tempo & Speed simpler than the wiki implies?

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: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)

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.

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)

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.)

Code: Select all

`floor(60000000 ÷ floor(1000000 ÷ rate)) ≠ 60 × rate`

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

- ShrubRustle
**Posts:**14**Joined:**Thu Jun 04, 2015 9:05 pm-
**Contact:**

### Re: Tempo & Speed simpler than the wiki implies?

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

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

### Re: Tempo & Speed simpler than the wiki implies?

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)

refactoring 0cc-famitracker

### Who is online

Users browsing this forum: No registered users and 2 guests