[Linuxsampler-devel] EGs

[Christian Schoenebeck]

Hi everybody,

after reviewing the code of the envelope generators, I noticed that I
implemented the state machine of the EGs incorrectly years ago. The common
behavior of EGs is that the attack, decay and decay hold phases are always
played entirely according to their defined duration in the instrument patch.
With our current EGs however the attack and decay phases are aborted as soon
as a note-off arrives, so the EG immediately switches into the release phase
too early on short notes. That's especially problematic for percussive
instruments.

So if there are no vetoes, I am going to change that, so that even if a note-
off arrives very early, the attack, decay and decay hold phases are always
played entirely to their stage end, and after the attack and decay phases
completed their defined durations, the EG would then switch into release phase
afterwards.

That will obviously change the behavior and thus the sound of existing sounds.
But I think that change really makes sense, and probably this behavior change
does not even have a negative impact on existing sounds.

Another change I planned regarding the EGs: we currently have a behavior which
is probably a bit exotic compared to common EG implementations; if a voice is
in release phase and a new note-on arrives on that respective MIDI note, our
EGs abort the release phase and switch back to the previous phase (i.e. back
to sustain phase). Now that behavior is sometimes useful, sometimes negative,
depends on the sound. So maybe I make that configurable, I am not very sure
about this particular change yet.

If you have an opinion on these two EG issues, let me know!

CU
Christian

[Aaron Laws]

On Tue, Jul 18, 2017 at 7:46 AM, Christian Schoenebeck <

Post by Christian Schoenebeck
Hi everybody,
after reviewing the code of the envelope generators, I noticed that I
implemented the state machine of the EGs incorrectly years ago. The common
behavior of EGs is that the attack, decay and decay hold phases are always
played entirely according to their defined duration in the instrument patch.
With our current EGs however the attack and decay phases are aborted as soon
as a note-off arrives, so the EG immediately switches into the release phase
too early on short notes. That's especially problematic for percussive
instruments.
So if there are no vetoes, I am going to change that, so that even if a note-
off arrives very early, the attack, decay and decay hold phases are always
played entirely to their stage end, and after the attack and decay phases
completed their defined durations, the EG would then switch into release phase
afterwards.
That will obviously change the behavior and thus the sound of existing sounds.
But I think that change really makes sense, and probably this behavior change
does not even have a negative impact on existing sounds.
Another change I planned regarding the EGs: we currently have a behavior which
is probably a bit exotic compared to common EG implementations; if a voice is
in release phase and a new note-on arrives on that respective MIDI note, our
EGs abort the release phase and switch back to the previous phase (i.e. back
to sustain phase). Now that behavior is sometimes useful, sometimes negative,
depends on the sound. So maybe I make that configurable, I am not very sure
about this particular change yet.
If you have an opinion on these two EG issues, let me know!
CU
Christian

Yes, that certainly seems like a bug; good catch.

Likewise, I think allowing the release to continue after a new note-on
should be configurable. In "absurd" cases, it may contribute to excessive
polyphony, but in the normal case, I think the releases would be
appreciated.

In Christ,
Aaron Laws

[Andreas Persson]

Post by Aaron Laws
On Tue, Jul 18, 2017 at 7:46 AM, Christian Schoenebeck
Hi everybody,
after reviewing the code of the envelope generators, I noticed that I
implemented the state machine of the EGs incorrectly years ago. The common
behavior of EGs is that the attack, decay and decay hold phases are always
played entirely according to their defined duration in the
instrument patch.
With our current EGs however the attack and decay phases are aborted as soon
as a note-off arrives, so the EG immediately switches into the release phase
too early on short notes. That's especially problematic for percussive
instruments.
So if there are no vetoes, I am going to change that, so that even if a note-
off arrives very early, the attack, decay and decay hold phases are always
played entirely to their stage end, and after the attack and decay phases
completed their defined durations, the EG would then switch into release phase
afterwards.
That will obviously change the behavior and thus the sound of existing sounds.
But I think that change really makes sense, and probably this behavior change
does not even have a negative impact on existing sounds.

Long time ago I put a lot of time and effort to get the behavior as it
is now I think. My goal back then was to make the EGs behave as closely
as possible to how the EGs of GigaStudio behaved.

I think I have piano sounds that would behave strangely after a change
like this: they have a very long decay (for some unknown reason) which
is supposed to get interrupted by a note off.

Post by Aaron Laws
Another change I planned regarding the EGs: we currently have a behavior which
is probably a bit exotic compared to common EG implementations; if a voice is
in release phase and a new note-on arrives on that respective MIDI note, our
EGs abort the release phase and switch back to the previous phase (i.e. back
to sustain phase). Now that behavior is sometimes useful, sometimes negative,
depends on the sound. So maybe I make that configurable, I am not very sure
about this particular change yet.

I don't remember that one - it could be a simulated GigaStudio
weirdness, but I don't know when it would be useful.

/Andreas

[Christian Schoenebeck]

Post by Andreas Persson

Post by Christian Schoenebeck
after reviewing the code of the envelope generators, I noticed that I
implemented the state machine of the EGs incorrectly years ago. The common
behavior of EGs is that the attack, decay and decay hold phases are always
played entirely according to their defined duration in the instrument patch.

Long time ago I put a lot of time and effort to get the behavior as it
is now I think. My goal back then was to make the EGs behave as closely
as possible to how the EGs of GigaStudio behaved.

Yes, I know that of course. I reviewed the current code and also the SVN
history. Because I remember that you worked hard on that.

Correct me if I am wrong, but as far as I can see it right now, you worked on
the actual EG curve shapes to replicate the original shapes as accurate as
possible, for example that the stages are actually a combination of linear and
logarithmic curves in GSt, and the way the durations were calculated by GSt.

However I think that particular issue, that the attack and decay phases are
not played entirely to their end, like it is usually the case with EGs in
general, is still from the very first EG version that I wrote long time before
that. So I think I caused that "bug", and you probably did not compare this
precise behavior aspect with GSt. Am I wrong?

Post by Andreas Persson
I think I have piano sounds that would behave strangely after a change
like this: they have a very long decay (for some unknown reason) which
is supposed to get interrupted by a note off.

Nothing changed yet. That's why I am bringing up this issue here.

On doubt, it will become a configurable behavior change. But it must be
addressed in some way. Because otherwise it is impossible to resemble
percussive instruments in a realistic way.

Post by Andreas Persson

Post by Christian Schoenebeck
Another change I planned regarding the EGs: we currently have a behavior which
is probably a bit exotic compared to common EG implementations; if a voice is
in release phase and a new note-on arrives on that respective MIDI note, our
EGs abort the release phase and switch back to the previous phase (i.e. back
to sustain phase). Now that behavior is sometimes useful, sometimes negative,
depends on the sound. So maybe I make that configurable, I am not very sure
about this particular change yet.

I don't remember that one - it could be a simulated GigaStudio
weirdness, but I don't know when it would be useful.

No, that behavior was also from the very first EG version I wrote. I think
back then I had a piano string in mind, which would stop being dampened as
soon as you press the piano key down again. And at that point I already knew
this behavior aspect would deviate from common EG implementations, but I did
not care.

CU
Christian

[Andreas Persson]

Post by Christian Schoenebeck
Correct me if I am wrong, but as far as I can see it right now, you worked on
the actual EG curve shapes to replicate the original shapes as accurate as
possible, for example that the stages are actually a combination of linear and
logarithmic curves in GSt, and the way the durations were calculated by GSt.
However I think that particular issue, that the attack and decay phases are
not played entirely to their end, like it is usually the case with EGs in
general, is still from the very first EG version that I wrote long time before
that. So I think I caused that "bug", and you probably did not compare this
precise behavior aspect with GSt. Am I wrong?

Yes, I think so. I remember doing measurements on how GSt reacted on
note off in the different stages of EG. I don't remember how much I
actually had to change the implementation, but at least in the comment
of my commit r783 I wrote "Release stage can now start before attack
stage ends."

Post by Christian Schoenebeck

Post by Andreas Persson

Post by Christian Schoenebeck
Another change I planned regarding the EGs: we currently have a behavior which
is probably a bit exotic compared to common EG implementations; if a voice is
in release phase and a new note-on arrives on that respective MIDI note, our
EGs abort the release phase and switch back to the previous phase (i.e. back
to sustain phase). Now that behavior is sometimes useful, sometimes negative,
depends on the sound. So maybe I make that configurable, I am not very sure
about this particular change yet.

I don't remember that one - it could be a simulated GigaStudio
weirdness, but I don't know when it would be useful.

No, that behavior was also from the very first EG version I wrote. I think
back then I had a piano string in mind, which would stop being dampened as
soon as you press the piano key down again. And at that point I already knew
this behavior aspect would deviate from common EG implementations, but I did
not care.

Yes, you're right. This sounded familiar, so I had to search the mailing
list archives: It seems I noticed this behavior and asked if it was a
bug in 2004:
https://sourceforge.net/p/linuxsampler/mailman/linuxsampler-devel/thread/14df1c3e04120514066f89786d%40mail.gmail.com

:)

/Andreas

[Christian Schoenebeck]

Post by Andreas Persson

Post by Christian Schoenebeck
Correct me if I am wrong, but as far as I can see it right now, you worked
on the actual EG curve shapes to replicate the original shapes as
accurate as possible, for example that the stages are actually a
combination of linear and logarithmic curves in GSt, and the way the
durations were calculated by GSt.
However I think that particular issue, that the attack and decay phases are
not played entirely to their end, like it is usually the case with EGs in
general, is still from the very first EG version that I wrote long time
before that. So I think I caused that "bug", and you probably did not
compare this precise behavior aspect with GSt. Am I wrong?

Yes, I think so. I remember doing measurements on how GSt reacted on
note off in the different stages of EG. I don't remember how much I
actually had to change the implementation, but at least in the comment
of my commit r783 I wrote "Release stage can now start before attack
stage ends."

I see, you are right, that behavior regarding attack and decay came from your
side. Then I am going to make that configurable as another LS extension to the
gig format and leave the current behavior as default behavior.

In the end I will add 3 additional check boxes to gigedit which allow to
select for 1.) "attack" stage, 2.) "attack hold" stage and 3.) "decay" stage
whether the respective stage should be played entirely to its end on note-off.
That checkbox trio will be available for all 3 EGs separately (amp EG, pitch
EG, filter EG) as individual configuration.

I guess that should be fine for everybody.

Post by Andreas Persson

Post by Christian Schoenebeck
No, that behavior was also from the very first EG version I wrote. I think
back then I had a piano string in mind, which would stop being dampened as
soon as you press the piano key down again. And at that point I already
knew this behavior aspect would deviate from common EG implementations,
but I did not care.

Yes, you're right. This sounded familiar, so I had to search the mailing
list archives: It seems I noticed this behavior and asked if it was a
https://sourceforge.net/p/linuxsampler/mailman/linuxsampler-devel/thread/14d
f1c3e04120514066f89786d%40mail.gmail.com

Ok, then this one doesn't matter anymore. Since I have to add a file format
extension for the attack/attack hold/decay behavior configuration, I will also
add that one as configurable behavior extension to the gig format as well and
leave the current behavior as default one as well.

CU
Christian

[Christian Schoenebeck]

Post by Christian Schoenebeck
I see, you are right, that behavior regarding attack and decay came from
your side. Then I am going to make that configurable as another LS
extension to the gig format and leave the current behavior as default
behavior.
In the end I will add 3 additional check boxes to gigedit which allow to
select for 1.) "attack" stage, 2.) "attack hold" stage and 3.) "decay" stage
whether the respective stage should be played entirely to its end on
note-off. That checkbox trio will be available for all 3 EGs separately
(amp EG, pitch EG, filter EG) as individual configuration.

Ok, I just committed changes for those EG behavior changes to libgig,
linuxsampler and gigedit.

In gigedit there are now 5 additional checkboxes for EG1, as well as for EG2,
which allow to configure (on dimregion level) individually whether Attack,
Attack Hold, Decay 1, Decay 2 and Release may be cancelled.

The previous EG state machine behavior is preserved as default value for those
settings on libgig level. Which means those 5 checkboxes are all enabled by
default.

Since EG3 just has one stage (decay) it does not have any options.

On libgig level a linuxsampler specific RIFF chunk is added as extension to
the gig file format for those new EG options. However that chunk will only be
added to the gig file if the user changed the settings differing from the
default values.

I hope I did not break anything. If I did, let me know!

CU
Christian

[Nicola Pandini]

Hi,
I noticed that years ago, but never been able to investigate it, thanks for fixed it. (I used loopmode=one_shot to partially resolve this)
While you are watching the EG behaviour, could you please check the ahdsr ramps? Weeks ago I started to write documentation for these opcodes, and I noticed two things I don't know are corrects:
1. Ampeg_decay value should be the time (in seconds) the AMPEG envelope takes to go from "hold" to "sustain", but actually is shorter.
2. Ampeg_release ramp is not linear, while attack and decay are linear.

Post by Christian Schoenebeck
Hi everybody,
after reviewing the code of the envelope generators, I noticed that I
implemented the state machine of the EGs incorrectly years ago. The common
behavior of EGs is that the attack, decay and decay hold phases are always
played entirely according to their defined duration in the instrument patch.
With our current EGs however the attack and decay phases are aborted as soon
as a note-off arrives, so the EG immediately switches into the release phase
too early on short notes. That's especially problematic for percussive
instruments.
So if there are no vetoes, I am going to change that, so that even if a note-
off arrives very early, the attack, decay and decay hold phases are always
played entirely to their stage end, and after the attack and decay phases
completed their defined durations, the EG would then switch into release phase
afterwards.
That will obviously change the behavior and thus the sound of existing sounds.
But I think that change really makes sense, and probably this behavior change
does not even have a negative impact on existing sounds.
Another change I planned regarding the EGs: we currently have a
behavior which
is probably a bit exotic compared to common EG implementations; if a voice is
in release phase and a new note-on arrives on that respective MIDI note, our
EGs abort the release phase and switch back to the previous phase (i.e. back
to sustain phase). Now that behavior is sometimes useful, sometimes negative,
depends on the sound. So maybe I make that configurable, I am not very sure
about this particular change yet.
If you have an opinion on these two EG issues, let me know!
CU
Christian
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxsampler-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Christian Schoenebeck]

Post by Nicola Pandini
Hi,
I noticed that years ago, but never been able to investigate it, thanks for
fixed it. (I used loopmode=one_shot to partially resolve this) While you
are watching the EG behaviour, could you please check the ahdsr ramps?
Weeks ago I started to write documentation for these opcodes, and I noticed
two things I don't know are corrects: 1. Ampeg_decay value should be the
time (in seconds) the AMPEG envelope takes to go from "hold" to "sustain",
but actually is shorter. 2. Ampeg_release ramp is not linear, while attack
and decay are linear.

No idea about those two. Maybe Andreas can comment on this?
It could be a left over from the gig engine's EGs. Because the sfz engine was
originally "branched" from the gig engine and then elements were replaced one
by one for the required, expected sfz behaviors.

Since I am going to address the other EG issues mentioned by me as
configurable options on gig file format level, I take from your response that
we must also address this for the sfz engine, right? If yes, are there precise
suggestions for sfz opcodes?

CU
Christian

[Andreas Persson]

Post by Christian Schoenebeck

Post by Nicola Pandini
Hi,
I noticed that years ago, but never been able to investigate it, thanks for
fixed it. (I used loopmode=one_shot to partially resolve this) While you
are watching the EG behaviour, could you please check the ahdsr ramps?
Weeks ago I started to write documentation for these opcodes, and I noticed
two things I don't know are corrects: 1. Ampeg_decay value should be the
time (in seconds) the AMPEG envelope takes to go from "hold" to "sustain",
but actually is shorter. 2. Ampeg_release ramp is not linear, while attack
and decay are linear.

No idea about those two. Maybe Andreas can comment on this?
It could be a left over from the gig engine's EGs. Because the sfz engine was
originally "branched" from the gig engine and then elements were replaced one
by one for the required, expected sfz behaviors.

I fine tuned the sfz EG and modeled it after SFZ Player and Rapture
2010-01-30. So, that the attack is linear and the decay and release are
exponential are deliberate (didn't even the original sfz spec say that
it should be like that? I don't remember). For exponentials the
interpretation of time values is hard as it depends on how close to the
target level you count as finished, but I tried to make the calculation
as close as possible to the SFZ Player/Rapture behavior.

/Andreas

[Christian Schoenebeck]

Post by Andreas Persson
I fine tuned the sfz EG and modeled it after SFZ Player and Rapture
2010-01-30. So, that the attack is linear and the decay and release are
exponential are deliberate (didn't even the original sfz spec say that
it should be like that? I don't remember).

Most EG implementations use linear for rising stages (i.e. attack) and
logarithmic curves for falling stages (i.e. decay, release). That has
historical reasons, since the first EGs based on analogue circuits with their
simple RC components behaved like that.

Post by Andreas Persson
For exponentials the
interpretation of time values is hard as it depends on how close to the
target level you count as finished, but I tried to make the calculation
as close as possible to the SFZ Player/Rapture behavior.

Yes, that's in general the problem with logarithmic stages. To make this more
clear: Since i.e. a logarithmic release stage will fall down towards zero with
constantly reduced speed, it never reaches zero level. So which EG level do
you then consider as end of the release stage? -12 dB? -24 dB? -120 dB? In the
end we must pick one level to be the "end" level. And accordingly depending on
which end level we pick, the duration is different to EG implementations of
other players which have picked another EG level as "end" level.

Since sfz is highly configurable and extensible, maybe somebody already
suggested an opcode for setting a specific "end" level.

CU
Christian