Allow the panning command to affect the panning fractional bits

[Swaguy14256]

Should not be too hard to implement, as all that is needed is a 3rd parameter for the hex command. The MML command might be less simple to implement, but I do not think it will be that hard. The trickiest part might be having to make this a hot patch so it does not break music sequences that use the hex command for panning, and only use 2 parameters instead of 3. Asking this to be a feature because some music tracks like the ones from the DKC trilogy use panning values that cannot be done in AddMusicK at the moment.

[KungFuFurby]

Increased panning precision? Well... OK. I thought this over. Expanding the parameter size of $DB to three bytes would normally not be practical, since it increases the filesize of all of the other songs. However, if I choose to go the route of expanding the $DB command, there's actually a free bit that can allow me to pull this off. I'll explain here using this theoretical specification (bitwise notation courtesy of asar):

• $DB %xyzaaaaa (bb)
  • %x defines a phase inversion switch for the left channel.
  • %y defines a phase inversion switch for the right channel.
  • %z means fractional panning is defined.
  • %aaaaa is five bits for the panning. This refers to an array of values to multiply the volume by after calculating the voice volume via various other parameters set by the VCMDs. Under normal circumstances, center is defined as $0A and the maximum value is $14.
  • bb is fractional panning, defined in 256ths. This only shows up if %z is set.

There are two things you need to be aware of. First, fractional panning has a precision limitation from the VxVOL DSP registers, and I am aware that fractional panning is handled internally and not just in fades because I actually fixed a bug where they were not cleared when switching songs. Secondly... this adds ASM filesize, something which doesn't come cheap.

And panning fades with fractional target values would require that I allocate an extra strip of variable ARAM. Those also don't come cheap.

[Swaguy14256]

Increased panning precision? Well... OK. I thought this over. Expanding the parameter size of $DB to three bytes would normally not be practical, since it increases the filesize of all of the other songs. However, if I choose to go the route of expanding the $DB command, there's actually a free bit that can allow me to pull this off. I'll explain here using this theoretical specification (bitwise notation courtesy of asar):

* `$DB %xyzaaaaa (bb)`
  
  * `%x` defines a phase inversion switch for the left channel.
  * `%y` defines a phase inversion switch for the right channel.
  * `%z` means fractional panning is defined.
  * `%aaaaa` is five bits for the panning. This refers to an array of values to multiply the volume by after calculating the voice volume via various other parameters set by the VCMDs. Under normal circumstances, center is defined as $0A and the maximum value is $14.
  * `bb` is fractional panning, defined in 256ths. This only shows up if `%z` is set.

There are two things you need to be aware of. First, fractional panning has a precision limitation from the VxVOL DSP registers, and I am aware that fractional panning is handled internally and not just in fades because I actually fixed a bug where they were not cleared when switching songs. Secondly... this adds ASM filesize, something which doesn't come cheap.

And panning fades with fractional target values would require that I allocate an extra strip of variable ARAM. Those also don't come cheap.

I actually forgot that bit 5 was unused, so that solves the compatibility issues.

As for the limitation of the volume precision, I do know that, mainly when dealing with lower volumes.

As for size, perhaps maybe in the future, there could be a way to have either multiple SPC programs, the ability to have per-track voice commands, or even allow commands to be dynamically uploaded to the SPC700, especially since more voice commands means less free space for music data, which must fit into the 65,535 bytes of RAM allowed. Implementing this is not trivial, of course, but should it be implemented, it can potentially save some ARAM space. After all, I highly doubt all voice commands available will be used in a single track (although seeing as that the ability to have multiple music sequences in ARAM is in the works, this may change things).

EDIT: Using multiple SPC programs is the easiest for freeing up ARAM space, but results in less ROM space. Per track voice commands can help with commands taking up space, but does not free up all potential space in ARAM. Dynamic command uploading frees up the most space, but requires some major changes that could possibly break everything. There may be a better way of doing this, as this is all just but a suggestion.

[KungFuFurby]

Nah. I'm against multiple SPC programs because it increases the loading times... in addition to having to jump to the IPL Boot ROM, since the loader used after the initial boot-up is actually internal to the sound driver.

Also, you're in luck, because #134 is in my records for doing such a thing. This system is currently in development, but not on AddmusicK: instead, it's on my own sound driver (not for Super Mario World). It requires a two-pass system... and, more importantly, for AddmusicK in particular, it has to compile to an ASM file and not just some hardcoded hex data to make detection easier and things more relocatable ID-wise, which means #228 is involved. Otherwise, it's pure mayhem for me to try to detect that kind of stuff on the C++ side, in addition to introducing a lot more potential problems down the road that may not be easily recompileable to fix, hence why I also have #323 present, since for the MML in particular, I actually have to disassemble the original data outright when using the old hardcoded hex data output, if I'm not going to massively reprogram the C++ side.