Loop and Endpoint metadata and Minimum Viable Opcodes in SFZ

[baconpaul]

In #1310 I stopped wav files from clobbering points they shouldn't but I still ignore quite a few opcodes. So here's the rules

1. If loop_start / loop_end are defined in the SFZ, that wins
2. If loop mode is set use that
3. If they are not defined and the wav file has loop points, then use those loop points and set to loop_continuous if loop mode is not set

and similarly

1. if offset and endpoint are set use those
2. otherwise use the entire sample

this is basically just detecting the state of the SFZ at variant parse time, reading the opcodes, set up the state, and then change the ENDPOINT | LOOP in #1310 to something which backs down from that.

[baconpaul]

More feedback from job23.10:

I do recommend to support the basic opcodes SFZBuilder mappings use, which are:

sample
pitch_keycenter
lokey
hikey
key (pitch_keycenter/lokey/hikey has the same value)
tune
offset
pan (for L/R mono samples that has different length)

loop_mode
loop_type
direction
loop_start
loop_end
loop_tune (if SCXT supports such feature)

These are the essential opcodes to construct a mapping basically, everything else is "optional"

For the pan, this is for L/R mono samples that has different length/size, old libraries used this and in SFZ are pan=-100 pan=100

For key can be combined with hikey or lokey to extend the region while the root key is the start of the region.

<region> sample=piano1.wav key=60 hikey=71
<region> sample=piano2.wav key=72 hikey=83
// and so on, this helps to simplify the mapping syntax

[tank-trax]

job23.10 added

oh, I forgot seq_length seq_position too, but this I guess is obvious for any format that supports it.

and

'lovel' and 'hivel'

[baconpaul]

From dj.tuBIG/MaliceX another confusion between where the data originates with a great repro.

Easier reproduction steps:

from the repo, load YM-FM_Font Music Box.sfz play chromatically also looks like wav sample loop points (given these are unspecified in the sfz) are now being ignored? (i think you'll probably see me referring to these quite regularly as a form of regtest :P) meanwhile gdi need to sort out what's going on, had to use the nightly build this time round cause vs2022 decided to update itself and now pulling latest HEAD doesn't wanna compile I'm gonna have a guess and there's some code somewhere that's stacked default keytracking to the same sample multiple times (since this particular sfz re-uses the same samples for multiple zones, noting they would be using the same sample using differently-written paths un-normalised)