This is a great plugin, however there has been an intermittent loss of the fractional part of the mute level leaving just whole integers for adjustment.
The problem doesn’t happen to Threshold and i haven’t tried fractional decimals with Look Ahead or Release Time.
I’ve just reinstalled Audacity and the problem persists for now. It has happened once or twice before in the few weeks i have been using it. Some of that time would have been with Ubuntu 12.10 i would think. It is still worth using without fractional adjustment of the mute level, just a bit lumpier.
I think that you may be seeing a bug that has recently been noticed affecting the slider controls in Nyquist plug-ins.
Could you give step-by-step details of exactly how to reproduce the issue?
Are you using a British keyboard and an English installation of Ubuntu?
I’m glad you asked that, after further testing it now seems only a display issue not affecting the computation.
Yes, British keyboard and English (64bitx86) installation.
To reproduce :
Select a track(s) from within Audacity and open the popmute plugin for the selection.
Key in values to the Threshold and Mute Level perameter boxes (i don’t normally use sliders here).
Use sliders for Look Ahead and Release Time (i set to 1 and 1.0).
As either of these sliders are moved with the mouse the fractional part of Mute Level goes blank leaving just the integer.
If Look Ahead and Release Time are not touched or set by keying in values to the perameter boxes rather than the sliders then the fractional decimal of mute level remains (until the OK button is pressed). By subsequent use of the plugin, which for the same track remembers the previous perameter setting when reopened, it can be seen that the fractional decimal has similarly been removed.
Having investigated further (and possibly because of doing so ?) the problem has gone ( ) and the fractional decimal now displays correctly but while the problem remained i am fairly certain that the fractional component was nevertheless applied to the computation even though it was not displayed. That was determined by looking at how much the track could be amplified afterwards without clipping.
Thanks for the additional detail Jorronno.
As far as I can tell you’re right - when the locale is set to English then the affect parameter is applied correctly - the problem only affects the display. We seem to have a more serious issue when the locale is set to a country that uses a comma as the decimal separator - in this case the problem may (but not always) affect the applied value. The problem (both cases) is in the slider code rather than in the plug-in code. We are looking into this but don’t yet have a solution - at the moment we are trying to pin down exactly what is happening, so your feedback has come at a very good time
The bug has returned… for more observation.
Only the fractional decimal .5 (or .50 or .500 …) seems to be affected.
So i can use say a Mute Level of 1.499 or 1.501 or 1.5000000001 without a problem.
Studying the effect of increasing numbers of zeros, 1.500001 will result in a subsequently re-opened popmute Mute Level showing 1.500001 but 1.5000001 will result in a subsequently re-opened popmute Mute Level of 1.5, which doesn’t loose the decimal fraction after further use, so perhaps the computation for further use would still be on 1.5000001 although the display says 1.5 ?
Anyways, there is a work-around, something which searching for becomes a way of life for Linux users.
) and the fractional decimal now displays correctly but while the problem remained i am fairly certain that the fractional component was nevertheless applied to the computation even though it was not displayed. That was determined by looking at how much the track could be amplified afterwards without clipping.
