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
He means how the tempo is set to 185 instead of 150.
I'm not very good at explaining this kind of stuff, but I'll try anyway...
Basically the NES runs at 60 fps (or 50 fps in Europe), but this doesn't affect only the video. This also is how fast the audio engine runs. Changes can only be made every 60th of a second in the audio.
When the "Tempo" is set to 150 in FamiTracker, the "Speed" value basically says how many frames to wait before going to the next line in the music. When the tempo is changed to a different value, it no longer stays within that "grid" and instead tries to estimate when the notes should be played.
Hope that made a little bit of sense... I don't know the real terms for everything so I'll wait for someone else to correct me XD.
Yes. It means that. If you leave it default and assign 6 frames (@60hz) to each row, then you'll end up at default 150bpm. If you change it to 7 per row, then it's 128.[u]571429[/u]BPM. 5 per row = 180BPM.
This also explains very clearly how we have the Gxx values for triplets at speed 6.
C-3
C-3 G02
C-3 G04
---
Since each full beat of 4 rows has 24frames in it, triplets would be putting a note every 8frames. So note at 0 frames, one at (6+G02) frames, and one at (12+G04) frames.
Took me DAYS to figure this all out and do the math. This info should be in the help file or the wiki at least.
[edit:]
But a workaround to the irrational tempi is to abuse Fxx. Such as having F06 and F07 alternating.
Irrational is probably the wrong word for the tempo. It's still a ratio. I'd call them integral/non-integral tempos maybe?
But yeah, 60hz framerate = 3600 frames per minute, and...
3600 f/min / (6 f/row * 4 row/beat) = 150 beat/min, which is the default tempo.
At 150bpm, the speed control means frames per row, but it only means that at 150bpm. The number of frames scales with the tempo. e.g. 175bpm makes the speed of 6 equal to: (175/150)*6 = 7 frames per row.
With values in between it's no longer an integer number of frames, if it's between 6 and 7, for example, then you'll get alternating rows that last both 7 and 6 frames (and you can't really predict which is going to be on any given row). The tempo will feel slightly uneven with non-integral row timings.
So, the general advice is to stick to 150bpm and just adjust the speed control, unless it's worth sacrificing evenness for tempo (maybe you need it to synch with something), but even then you can adjust the framerate instead (it doesn't have to be 60hz).
[quote=rainwarrior]With values in between it's no longer an integer number of frames, if it's 6.5, for example, then you'll get alternating rows that last 7 or 6 frames. The tempo will feel slightly uneven with non-integral row timings.[/quote]
I've never had tempo unevenness interfere with my enjoyment of any NSF ever. Heck, I've used non-150bpm tempo values when making stuff for ppMCK, and it's always sounded just fine to me...
I fail to see what the fuss with tempo is about. Why shouldn't I use 241 bpm (for example) if the program lets me do it and there's no noticeable ill effect to normally constituted human beings?
At the end of the day - from my point of view at least - it's a personal choice whether you want to be a purist (integer-only with Fxx alternance) or not, really, isn't it?
On a related note, how does fluidvolt's personal decision not to use an integer tempo value affect the quality of his piece in any way?
_______________________
Follow me on [url=https://twitter.com/jrlepage2a03]Twitter.
I record (some) NSFs on hardware. Feel free to [url=http://www.famitracker.com/forum/posts.php?id=3633]request a hardware render.
I used non-integral tempos throughout my Dark Side of the Moon cover, and it turned out okay, but I did notice it in parts, especially "On the Run". I wanted to keep in synch with the original as much as I could though, so I decided to live with it.
If you have a piece that does something on every row, it's quite noticeable.
A lot of old game soundtracks have the problem. I really hear it in [url=http://www.youtube.com/watch?v=7f9pnzcP1fU]Chip's Challenge on the Atari ST, though that didn't stop it from being one of my favourite soundtracks.
Anyhow, for original music, I will pretty much always want to use an integral tempo.
Oh, the other thing where this matters a lot is when you're doing arpeggios and other effects where you're working with frames and not rows. Without an integral tempo you will have a real hard time lining them up with each other, since it's hard to know how long any particular row will last.
And jrlepage, no, I don't think this particular piece suffers for it. I just like talking about frames. :P
[quote=jrlepage]
I've never had tempo unevenness interfere with my enjoyment of any NSF ever. Heck, I've used non-150bpm tempo values when making stuff for ppMCK, and it's always sounded just fine to me...[/quote]
Really? I DO hear it. It sometimes manifests itself as a slight swing even though the tempo and actual note placements are even.
Ditto on the frame talk since I just figured it out.
[quote=nicetas_c]Anyway, good luck finding some NES game that doesn't use integral tempi.[/quote]
What's your point? Okay, fine, the original hardware didn't allow it. Got that. So what?! Why should I restrain myself from using it when both programs I use (FamiTracker and ppMCK) allow me to use any tempo value with little to no consequence? Besides, neither the NES nor the Famicom supported multiple expansion chips (the PowerPak is a recent device, just in case you were going to use that as an argument), yet ppMCK lets you create such NSFs.
My point is, how does using a tempo value that's not compatible with the hardware make an otherwise good tune bad to you or anyone else? (but you specifically, apparently)
[quote=nicetas_c]With some algorithm every tempo would be integral.[/quote]
Now you're just trolling.
_______________________
Follow me on [url=https://twitter.com/jrlepage2a03]Twitter.
I record (some) NSFs on hardware. Feel free to [url=http://www.famitracker.com/forum/posts.php?id=3633]request a hardware render.
I called it non-integral, because I thought calling it irrational was irrational. Integral meant that the length of a row in frames is an integer, thus not requiring any approximation by a wobbly row length.
Your example is a good way to demonstrate the problem by making the row lengths explicit. It doesn't make them any more regular though, so... you haven't made the row length integral at all, unless maybe your definition of integral is "the tempo says 150"?
Also, if you wanted to apply this to a song with 64 rows per pattern, since 77 is relatively prime, you'd end up with 77 different Fxx skip patterns, and your piece would need to be exactly that long if you want it to loop without incorrectly missing a frame somewhere.
.
