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
Is it possible to use a hardware sweep without resetting pitch? Hxx/Ixx always begin from the last used pitch, even if you use several of them in a row.
An interesting side effect of this is that H00/I00 actually produce a phase reset, since FamiTracker always writes both pitch registers at the sweep event, regardless of their current value. Doommaster1994 pointed it out to me; he was using it to put phase reset clicks into sustained notes.
If we had a different two commands, we could do a few other things, like construct a wide vibrato that won't click on A-3, or maybe just a long sweep that changes velocity or goes up and down. Also it would just be nice to be able to sweep up or down after the note starts without that unpleasant noticeable click.
Alternatively, the pitch writing behaviour of Hxx/Ixx could be removed, and old documents could be maybe converted by sticking an extra note-on on any row with a sweep (wouldn't catch 100% of cases, but might be okay for most; I guess you would only be able to find the note to use if it appears above in the same pattern, and macros would be out the window a bit; might be better to not convert at all). Unfortunately this would remove the (unintended?) ability to reset phase with H00/I00.
Good point, I haven't thought of that. As you say, this would probably be easy to change and the compatibility with existing tunes can be fixed by inserting more notes.
Regarding the phase reset stuff, one thing I've been thinking about is to insert an option in the instrument editor to always reset the phase on new notes. Would that be useful?
I've seen such a thing when covering the Trainer Battle theme from Pokemon R/B/Y. I even zoomed in on the ripped audio and the phase resets to create a new note, as seen in the wave channel when notes are repeated. It differentiates the notes without muting the channel even for a frame. (Also I didn't know hardware sweep could so a phase reset, but it doesn't look like it works for FDS. I'm still not sure what hardware sweep is, anyway.)
_______________________
[url=http://icesoldier.me]Website (includes FTM's of my covers)
Hardware sweep only works on 2A03 square channels. It's a feature that automatically sweeps the pitch up or down instead of the program having to do it manually. I guess it was intended mainly for easy implementation of pew-pew/jumping sound effects.
It's also slightly nicer than manual pitch sweeps because they're (sort of) logarithmic, so you get roughly the same interval-per-time at any starting pitch. Also because it bypasses the unavoidable phase-reset click you get when writing the high pitch bits.
Here's a comparison, try muting either channel to hear the difference. With the 2xx version there's at least 6 clicks or so on the way down (easier to hear if you slow it down), and notice how I have to keep increasing the value to keep up to speed with the Ixx version. Also note how the Ixx sweep is very even, the pitch speed is percpeptually constant (that's what I mean by logarithmic), whereas if you don't increase the the 2xx value it slows down as the pitch goes lower.
Also, a phase reset instrument option would probably be useful. Something that springs to mind is trying to do octaves in S1/S2; with phase resets you could get a consistent sound. Or like Doommaster1994 was doing, just to break up a sustained note without stopping the sound.
Far more useful would be modifying the sound engine to use a HW Sweep to change the high byte of the period, and eliminate the clicking on pitch effects when they are at certain notes. Only issue with that is that you basically disable any other use of hardware sweep if you do that.
Dwedit, I don't think that's really possible... Assuming you could reliably get the required value change with the bit-shifts, I don't think you would be able to stop the sweep and correct the low bits with accurate enough timing to prevent some kind of artifact.
A far, far simpler solution to this is to just put a toggle option in your sound engine that eliminates the phase reset on write of the high byte.
You don't need precise timing, writing to $4017 resets the sweep timer, causing a sweep shortly after the write.
And you don't need to get the low byte correct, just the high byte. Low byte can be overwritten shortly after the sweep changes the high byte.
I've seen people make sound engines that took advantage of this.
"Low byte can be overwritten shortly after the sweep changes the high byte" This is exactly what I meant when I said "correct the low bits". The question is when exactly the sweep will change the values. Presuming that it reliably happens just before the frame interrupt, there will still be some time between the sweep update and your code fixing the low bits where the pitch will be wrong (maybe this is short enough that it doesn't really cause a problem?).
I dunno, just seems a really complicated thing to try to pull off. You'd need to be issuing the sweep a frame ahead of time, for one thing.
What music engines take advantage of this, and do they run properly on a real NES? I'm curious. (I wish I had an NES I could test it for myself...)
Edit: all I've really seen on the subject is this NESDev thread: [url=http://nesdev.parodius.com/bbs/viewtopic.php?t=231]http://nesdev.parodius.com/bbs/viewtopic.php?t=231
But that thread lays out like a billion complications of trying to do it. Rereading it, I see that you can manually clock the sweep unit, apparently (solving the timing problem), but doing so messes up the frame counter (that you might want to be using for other things). And nothing in this thread is anything close to a complete music engine that generically sets the high bits via sweep. (If you've seen something that does it, though, I'd be really interested.)
Using it for vibrato seems quite practical. (Though I wonder if the pitch would slowly rise on Square 1 due to the extra -1?)
I have tried this technique actually, but one problem was that some NSF players wasn't accurate enough to handle this. Some didn't clock the sweep unit directly on the $4017 write.
Back to the original request, there are two unused bits in Hxx/Ixx. Maybe you could specify the pitch-write behaviour with one of those bits. e.g. H16 (don't write) vs H96 (write) would be the same sweep settings, but one writes pitch. This would let you convert old stuff properly as well, and let people who were using H00 for an intentional reset keep using it (as H80, or however those bits are used).
I guess I would also request an option to turn off phase resets in the audio rendering itself. Obviously it shouldn't be on by default, for accuracy's sake, but it's a nice option to have, and a relatively small code change. (Much easier than trying to use sweeps to do it robustly.)
When I rendered my classical album I hacked it myself to do this. I was careful not to do things like wide vibrato on A-3 when working on it, but it was still nice to get rid of the unwanted pops on note-on, even though it isn't authentic.
[quote=jsr]I have tried this technique actually, but one problem was that some NSF players wasn't accurate enough to handle this. Some didn't clock the sweep unit directly on the $4017 write.[/quote]
I think there might be a workaround...
You can use the channel length counters to test if the emulator clocks the frame counters correctly. If it passes the test, chances are good it's a more accurate emulator which will bother to get the details right.
Most of this stuff is over my head, but if the actual hardware can do something you're trying to get properly emulated, then any player worth its salt should support it; raise the bar.
I don't agree with that suggestion. Completely hardware-accurate emulation doesn't exist anywhere. [i]Every[/i] emulator compromises something somewhere, often for code simplicity, often for speed, sometimes by mistake or ignorance, sometimes because the actual hardware behaviour is unknown altogether.
I'd hate to see FamiTracker generated NSFs be unplayable on most mobile phones, for example, just because it uses a novel technique to eliminate a couple pops here and there. That's not a good trade to make.
