Triplet Calculator

General discussion about tracking, help and support.
User avatar
SamW
Posts: 50
Joined: Mon Apr 20, 2015 6:35 pm
Location: Belfast, UK
Contact:

Re: Triplet Calculator

Postby SamW » Tue Aug 11, 2015 11:41 am

Perhaps I'm the only one seeing this, but the rebuttal replies were uncalled for as well. There's a way to react to criticism without looking like a spoiled baby.

Those are my two cents on the matter.
ym2612 extraordinaire, metal & edm producer, professional weeblord, head over heels for harumi

twitter
soundcloud
super famidev

User avatar
LarryLarington
Posts: 35
Joined: Thu Jun 25, 2015 5:27 am
Contact:

Re: Triplet Calculator

Postby LarryLarington » Tue Aug 11, 2015 1:52 pm

Stratelier wrote:
Anyway, here's a somewhat more interesting calculation than simply whether your tempo allows exact triplets:

Stability = LCM(60 * Engine * Speed, 24 * Tempo) / (60 * Engine * Speed)
(aside: the 60 and 24 can simplify to 10 and 4, or 2.5 and 1 respectively)

If the result is 1, your tempo is 'stable' (i.e. consistent # engine cycles per row). Otherwise, it indicates the # of rows across which your tempo is stable; e.g. if your tempo is 240, your stability is 4 (meaning if you have 4 rows per beat, then each beat as a whole is stable, despite that the rows within each beat are not).


This is actually pretty interesting. When you say a tempo is "stable," do you mean that there is a consistent integer number of ticks per row, assuming your ticks are defined by the tempo (ex: bpm of 150 corresponds to 3600 ticks/min)?

Here's the FT wiki I'm looking at for reference: http://famitracker.com/wiki/index.php?title=Fxx

So essentially there are certain tempos that result in rows with a number of ticks between two integers and thus cause problems -- shouldn't there just be a set list of tempos that "work" with Fxx commands then? Assuming you don't change the default video refresh rate/clock speed of 60 Hz (NTSC). For example, the document I linked says bpms of 128 and 150 are stable because each row has an even number of ticks. Thus everything in between is unstable?

I guess a little bit more clarity on your calculation would be helpful, since I might be misunderstanding what you're trying to say.
Current Project: TBD
Completed: Thunder Force IV - Count Down Continue

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

Re: Triplet Calculator

Postby Stratelier » Wed Aug 12, 2015 3:17 am

LarryLarington wrote:This is actually pretty interesting. When you say a tempo is "stable," do you mean that there is a consistent integer number of ticks per row, assuming your ticks are defined by the tempo (ex: bpm of 150 corresponds to 3600 ticks/min)?


Yes, stable means that every row lasts a consistent number of ticks; this can be valuable if your song involves effects that are measured in ticks (like arpeggio chords, and Sxx/Gxx values close to the row length in ticks) but it is by no means required -- if you want to specify song tempo as an arbitrary BPM and let the NSF driver worry about ticks-per-row on its own, go right ahead.

So essentially there are certain tempos that result in rows with a number of ticks between two integers and thus cause problems -- shouldn't there just be a set list of tempos that "work" with Fxx commands then? Assuming you don't change the default video refresh rate/clock speed of 60 Hz (NTSC). For example, the document I linked says bpms of 128 and 150 are stable because each row has an even number of ticks. Thus everything in between is unstable?

Tempo 128 (as in 128.00) is actually not stable per row (it is however stable across 32 rows).

Here's how you calculate BPM and ticks per row:

Ticks per row = 2.5 * engine * Speed / Tempo
(for NTSC, this reduces to 150 * Speed / Tempo)

The closest stable tempo is a fixed 7 ticks per row (Tempo 150 Speed 7) which is ~128.57 BPM .

150 BPM is a preferred tempo because it is stable on both NTSC and PAL engine settings: each row lasts 6 ticks on NTSC, five ticks on PAL. This makes some difference with frame-specific effects and instrument definitions (like your instrument volume curves) but otherwise allows a song to play at the same tempo regardless of which engine setting you're running.

I guess a little bit more clarity on your calculation would be helpful, since I might be misunderstanding what you're trying to say.

"Stability" as I mentioned it is how many rows correspond to a stable number of engine ticks. For example, on the NTSC engine a tempo of 200 BPM corresponds to exactly 4.5 engine ticks per row, but there's no such thing as a "half tick" in the NSF driver so what you get is one row lasts five frames, the next lasts 4, then 5, then 4, etc. Unless you're manually controlling it (with a series of F04/F05 commands) you have no way of knowing for sure which rows get 4 frames and which rows get 5, but you do know that every pair of rows lasts a consistent (stable) total 9 ticks.

Similarly, for an NTSC tempo of 160 every row should last 5.625 ticks, but again there is no such thing as a fractional tick so what you end up getting is five rows lasting 6 ticks alternating with three rows lasting 5 ticks (something like 6 5 6 5 6 5 6 6, repeat). Again, you don't know which rows are which but you do know that there are (consistently) 45 ticks for every 8 rows.

As an example of this, take the following FTM and play it. Then slowly increase the tempo from 150 to 180 and notice how the rhythm changes as you do so.
Attachments
stability-check-5.ftm
Unstable tempo demonstration, 150-180BPM
(2.33 KiB) Downloaded 40 times
Last edited by Stratelier on Wed Aug 12, 2015 5:16 pm, edited 1 time in total.

User avatar
LarryLarington
Posts: 35
Joined: Thu Jun 25, 2015 5:27 am
Contact:

Re: Triplet Calculator

Postby LarryLarington » Wed Aug 12, 2015 2:47 pm

Stratelier, I'm pretty sure you should just write the wiki on tempo at this point, hah! Thank you for all the clarification -- it makes a lot more sense now.

And just to test my understanding with your attached ftm, the rhythm changes as you move from 150 bpm to 180 bpm because you are slowly introducing "random" rows of 5 ticks until all of them are 5 ticks or fewer, right? Since the volume envelope/mute delay S05 will only sound at 6 ticks or more (due to 0 0 0 0 0 15 0 in the hat).

Very informative! Appreciate the write up. :)
Current Project: TBD
Completed: Thunder Force IV - Count Down Continue

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

Re: Triplet Calculator

Postby Stratelier » Wed Aug 12, 2015 5:03 pm

LarryLarington wrote:Stratelier, I'm pretty sure you should just write the wiki on tempo at this point, hah! Thank you for all the clarification -- it makes a lot more sense now.

lol. I tend to have a knack for explanations ... sometimes. (I can also be pretty pedantic and long-winded.)

And just to test my understanding with your attached ftm, the rhythm changes as you move from 150 bpm to 180 bpm because you are slowly introducing "random" rows of 5 ticks until all of them are 5 ticks or fewer, right? Since the volume envelope/mute delay S05 will only sound at 6 ticks or more (due to 0 0 0 0 0 15 0 in the hat).

Yes, that is absolutely correct. Rows lasting 5 ticks cause Triangle to blur together into a longer note (because the S05 is skipped in favor of the new note) and the Noise channel to not sound at all (due to the delay built into its volume curve). Also, if you keep the tempo at 150 but change the engine to PAL you will see the same thing happen because suddenly all rows are five ticks instead of six.

User avatar
LarryLarington
Posts: 35
Joined: Thu Jun 25, 2015 5:27 am
Contact:

Re: Triplet Calculator

Postby LarryLarington » Wed Aug 12, 2015 6:21 pm

Stratelier wrote:lol. I tend to have a knack for explanations ... sometimes. (I can also be pretty pedantic and long-winded.)


Well it made sense to me! Just stick to music and FT and you'll keep my attention. ;)

Yes, that is absolutely correct. Rows lasting 5 ticks cause Triangle to blur together into a longer note (because the S05 is skipped in favor of the new note) and the Noise channel to not sound at all (due to the delay built into its volume curve). Also, if you keep the tempo at 150 but change the engine to PAL you will see the same thing happen because suddenly all rows are five ticks instead of six.


WOOT. I CAN DO THE LEARNING! Incoming piece that evolves based on your tempo setting...

(yeah not really)
Current Project: TBD
Completed: Thunder Force IV - Count Down Continue

User avatar
///CH3DD4R/_
Posts: 79
Joined: Mon Apr 20, 2015 9:47 pm
Location: Amarillo, Texas

Re: Triplet Calculator

Postby ///CH3DD4R/_ » Wed Aug 12, 2015 6:24 pm

I really still don't understand it. Basically just because I have limited mathematical understanding, and I'm saving it for things I HAAAAAVE to learn for school (algebra, scary things.) I have no shame in saying that I have used cak's Tuplet calculator for years. Leel.
int main() {
}

Overlord99
Posts: 609
Joined: Sat May 09, 2015 4:31 am

Re: Triplet Calculator

Postby Overlord99 » Wed Aug 12, 2015 10:05 pm

///CH3DD4R/_ wrote:I really still don't understand it. Basically just because I have limited mathematical understanding, and I'm saving it for things I HAAAAAVE to learn for school (algebra, scary things.) I have no shame in saying that I have used cak's Tuplet calculator for years. Leel.

You and I are in the same boat in the "bad at math" regard, unfortunately. I don't really use triplet calculators, though. What I usually do is I do it by ear, in that I play around with the effects for a while until I hear what I think sounds right. And even then, it's not always 100% perfect.


Return to “General Talk”

Who is online

Users browsing this forum: No registered users and 1 guest