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
Hi jsr!
First off, I should mention that I'm so thoroughly impressed with famitracker's current state! I've used 0.2.7 (both stable & the older WIP) for my various projects, and it has been an invaluable tool in accomplishing what I want to express in a NES tune.
Here's a couple of bugs I've encountered so far, as well as some interface changes & additions I would love to see implemented.
[b]- Bugs -[/b]
[u]Track solo bug:[/u]
Solo'ing a track during playback doesn't mute the rest of the channels -- it merely makes the channels ignore notes.
[u]Speed command wonkiness:[/u]
The speed command (Fxx) seems to be inconsistent between the tracker & the replay code. The tracker seems to have a habit of parsing the speed change on the next line -- instead of parsing it instantaneously.
Example here, using a rather unfaithful cover of Minuet in G I did in 5 minutes (sorry OCD folks :D ), with tri-channel metronome: [url=http://www.nanjamonja.com/muzak/tempowank.zip][b]tempowank.zip[/b]
Aside from the timing issue in the beginning of the song (which Dafydd mentioned about in [url=http://famitracker.shoodot.net/forum/posts.php?id=207][u]another thread[/u]), the NSF obviously doesn't have the weird speed command issues that the tracker has.
[b]- Additions -[/b]
[u]Alternative Note Delay:[/u]
Can there be a global/module properties option where it instructs the Gxx note delay command to hold its state for the remainder of parsed notes & commands in the channel (until a command like G00 disables it)? I usually use the note delay command in a channel for certain sections of my music (usually melodic duets) in order to bring more percieved depth, and having repeated instances of the command for every note makes the process a bit unintuitive.
Example: [url=http://www.nanjamonja.com/muzak/lol_true.ftm][b]lol_true.ftm[/b]
(specifically, the consistent G01 commands on the first pulsewave channel)
[u]Direct input of a note's octave:[/u]
One small editor change I would like is if I can directly edit a note's octave value. It's almost an insignificant feature, but sometimes I prefer to shift octaves for an existing note directly on a whim -- instead of having to change the keyboard's current octave & re-input the whole note, or use the highlighter + octave shift command.
I can't think of any more additions for the time being (aside from lower-priority stuff like having macro control for hardware sweeps), but most of my tracker usability quips have already been covered by others in this forum.
Once again, thank you for your hard work in making FamiTracker such a fantastic NES composition tool!
[size=1](p.s. yes this is chibitech in another account because i'm an idiot and forgot my password YAYAYAYERVHA79IE6HIORUAWEM4HCHKLHCFEWIT434[size=6][b]orz[/b]
Nice finds! I approve of the Gxx suggestion (infact, I don't even think it should be an option!) A while back, I pointed out the same thing with regard to the Vxx command, and how having it switch off automatically made usage labourous (thankfully that's been fixed now ) Maybe all effects should stay on until they're turned off/reset... that makes the most sense to me personally.
Also, as an aside, something that's piqued my interest is your use of constant speed changes in lol_true.ftm. I'm wondering why it is you did that, since it doesn't achieve a triplet feel or really do anything a fixed tempo couldn't as far as I can see? Or is there some sort of underlying technical rationale from the perspective of NES music innards that I have possibly no hope of comprehending? :D
Hi Chibi-tech. Amazing to hear that's it's been of some use! Hope we can hear some new stuff from you later. :D
The tempo quirk was quite easy to fix (but not the less annoying), funny that I didn't notice it myself for this long (the tracker's player code is a mess). I'll make a bug fixed copy available once I've also figured out the NSF timing bug.
I will also add those additions for you. Hopefully there will be an updated version soon when I'm done with virt's list.
Dave: I think the tempo changes was entirely to demonstrate the bug.
RE: Bugs (timing, solo), and some feature requestsPosted: 2008-01-25 22:39
[quote=tibitekutan]
I can't think of any more additions for the time being (aside from lower-priority stuff like having macro control for hardware sweeps), but most of my tracker usability quips have already been covered by others in this forum.
[/quote]
There should be a macro control for EVERYTHING! heheheh
[quote]
[size=1](p.s. yes this is chibitech in another account because i'm an idiot and forgot my password YAYAYAYERVHA79IE6HIORUAWEM4HCHKLHCFEWIT434[size=6][b]orz[/b]
[/quote]
LOL! Haven't laught that much for a while... I guess "tibitekutan" is the japanese way to pronounce "Chibi-Tech", or at least using available syllabs (well in hiragana/katakana, I don't know)?
Thank you jsr for helping me gain my original account back! :D
Hopefully I'll be able to share my recent completed works from famitracker soon -- i just need to prep up my haggling skills, so to speak.
[quote=Dave]Also, as an aside, something that's piqued my interest is your use of constant speed changes in lol_true.ftm. I'm wondering why it is you did that, since it doesn't achieve a triplet feel or really do anything a fixed tempo couldn't as far as I can see? Or is there some sort of underlying technical rationale from the perspective of NES music innards that I have possibly no hope of comprehending? :D[/quote]
Hahaha I had a feeling someone would catch that!
It was a trick I used to rely on long time ago when tracking on D.O.C. Soundtracker for the Amiga (where timing depended solely on Vblank speed). It took only a couple of years before Protracker eliminated that hassle by bounding a BPM tempo option to the Amiga's hardware CIA timer. (Since that hardware timer is readily available in every Amiga, why didn't Soundtracker just use this in the first place? IT IS A MYSTERY.)
However, since the NES doesn't have the luxury of having its own internal CIA timer or similar vein AFAIK[b]*[/b] (i think at most there's MMC3's IRQ timer? And even then, that's only an external solution that developers would rather use for the actual game mechanics/visuals), bounding NES audio to a fixed Vblank is the next-best thing to do (as well as the easiest to implement, which is why nearly EVERY NES videogame or anything that revolves around a PSG-based audio engine uses it).
Now considering that fine BPM control is dependent on having a variable timer to calculate everything, things start getting a bit hairy here. Since most NES music is bound within that fixed Vblank, there's no straightforward way of implementing a fine-tuned BPM. programmers have to now either #1: Deal with it, and use the speed command to swing a custom "tempo" just like in Soundtracker... #2: incorporate some simple timer code that works within the Vblank limitation and parses note & command events at the approximate frames... #3: Program an elaborate software timer that would inevitably eat up precious CPU cycles... or #4: Modify the play call rate in an NSF's header to something other than Vblank (in this case, 411Ah for NTSC), and hope someone incorporates that to some external timer if you were to play it on the real thing.
[size=7]* = If there really is an internal timer or some way to do it without resorting to a software calculation or at least without major CPU overhead, please do correct me on this.
Famitracker's BPM tempo feature uses option #2. Unfortunately, timing obviously starts going el-weirdo if you were to deviate from that VBlank fundamental, since it now has to approximate note events within Vblank frames (in this case, anything that's not within a multiple of 150BPM for NTSC / 125BPM for PAL).
As for the "true my heart" messaround, I wanted to keep it at the same BPM as the [url=http://www.youtube.com/watch?v=AdLAYBnIJyw][u]original song[/u] (which I ended up failing at anyway, as the original is a tad slower... argh!). Since the cover uses 13 frames each repetition of 4 lines, the BPM would be 281.25 ((225+300+300+300)BPM / 4 lines = 281.25). Since BPM is calculated in whole number integers (nevermind that the max tempo is 255), I didn't want to bother calculating a speed / tempo combination in order to achieve the same result.
Of course, I could have also foregone all that craziness and went with option #4 to get the perfect tempo. But I'd rather keep the song at least NTSC-Vblank happy.
Plus, I like having the reassurance that my stuff will play correctly on even the simplest of homebrew solutions with minimal code intervention.
[b]tl;dr = [/b]I'm a whore for pin-point timing on each downbeat, and I'm too lazy to find a similar tempo / speed combination without making note timings start to go haywire.
Don't follow my example, as it's the result of both bad habits and being a control freak within set limits.
Ah, sorry I thought Dave meant the first song. (Didn't read careful enough)
Actually, there is a good reason for the NES to always run audio in sync with Vblank, and not use any external timers. That's because how the picture processor works, it can only be interfaced directly after one screen is drawn and before the next screen will start. This leaves very little time for screen updates, so that moment must always have the highest priority. Now, running the music from another timer would simply make it collide with Vblank at some points. I'm not familiar with the Amiga hardware (except for Paula :D) but I'm sure this problem doesn't exist there (and neither in other computers, Nintendo was known for doing hardware that wasn't so easy to program).
Perhaps one way to resolve it would be to disable IRQs during screen updates, but that's probably noticeable. And I guess most NES musicians was fine with 60 Hz at the time.
So, running without video would allow an external timer to be in use, and I guess that's why it's supported in the NSF header. This would actually be kind of easy to do now when the PowerPak exists and allow custom designed hardware. But still requires that hardware if one is picky.
One other trick, still if no video is displayed, the DPCM channel can probably be used as a timer by using it as a periodic IRQ. But that would make DPCM unusable, and it's not certain that a period can be found that satisfies a desired tempo.
Anyway, I've adjusted the tempo code in the tracker and NSF:
and it appears to work now. But I found that the triangle clicking bug was reintroduced in version 2.0 of the NSF code (and I updated the APU code in the tracker recently so it's now also there) so I got to fix that also.
[quote=chibitech]Famitracker's BPM tempo feature uses option #2. Unfortunately, timing obviously starts going el-weirdo if you were to deviate from that VBlank fundamental, since it now has to approximate note events within Vblank frames (in this case, anything that's not within a multiple of 150BPM for NTSC / 125BPM for PAL).[/quote]
Interesting. Would this be why note delay triplets (G02, G04) only sound properly like triplets at speed 6/tempo 150, and any other speed seems to mess them up? Although that may be something else, because they still seem to mess up if you only change the speed and not the tempo, which from my understand should avoid timing related problems...
Anyway yeah, I knew it had to be something techy, but I think I got the jist of it. It is interesting though... it'll make me more hesitant to start fucking with the tempo controls too much, ha.
[quote=Dave]Interesting. Would this be why note delay triplets (G02, G04) only sound properly like triplets at speed 6/tempo 150, and any other speed seems to mess them up? Although that may be something else, because they still seem to mess up if you only change the speed and not the tempo, which from my understand should avoid timing related problems...[/quote]
You can think like this: speed is the exact number of frames per row when tempo is 150 (or 125 for PAL). So for speed of 6, there are 6 frames/row. That's why G02 and G04 works, it makes each row 8 frames instead. Default: 4 rows = 4 * 6 = 24 frames, triplets: 3 rows = 3 * 8 = 24 frames.
