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 ------------------------------------------------------------------------------ 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 Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
