Vxx does nothing in Famitracker VRC7, but when it exports, it changes the patch number.
_______________________
"im going to continue making this crazy stuff then after a while my style will be so sick that you will be like damn suuun that shit is so sick i dont even get it. i will be like bro its ok.. you dont have to." -omgdonut
Pulse 2 seems to manipulate Hxx/Ixx in Pulse 1.
In my SMB cover Overworld Warp song the song plays normal till
E-5 0B I11
Appears and the sound seems going down more heavier.
Restarting the Song without Pulse 2 the normal Warp sound plays.
NSF (Tested with Winamp Notsofatso, Winamp NEZplug++, VirtuaNES, NSFPlay, NSFLive and Nestopia) export doesnt seem to be attacked by that.
I'm not sure if this is already known or part of the program, but the volume is skipped on the first volume number. Normally, it's supposed to follow the code.
I'm not sure if this is already known or part of the program, but the volume is skipped on the first volume number. Normally, it's supposed to follow the code.
I have this problem with VRC6 as well. I haven't tested it, but I'd wager it happens on all expansions. 2A03 side works just as you'd expect though. I'd meant to report this, but I always end up forgetting to.
_______________________
The only things certain in life are death and uncertainty.
It is proper behavior. Instrument 22 starts at position 0 and uses slots 0-31. Instrument 19 starts at position 16 and uses slots 16-31. You need to be more careful when using N163
At the moment, FT will not allow you precise control of the pitch. For 2A03, using 2xx or a pitch macro in the instrument will directly change the 11bit period. So like using 201 will make the frequencies 458, 459, 45A, 45B etc.
In N163, it's 18bits of frequency but using 201 will make it change every 16 like 0458, 0468, 0478, 0488, 0498, 04A8 etc. Some for 4xy and similar effects.
They sound decent anyway, but the absolute control isn't possible in FT
BlipBuffer::bass_freq seems to be called with garbage parameters during program initialization, which leads [at least in Qt FamiTracker] *occasionally* to a divide-by-zero because sample_rate_ is 0. If the "low cutoff" value passed to BlipBuffer::bass_freq happens to be negative [as is observed in MFC FamiTracker], the check of freq>0 in BlipBuffer::bass_freq prevents the divide-by-zero. However, in Qt FamiTracker it seems the garbage value is sometimes hugely positive, and sometimes hugely negative. When it's hugely positive...exception!
.png)
.jpg)
