Plugin release frames depend on sample rate

[zonkmachine]

Bug Summary

First brought up here: #6908 (comment)

When a plugin doesn't use the envelope it still has a fixed number of release frames. Example from Bitinvader:

lmms/plugins/BitInvader/BitInvader.h

Lines 88 to 91 in df11a98

	f_cnt_t desiredReleaseFrames() const override
	{
	return( 64 );
	}

The problem with a fixed number of frames for release is that the decay time now will vary with the sample rate as shown in the release below in a project exported with three different sample rates.

Expected Behaviour

The release time should be the same and independent of sample rate.

From @michaelgregorius in the same thread.

It looks like the release should be defined in milliseconds which is then converted into a number of samples based on the sample rate.

[Rossmaxx]

Would it make sense to return 64 * (sampleRate ÷ 44100) ?

[michaelgregorius]

I think it makes more sense to solve the problem by changing the method to something like desiredReleaseTimeMs. The underlying problem is that the release time is requested in a unit that's independent of the sample rate, so this problem should be fixed.

If you search for desiredReleaseFrames you will find that there are already several overrides. If the method desiredReleaseFrames was only adjusted and kept then the problem might creep in later again even it all overrides are adjusted as well. Or put differently: the problem should be fixed in one place where the release time in milliseconds is converted into sample frames. Keeping desiredReleaseFrames would mean that the problem had to be fixed in several places with the danger of the aforementioned return of the problem, e.g. in new classes.

For the overrides it should also be checked if the number of frames that are used really make sense or if they haven't just been chosen arbitrarily by the implementers. Another potential explanation for the differences in the implementations might be that the implementation in the base class was changed without taking all the overriding implementations into account.

[michaelgregorius]

@zonkmachine, can you please check with the changes of pull request #7217?