OpenMPT supports several v2 opcodes. I suppose you are talking about the <curve> section in particular?

I was thinking about about opcodes such as

https://sfzformat.com/opcodes/egN_timeX

https://sfzformat.com/opcodes/egN_levelX

which, if my understanding is correct, could capture the multi-point amplitude/pitch/filter envelopes that makes the iti and xi formats so great.

To be clear I tried to export some instrument to SFZ, then import in both OpenMPT as well as a SFZ player, and the multi-point envelope was gone. Reading the content of SFZ file I only found ampeg_* opcodes, which is why I (wrongly) inferred that only v1 was supported.

Ah, I was not aware of flexible EGs. The SFZ documentation probably did not contain them the last time I was working on SFZ stuff (and it still appears to be incomplete). I'll see what I can do about that. More complex looping stuff doesn't seem to be supported, though, only loop points, unless https://sfzformat.com/opcodes/egN_loop is incomplete. But at the very least retaining the envelope shape would already be a good start.

I played around a little and got limited support for envelope export now. Loops don't work though (Tested against sforzando/Aria, I have no idea how this is supposed to work, if at all).

Cool! I'd try it but I'm unsure how to compile OpenMPT under Wine (couldn't install VS 2019 community).

You'll be able to receive test builds from https://builds.openmpt.org/builds/ once I have commited the code (maybe tonight / tomorrow).

Some improvements have been made as of r12533, which should be available from the aforementioned site in a few hours.

Many things about flex EG looping are not quite clear yet, so this is still a very rough export. Import is not supported at all yet.

r12534 also imports flex EGs (and fixes some smaller errors in the envelope output that was implemented in r12533).

Some feedback on the new functionality would be appreciated. I have not received any answers regarding the looping stuff yet, so I'm not sure yet if it can be done. If you have the possibility, please also test the exported files against other SFZ-capable software. So far I have mostly tested against sforzando.

I extremely appreciate your work on that, thank you so much! I started to test it, but with a bit of struggle. The only software I could run so far that supports SFZ2 is LinuxSampler and it crashes shortly after playing my converted preset (but what I'm hearing so far seems correct!).

I'll do a thorough testing (try sforzando under wine as well) but it's gonna take me a bit of time.

I actually tried to look at the linuxsampler code to get an idea how some values should be handled but I was a bit lost; officially it should support most EG stuff but I simply couldn't find it being used in the code. So I'm not even sure if it would be possible to test this feature with linuxsampler, but no matter what it should of course not crash. :)

Some more changes have been made, in particular in r12540. Playback at the end of an envelope should now be more consistent between OpenMPT and "real" sfz players, at least based on my observations of sforzando.

Cool. I didn't have time to test thoroughly yet but from what I've heard the amp envelope is pretty faithful. The filter however not so much. Maybe this comes from the conversion of Q, would need more testing to tell. If time permits I'd like to see if I can come up with a good formula of the conversion... (BTW, I'm quite busy for the next 2/3 weeks thus might not be very responsive, but I'm more than happy to provide feedback and help as permitted).

The one thing that I find odd, but it's most certainly a problem with SFZ (or perhaps sforzando, though both sforzando and linuxsampler display the same -undesirable- behavior) is that ampeg_release is only taken into account once the envelope has reach the sustain point, before that, release seems to be fixed and set to a very short time. Now I know that iti ignores the release time when an envelope is defined, however the difference is that the release before the sustain point is infinite (rather than close to zero as in SFZ). It's not a big deal because I can always hold the note or use the sustain pedal, but I find this behavior odd and unexpected. I might ask the linuxsampler forum about it...

The filter however not so much. Maybe this comes from the conversion of Q, would need more testing to tell.

The filter conversion sounds pretty correct to, however you have to keep in mind that IT's filter is slightly "non-standard" - it saturates the output in a way that none of the SFZ filters do. So especially frequencies around the resonance peak will sound slightly different. But if this saturation is not reached, then the filter output should be relatively identical.

I should probably also add that filter import only works well for negative filter envelope values, because that's how the IT filter envelope works (it only subtracts). For SFZ files saved with OpenMPT this is obviously not a problem, but for SFZ files from other sources, the filter envelope conversion will not be very faithful

ampeg_release is only taken into account once the envelope has reach the sustain point

From my experience, the problem is a different one: ampeg_release is always taken into account correctly, however I think in SFZ the fadeout is supposed to be logarithmic, while in IT it's linear. This causes the fadeout to be sound much shorter in an SFZ player compared to the original IT fadeout value. I don't think we can find a perfect solution for it - a faithful conversion will almost always require additional manual work, but I hope with the current code this manual work can now be kept at a minimum.

If there is no remaining questions, I suggest we close this issue for now, and if you have any further suggestions or bug reports, they can be put in a new issue.

I have carefully tested 26 presets. Aside from the release problem, the various EGs (amp, pan, pitch and filter :-) ) are extremely faithful. Well the filter resonance isn't perfect, but as you explained it is not the same filter, so it makes sense, and in any case, it is very acceptable.

Regarding the release, there are 2 problems:

1. Because the iti "fade out" kicks in at the last point, while in sfz the release kicks in when the note is released (with the exception of what seems to be a bug to me, see below), thus when there's a complex envelope after the off note, it tends to be faded out way too early.

2. As you pointed out, iti "fade out" is linear while sfz release is exponential.

Here's what I suggest, for each problem:

1. Set

amp_release = fade-out-time + envelope-after-off-note-time

2. Multiply amp_release by some factor > 1, I'm not sure which, it might depend on psycho-acoustic notions that I don't know, maybe so that both linear and exponential curves have the same integral, not sure. Anyway, all that to say that I don't think it's a big deal that one is exponential and the other is linear as long as that it feels they last about the same time.

Regarding the release time bug. Yes, you are right the release time in sfz is the same everywhere, not just after the sustain point as I wrongly thought. However, in both sforzando and linuxsampler, if the sustain point if the last one of the envelope, then the release time is simply ignored and abruptly ends. The workaround is to add an extraneous envelope point after the last one. I have no idea if that is a feature or a bug, but that is what I have observed.

It's a bit late now so I'm gonna leave this comment as it is, but later I can compile you some presets that demonstrate what I mean if you'd like to, let me know.

I am hesistant to do any modifications to the ampeg_release value. In particular the difference in behaviour that you describe mostly applies to the IT / MPTM format, but e.g. in the XM format the fadeout is also applied instantly on release, not just after hitting the end of the envelope like in IT. In fact, IT does the same if the instrument contains a regular loop instead of a sustain loop. The rules when to apply the fadeout value are quite a complicated mess, so I'd rather keep the ampeg_release value as-is and let the user change it if required. There's simply no way to have the SFZ instrument behave exactly like its IT/XM counterpart in all possible cases.

The workaround is to add an extraneous envelope point after the last one. I have no idea if that is a feature or a bug, but that is what I have observed.

This exact workaround was introduced in r12540 as I was making the same observation, can you check the latest builds?

This exact workaround was introduced in r12540 as I was making the same observation, can you check the latest builds?

Excellent! Indeed it works, though I'm having some glitches (sudden change of volume) on off notes. A solution, it seems, is to the time of the extraneous point to the time of the last (i.e. previous) one, instead of 0, then the glitches disappear. Please let me know if you want me to provide a preset example for it. Also I noticed that eg0_points is set to 1, which is incorrect according to my understanding. Neither sforzando nor linuxsampler seem to care, however maybe it would be safer to set it to the correct value, or else dismiss it.

Other than that, it sounds great and I agree with your comments about the trickiness of setting the correct amp_release value and the fact that it's easily user corrected.

Also I noticed that eg0_points is set to 1, which is incorrect according to my understanding.

Ah, missing parentheses... this was supposed to add 1 to the number of envelope points... Will be fixed in the next update. And indeed, I figure out that this opcode is completely useless the way SFZ players seem to be implemented, which is sad.

Please let me know if you want me to provide a preset example for it.

Yes, that would be useful, because based on my observations it behaved as intended.

Please find an sfz in attach. To reproduce the glitch release the key when it is at its lowest volume, before or while the volume is climbing up again.

As the major request (embedding envelopes) has been implemented, I will close this issue for now. The buggy envelope behaviour on key-up might be a glitch that's not easy to work around, and unless you have a good suggestion how the export should work around this that can be applied in general, I think we have to live with the current export quality for now.