The volume part (aka the second number in qXY) is used as an index to a table to determine what the actual channel volume is. The table is this one:
CodeVelocityValues:
db $08, $12, $1B, $24, $2C, $35, $3E, $47, $51, $5A, $62, $6B, $7D, $8F, $A1, $B3 ; Normal, SMW velocities.
db $19, $33, $4C, $66, $72, $7F, $8C, $99, $A5, $B2, $Bf, $CC, $D8, $E5, $F2, $FC ; Standard N-SPC velocities.
The second row is used normally with #amk 2 (or in #amk 1 using the #louder option), and the numbers are divided with $FF (255) and multiplied with the channel volume to get the final result. So for example if you have qX7 with v200, the entry in the table (with N-SPC velocity on) is $99 (153 in decimal), which divided by 255 is 0.6, multiplied by v200 is v120, so that's what the actual volume will be. This also means that, since the v values are not linear, the effect of the volume quantization changes depending on how high or low the v value is.
For the note duration part, the number is used once again as an index to a table that determines how much the actual note duration will be:
CodeNoteDurations:
db $33, $66, $80, $99, $B3, $CC, $E6, $FF
and once again the formula is the same: divide the value in the table by $FF, multiply the result with the note length. I believe the tick at the end of each note is handled after this step (or two ticks if $F4$02 is not used), because the code doesn't actually "remove a tick", it just performs a check later to see if the channel is on the last (or penultimate without $F4$02) tick, and if yes it keys off the channel.
You can also see that these values are not linear, so for example q2X equals half of the note length. brickblock's results look accurate after taking into account the additional tick that's removed automatically (although since that tick is constant for all note lengths, the proportions change depending on the note length, so if you want to be accurate you should use the values in the table to do the proportion and then subtract 1 or 2 from the result).
Originally posted by musicalmanI have a suspicion that this changes as the number of channels increases, for instance the gap feels slightly larger as you add channels.
This sounds very strange, but who knows, lol.