lock_ prefix for all opcodes

[alcomposer]

Reason why lock_ needs to exist:

sfztools/sfizz#362 Has made it clear that SFZ rgc:audio & Cakewalk has some opcodes that are locked, as opposed to being able to be overridden.

For example:

<region> sample=a.wav pitch_keycenter=sample key=51

As key sets three opcodes: pitch_keycenter, lokey & hikeyto the same value, then the above SFZ script would set the playback to:

pitch_keycenter=sample
lokey=51
hikey=51

Even though key opcode (which normally sets all three opcodes to the same value) is placed after pitch_keycenter.

Discussion of lock_ opcode prefix:

With a lock_ prefix for opcodes, a lib maker would be able to replicate this behaviour- in a consistent and verbose manner.

lock_pitch_keycenter would allow the keycenter setting to be immutable, and only changeable by either another lock_pitch_keycenter or lock_key=.

A simplified example:

<group>  lock_sample=a.wav
<region> sample=b.wav
<region> lock_sample=c.wav
<region> sample=d.wav
<region> sample=e.wav
etc...

• First region would play a.wav
• Second region would play c.wav (as another lock_ is able to override a previous lock_)
• Third region would play a.wav etc...

lock_ prefix, while solving the above mentioned issue in pitch_keycenter=sample, would also clearly communicate with the library maker that an opcode is locked. And would also allow library makers more freedom, and expressiveness when working with opcodes.

It would allow a library maker to quickly swap out samples present in a group, without having to change every sample in regions.

For example - if a library maker was wanting to quickly test how the instrument behaved like if using a *sine wave for testing purposes, then it would be as simple as writing:

<group> lock_sample=*sine
<region> sample=a.wav
<region> sample=b.wav
etc...

[paulfd]

Hi Alex ! I'm not sure I'll have time to read all your discussion on the chat, so maybe we can argue here. I have to say that this will add a lot of complexity to the code in a first approximation, if you want to make it on all opcodes.

For the actual use, in your first example you could have

<group>  sample=a.wav
<region> 
<region> sample=c.wav
<region> 
<region>

which would achieve the same result right?

Your last example is valid but it's more of an intermediate thing while developing a lib, a process that is bound to be a bit messy and hands on. I wonder how necessary would the added complexity is warranted.

[alcomposer]

@paulfd Thanks for the thoughts. Possibly lock_ should only be applied to opcodes that need to be able to change the SFZ format rule of: "Newest Opcode Wins".

From my understanding of the conversation this would only be the key, lokey, hikey & pitch_keycenter opcodes?

The example I gave of sample and lock_sample was intentionally simplistic. I am sure however that there could be much more useful examples of how a universal lock_ prefix would improve the grammar.

[DSmolken]

I can see this as simplifying things like implementing the transposition trick. So, nice for the instrument developer, though it would only simplify things that are currently possible, not make currently impossible things possible, as far as I can tell.

So I can see uses for it, but I'm not gonna lie and say it's something I'd want to have the job of coding.

[jpcima]

Suggested as an alternative, use the := notation.

<group> sample:=a.wav // it's locked