linuxsampler-devel

[Linuxsampler-devel] EGs

[Christian S. <sch...@li...>]

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

Re: [Linuxsampler-devel] EGs

[Aaron L. <dar...@gm...>]

On Tue, Jul 18, 2017 at 7:46 AM, Christian Schoenebeck <
sch...@li...> wrote:

> 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

Re: [Linuxsampler-devel] EGs

[Andreas P. <and...@ou...>]

Aaron Laws wrote:
> On Tue, Jul 18, 2017 at 7:46 AM, Christian Schoenebeck
> <sch...@li... <mailto:sch...@li...>> wrote:
> 
>     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.

>     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

Re: [Linuxsampler-devel] EGs

[Christian S. <sch...@li...>]

On Tuesday, July 18, 2017 15:02:23 Andreas Persson wrote:
> >     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?

> 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.

> >     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

Re: [Linuxsampler-devel] EGs

[Andreas P. <and...@ou...>]

Christian Schoenebeck wrote:
> 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."

>>>     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

Re: [Linuxsampler-devel] EGs

[Nicola P. <nic...@gm...>]

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.

Il 18 luglio 2017 13:46:41 CEST, Christian Schoenebeck <sch...@li...> ha scritto:
>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
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

-- 
Nicola

Re: [Linuxsampler-devel] EGs

[Christian S. <sch...@li...>]

On Wednesday, July 19, 2017 07:25:50 Andreas Persson wrote:
> Christian Schoenebeck wrote:
> > 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.

> > 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/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

Re: [Linuxsampler-devel] EGs

[Christian S. <sch...@li...>]

On Wednesday, July 19, 2017 10:27:47 you wrote:
> 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

Re: [Linuxsampler-devel] EGs

[Andreas P. <and...@ou...>]

Den 2017-07-19 kl. 13:24, skrev Christian Schoenebeck:
> On Wednesday, July 19, 2017 10:27:47 you wrote:
>> 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

Re: [Linuxsampler-devel] EGs

[Christian S. <sch...@li...>]

On Wednesday, July 19, 2017 17:25:50 Andreas Persson wrote:
> 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.

> 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

Re: [Linuxsampler-devel] EGs

[Christian S. <sch...@li...>]

On Wednesday, July 19, 2017 13:13:26 Christian Schoenebeck wrote:
> 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

Re: [Linuxsampler-devel] EGs

[S. C. C. <s_c...@ho...>]

I realize I'm a bit late on this particular topic, but I think a good, 
universal solution to this problem would be to set a minimum duration 
for all notes. For example, if the minimum duration is set to 20 
milliseconds, then a note duration of between 0 and 20 ms would always 
play as 20 ms. This would prevent the scenario where notes with short 
but nonzero attack values go to release stage before the note has 
reached the desired volume, and sounds that have attack phases longer 
than 20 ms (pads, cymbal rolls, sound effects that fade in) would still 
properly respond to keypress duration. This would at least be in line 
with how I'd expect a synth/sampler to behave. For other behaviors, we 
have "one shot" mode.

-~Chris


On 07/23/2017 02:37 PM, Christian Schoenebeck wrote:
> On Wednesday, July 19, 2017 13:13:26 Christian Schoenebeck wrote:
>> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] EGs

[Christian S. <sch...@li...>]

You are talking about SFZ? Because for the gig format I think I already 
addressed this overall issue appropriately like I already described in this 
thread.

CU
Christian

On Mittwoch, 8. November 2017 00:17:50 CET S. Christian Collins wrote:
> I realize I'm a bit late on this particular topic, but I think a good,
> universal solution to this problem would be to set a minimum duration
> for all notes. For example, if the minimum duration is set to 20
> milliseconds, then a note duration of between 0 and 20 ms would always
> play as 20 ms. This would prevent the scenario where notes with short
> but nonzero attack values go to release stage before the note has
> reached the desired volume, and sounds that have attack phases longer
> than 20 ms (pads, cymbal rolls, sound effects that fade in) would still
> properly respond to keypress duration. This would at least be in line
> with how I'd expect a synth/sampler to behave. For other behaviors, we
> have "one shot" mode.