egN_ AHDSR style opcodes for simple envelopes

[AlexMitchellMus]

Currently in SFZ format in order to use egN the SFZ author needs to write out the eg as:

eg1_time1=1 eg1_level1=1 etc

This suggestion would be to give authors an easy, mnemonic syntax for simple ADSR style envelopes, which mirrors the already used ampeg_ style syntax:

egN_attack=
egN_decay=
egN_sustain=
egN_release=

This would mainly be for time saving, and when a more advanced description of eg's isn't needed.

[Gaeriel]

egN_sustain is already an opcode, but given that this would only be used as a shortcut for defining flex eg's, why not shorten it to egN_a, egN_h (hold), egN_d, egN_s, egN_r ?

[AlexMitchellMus]

I suppose in retrospect egN_sustain should have had another name, given SFZ already had ampeg_sustain.
However, given that it's intended for time saving, I think egN_a etc is a good idea.

Alternatively we could shorten the words? egN_att, egN_hol, egN_dec, egN_sus, egN_rel

[christophe-hall]

I would somewhat disagree unless there was a more distinct syntax for multistage envelopes, eg. msegN. The trouble is that egN is an ambiguous default for either creating a multistage envelope, and/or targeting a parameter other than amp / filter / pitch, and/or targeting multiple parameters with the same envelope. Personally I would rather see egN dedicated to DAHDSR (like the older ampeg / fileg / pitcheg) and a separate 'msegN' dedicated to freeform multistage envelopes.

[MTornPDX]

I agree with the original post, that there is a need for traditional envelopes to be used outside the main three functions (amp, filter, pitch). Flex EGs never really click with me, partially because they are pretty fiddly to set up, and partially because they are linear by default.

I don't agree that egN_a, or egN_att is preferable to egN_attack. While they save some typing, I think the spirit of SFZ is that it should be easily readable by humans.

But I do agree with Christophe, that in an ideal future SFZ (or SFZ-like) implementation flex EGs should be labeled msegN, and the egN should be traditional DAHDSR ones. This would also be an opportunity to retire the hardwired old ADSR implementation, shrinking and cleaning up the opcode list significantly.

Of course, none of this is compatible with the current SFZ, so it's only really applicable if there was a complete rewrite.