Bug: env attack maximum level is higher than the maximum sustain level

[el-folie]

By this level difference a stepping can be perceived when the attack level reaches the max sustain level.

Complete description with audio examples in the gearslutz thread.

[image-et-son]

This is a tricky "bug". It must have been around forever. In essence, in the multiplexer readout there are two types of cutoff: a parameter specific accuracy (which in the case of sustain is the leading 8 of 16 bits) and a detection threshold, which eliminates slow down due to small unwanted changes. But the downside is that you can never reach values above (full value -threshold) or below (zero + threshold). And this is precisely what happens here. I am currently unsure what to do about it :-\ but I keep on thinking about it, of course.

I only came across this when I did the pick-me-up logic because I was never able to "pick up" default values which were set to full (unreachable by potentiometer).

[el-folie]

You´re right, just I verified the "sustain level step" even on gligli 2.0 stable release. I´ll ckeck how the Sequential OS behaves...

No step on Sequential OS. But of course hard to say how they managed to do it...

[image-et-son]

I can program an exception for pot values near the maximum. I'll do that in the next alpha.

[el-folie]

Tested and seems to work reliable. Is there any reason to call the fix preliminary?

[image-et-son]

Well, yeah, I am not really happy with the solution at all. What I have done is interpreting any value above (MAX - threshold) as MAX. This violates the accuracy which would be possible and this is why I dislike it. Maybe I just restrict this to the filter sustain because this is the only parameter for which you will ever be able to hear the threshold difference.

[el-folie]

Ah, I see... Yeah, then maybe just keeping it for now would be sufficient.

In my opinion, even if it, like you say, may not be the best solution engineering-wise, it is stil the best solution sound-wise, at least for now. And as it´s all about sound and not about perfection I think your solution is spot on!

[el-folie]

I think I understand the problem now...

I think your exception method is absolutely logical and totally precise, because MAX >IS< MAX and must always be MAX for each and every paramater, as MAX must never be less than MAX or the patch sound or influence of a paramater would be wrong if MAX is not MAX at MAX. Therefore an additional threshold at the very top and maybe also at the bottom of parameter knobs would lead to wrong values if being added or subtracted.

Thus I think you got it perfectly right with your first approach.