After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 337707 - ADSR shows instabilities
ADSR shows instabilities
Status: RESOLVED OBSOLETE
Product: beast
Classification: Other
Component: bse
SVN trunk
Other Linux
: High major
: ---
Assigned To: Beast Maintainers
Beast Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-08 12:10 UTC by Tim Janik
Modified: 2021-05-25 12:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case showing stale ADSR modules (4.06 KB, application/octet-stream)
2006-04-08 12:13 UTC, Tim Janik
Details

Description Tim Janik 2006-04-08 12:10:19 UTC
in some setups the ADSR module seems to enter instable states where the Done output is not (never?) set to 1 in time.
in particular for small sustain values and long release times.
Comment 1 Tim Janik 2006-04-08 12:13:20 UTC
Created attachment 62975 [details]
test case showing stale ADSR modules
Comment 2 Tim Janik 2006-12-15 20:31:03 UTC
a debugging session with adsr value print outs revealed that for small sustain values, the slope calculated bse_simple_adsr_update_modules():
  vars.release_dec = vars.sustain_level / (ms * adsr->release_time);
can be subject to float value cancellation and precision loss, when summed up and checked against a threshold in simple_adsr_process().
this may lead to excessively long hold/release times in envelopes.
Comment 3 Stefan Westerfeld 2007-09-28 19:46:32 UTC
I don't think in this particular case float cancellation has anything to do with the problem. If you let the song run longer, you'll see that eventually voices become available again. To me, it looks like the following is happening:

-
In the testcase, the ADSR sustain is very long, so that the release value decrement (vars.release_dec) is very very small, too.

Now if we release before the sustain is reached, the current value of the ADSR will not be small. It could even be 1, if gate becomes low exactly after the attack phase is over.

The very very small release decrement will lead to a release time that is much much longer as in the normal case (where sustain would have been reached before release starts).
-

To suggest a proper strategy to fix this (i.e. what would be a behaviour that is reasonable to musicians), I have asked Krzysztof Foltman to do some samples of his Yamaha CS1X, for two cases:

(a) slooooow release (decay < release)
(b) quick release (decay > release)

What we observed is this:
(a) if the release phase is triggered (gate low) before the sustain level is reached, then the release becomes steeper the earlier it happens - this means that the note will never become longer than if the sustain level would have been reached

or to put it in another way: A + D + R give the definite minimum duration of the note in case (a), and if release happens before A + D is finished, it will be steeper than usual

(b) in this case the release can cut off the note prior to its normal (A + D + R) end - that is, if the gate goes low before the decay phase is over, the release slope will be steeper than the decay slope, and the note will end earlier

I think this is what the current ADSR code does anyway, so I won't go into too much detail here.

-

I think its highly desirable to modify the ADSR so that it also behaves like described in (a). It will make the behaviour much more predictable.

Also, from a musicians point of view I'd like to add that all instruments I know behave in the following way: if I play a long note, the sound is long. If I make the note shorter and shorter, the sound also gets shorter and shorter. In some cases (for instance drums), there is a point where making the notes even shorter doesn't make the sound even shorter. But I've never seen an instrument where making the note shorter makes the sound longer, which happens with the current ADSR code.
Comment 4 André Klapper 2021-05-25 12:34:23 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new enhancement request ticket at
  https://gitlab.gnome.org/GNOME/beast/-/issues/

Thank you for your understanding and your help.