tweak clipping of .XM so that it matches ft2(-clone)/milkytracker

[coderofsalvation]

I've noticed that milkytracker & ft2-clone clip in exactly the same way, but bassoontracker not (it has much more headroom, perhaps because of the higher float-resolution?).

I was talking to 8bitbubsy (ft2-clone) about the fact whether there's even something about it in the spec.
He said:

"At full amp in the FT2 config screen (32x), one voice equals full volume (0dB, peak). And about clipping, FT2 clamps the final 16-bit value after mixing of all voices is done, right before it sends the mixed stereo stream to the sound card
So it has a 32-bit integer mix buffer"

Maybe we can clamp the mix to 16 bit values (and adjust 0db to the maximum value of 16bit?) so that it clips everything beyond that?

kind regards,

Leon

background: some of my modules (and other producers who use daws) use clipping in a musical way (boost transients of a mix to pierce through other sounds, which are shaven off when clipped, to increase perceived loudness).

[coderofsalvation]

how to reproduce:

use a normalized sample (bassdrum e.g.) as follows:

row 8 and 12 should start clipping (beyond 0db)

[steffest]

Hmm... good point...
Internally, because it's using webaudio, all sample data ends up as floats, indeed, affecting clipping. (and other things)
BassoonTracker doesn't do any mixing in script, it just hands that over to webaudio, so there's no easy way of clamping that final mixed value to a 16 bit int.
I'll have a think about that.

[coderofsalvation]

interesting challenge indeed.

It turns out "JavaScript Numbers are Always 64-bit Floating Point", so at least that's a fixed size which can be worked with (before sending it to WebAudio)..so I guess somewhere values exceeding 16bit needs to be shaven off...and then normalized back to 64bit floating point.