HertzDevil wrote:
The current implementation of my arpeggio scheme is that, when the arpeggio sequence is in Scheme mode, the 6 low bits represent the signed root transposition from -27 to +36 semitones, the range of which is specially decided to allow 3 octaves above. The 2 high bits determine how the 0xy parameters affect the arpeggio sequence's terms. There are 4 possibilities here, three of which are "root", "+x", and "+y" using the 0xy effect's parameters respectively; the last option is undecided yet and has a few candidates:
- Subtract Y;
- Add X+Y;
- Add XY (7-bit signed) when MSB of XY is off, fix to XY (7-bit unsigned) when MSB of XY is on.
I would most likely go with "-y", though the functions of schemes that use both "+y" and "-y" like {| 0 -y y} would be quite limited. To ensure that non-looping arpeggio schemes always produce the same result as it transitions from the arpeggio scheme to the ordinary 0xy effect, the 0xy's internal counter will reset every time the pattern encounters an instrument using an arpeggio scheme. The sequence editor will resemble the Sunsoft 5B Duty / Noise interface and the MML field will display "x" and "y" properly instead of 8-bit signed integers as in the YouTube preview.
#59509, #59514, #59539: The ASM hack is fully working. I have used the ASM hack to reduce half of the instruments in the Extends Levant FTM, and the NSF exported by FamiTracker produces the same sound as FamiTracker itself, although only those experienced with manipulating FamiTracker NSFs directly from the binary data could see the arpeggio schemes in action. This should clear any doubts that the NES APU or the 6502 ASM is incapable of performing such feats as redefining the 0xy effect per instrument during run-time of the sound engine.
#59507, #59520, #59570: Some of the posts in this thread mentioned LSDj tables. This is not the purpose of arpeggio schemes (or Uxy); they allow the 0xy effect to update the arpeggio parameters shared by both arpeggio schemes and 0xy itself, whereas sequence call, as in the Axx Run Table effect, simply invokes another sequence in the memory and resets the sequence position. This is not impossible, as the sequence calls can simply be parsed into 16-bit pointers to the respective sequences during NSF compile-time; however, sequences are separated by regions of action (volume, pitch, duty etc.) in FamiTracker, and at least 5 different effects are required to access all kinds of sequences as the original post suggests, but in reality there are not that many effect slots remaining (KLMNO?). Alternatively it could be as suggested in another post that X and Y represent type and sequence ID respectively, or the 2 high bits represent type and the 6 low bits represent sequence ID. Unfortunately, this would lead to the same bad design FDS instruments have w.r.t. sequence instruments, namely that sequences of an instrument do not all have the same operations as Hi-Pitch could not be accessed. Furthermore, each channel (times 2 if you count the work-in-progress sound effect channels) then requires 5 generic parameters for each type, independent from each other, which may cause a large increase in the RAM space needed by the NSF engine.
#59520, #59530, #59553, #59566: LSDj tables do not carry variables that can be passed from pattern effects. The transpose column of LSDj tables can be globally transposed once more in the phrase editor but their entries cannot, meaning triadic chords still require 3 tables to realize all inversions of any given arpeggio scheme. LSDj tables do not mix either; each new table is already initialized with zeroes and will cancel out parts of the current table if these zeroes remain. Sequence calls are therefore more powerful than invoking entire tables which are practically same as instruments in FamiTracker; tables are not aggregates of independent command sequences.
#59530: FYI the Software Creations sound engine (as in Silver Surfer) uses note sequences - like fixed arpeggio sequences, but with zero information of each note's duration. The entire note sequence is referenced by an address pointer, no other variables are passed. A separate command sets the note duration and another specific arpeggio command generates such arpeggio sequences:
{0..0 | X..X 0.....0}
repeating 0 for A times, setting the loop point, repeating X for A times, then repeating 0 for B times; here A and B vary to generate all arpeggios you hear in Silver surfer. There is one more command that transposes the entire channel, so that those fixed values can behave like movable values. Thus these arpeggios are not more complex than those in FamiTracker.
#59528, #59536, #59608: Arpeggio schemes need not have any default parameters other than the trivial xy = 00 in the same way Ixx and Jxx on the FDS channel do not carry any default values, though such a default parameter can indeed be added to each instrument akin to each FDS instrument's individual FM rate when Ixx and Jxx are not used. That default parameter would be useful only while previewing the instrument and should not export to the NSF. (If you press Ctrl+Enter to preview one row, the 0xy on the same row will affect the instrument's arpeggio already; the same goes for FDS FM and arpeggio schemes)
#60058, #60059, #60064: Upon entering effects which share the same name, FamiTracker will automatically apply different effects to the pattern depending on the channel it belongs to; thus, Hxy on 2A03 and Hxx on FDS are two distinct effects on the enumerated effect list. There isn't one H effect that acts differently across 2A03 and FDS channels. One bug of the text importer is that it might not check the expansion chip and put the hardware sweep Hxy on the FDS channel instead.
#59562: I have not seen a single FTM with an engine speed of hundreds hertz that tries to use this E0x effect to maintain arpeggios of the same pace as those at 60 Hz.
