My changelog:
As I write this, I realize how simple the other documentation is compared to the music page. It's not a problem, it's just...interesting.
Going off of how rulz explained these effects, I added this distinction to describe the sole rule that Channel 3 has about its effect limits. Previously we thought that Channel 3 was incapable of any effects other than 0xy, E8x, ECx and Cxx. The previous documentation even forgot to include that Channel 3 can use effect Cxx.
This is so the information translates across to more trackers, and using the currently popular OpenMPT and MilkyTracker as examples to follow.
Volume "flooring" to multiples of 4 and Channel 3's volume "rounding" were finally covered (thanks rulz!)
I also made it clear that non-distinct volume numbers for the channels can still be entered without drastic problems. I also made sure to include base 10 and hexadecimal examples to accomodate for all users, and gave examples in base 10.
@emninem did a great job on this example. I did expand on a few of the potentially-ambiguous uses of "this" and "that", and avoided using contradictory language like "meanwhile".
I removed the segment I wrote about how I'm denoting hexadecimal numbers. I instead opted for Base-10-First. (0hx following) by adding "hx" to the end of the hexadecimal instrument numbers that I'd previously added.
I also simplified the description for which instruments that each channel can use. The best concise example is here:
The wave channel gets 8 instruments (from 8 to 15): is now Channel 3, the wave channel, has 8 instrument options:. The numbers of those instruments are already listed below as-needed.
Any cases of describing the noise instruments as having "The same waveform but faster" I mostly changed to "etc." to make the list easier to parse. This is still not a great description system and I'm convinced that someone other than me needs to make this part easier to skim because I haven't found the best solution yet.
Updating the old monospace text formatting of AntonioND's Effects table with Github Markdown formatting
As previously mentioned, I also split up the effects into "Note-effects" and "Command-effects" going off of how rulz described it. This is a lot easier to compartmentalize, especially as Channel 3's effect restrictions only apply to Command effects. This note is included below the Command-effect table.
I also tried to better-explain what each effect does. Note-Cut's old description of 0 < x < speed-1 only made sense to me just now despite reading the docs for almost a year, so now Note Cut's requirements are written in words rather than a math equation.
We now have sound effects! I felt this was important to emphasize in the FAQs so as to not completely remove those contents. This question may be redundant as we can just advance to the next page to show that sound-effects can be done.
The question on .midi to .mod tried to explain the process in the question's answer, and it may be best to simply link a page that explains how to do it for OpenMPT. That process should be documentation for OpenMPT, not GBT Player/GB Studio, but it's good that we still acknowledge this FAQ in this documentation.
I followed these two guides: http://www.plainenglish.co.uk/files/howto.pdf and https://docs.godotengine.org/en/stable/community/contributing/docs_writing_guidelines.html as part of my reasoning. I did not follow these guides strictly, but felt it was necessary to better-convey the information that's in these docs. This included removing words like "please", "basically", and "so". Some sentences were reworked to allow the document's information to appear sooner in various sentences. For example, one of the earlier sentences used to be There may be only 4 channels in your .MOD file. whereas now it is .MOD files need to use 4 channels.
Some of this document's information extends into the documentation of other trackers (which is fine) but I think this information should be limited and links to those trackers' documentation should be linked when it's appropriate. It's better to link to a dedicated community that updates their documentation rather than to write our own from scratch. I think what has been done in these docs is perfectly fine, but that's my mindset going forward if we want to keep refining these docs for the GB Studio community. Most of the ending FAQs and tips I kept in-tact because they provide useful information that is otherwise hard to find, but I still think space could be saved with resource links rather than re-explaining programs that we're not as familiar with. Just some thoughts about how to move forward from here.
I reaaally had to hold myself back from redoing everything so I hope I did well at not omitting anything while adding new information that the community has discovered about GBT Player.