Use of percentages in the offset opcode - (offset_mode?)

[michael02022]

instead of an exact number, you can use a percentage from 0 to 100, where depending of the percentage result, that gonna be the section that will be skipped in the sample
if you write "offset=2%", it will calculate the result based on the sample size for each one
sample-size | result of 2%
sample 1: 35654 -> 713
sample 2: 75456 -> 1509
sample 3: 48289 -> 965
also you can use decimals like 1.5%
for precision
not sure if it can be done with the same opcode or should be a new opcode for that like offset%=2.1

[MTornPDX]

The current way of measuring offsets is pretty awkward. Should you really need to keep the sample rate in mind when setting an offset?
But rather than a percentage, which instead requires you to know how long your raw samples are, how about simply defining offset in seconds? After all, that's how we do almost everything else, like envelope times, delay, etc.

[mrbumpy409]

I thought offset= used number of samples within the wave file, not involving current host sample rate. This is actually really useful when precision offset is needed, e.g., quickening note attack, avoiding pop at start of note, better align phase between two waveforms, etc. I just hop into a wave editor, find the exact spot to offset to, and punch the sample number into the SFZ file.

[plgDavid]

Some ARIA Extension SFZs in the field already have been using a variant of this idea (since 2021 ish)
EG:
offset_mode=percent //switches the offset opcode from its default "offset_mode=samples" behaviour
offset_oncc257=50 //random offset from 0 to half the file

This is included in sforzando since v1.971

[mrbumpy409]

Seems like offset_mode would be redundant when one could just parse for a "%" sign after the number to indicate percent.

[redtide]

problem is that AFAIR there is no opcode using the unit at the end of the value, so it would make it less consistent with the rest, isn't it?

[mrbumpy409]

That's a good point. Perhaps a rule of SFZ 3 could be: any parameter that can optionally be specified in percentage would be specified so via use of a % sign following the value. I guess it would depend on how this handling would work with other opcodes, and how many other opcodes could reasonably have their values specified in this way.