I see why you have done this and I think that this change is “correct”, but the desirability of this change depends on the way that the effect is used, so for anyone that is familiar with the current version it may not be a welcome change.
If the user has a mono track and they wish to pan it randomly, with the original version they would probably just add an empty track (Ctrl+shift+N) and join the two tracks to make a stereo track. If they do this with the updated code, the result will have only half the amplitude that the original version would have.
I think that this fix probably is a good idea for a new “panning” effect, but because it is a noticeably different behaviour I have not applied this to David’s plug-in.
Thanks - that’s fixed the problem and has now been applied.
I like user input checking. You can bet that if it is possible to enter invalid input, then someone will
It may be a matter of personal preference as to how the user input is validated.
When is it better to assume that the user means a positive value when they enter a negative value (or vice versa). This approach could be useful for dB values where the user may just forget to enter a minus.
Sometimes it may be better to return an error message. This approach is probably best when the user input is complex, as may be the case when a text input widget is used for entering parameter values.
For this plug-in it would be better if it was impossible to enter negative values. Perhaps there is a case for an enhancement to the slider widget:
;control variable-name "text-left" variable-type "text-right" initial-value minimum maximum (&optional limit)
The additional “limit” parameter could be an optional value:
- 0 or not present = not limited (as now)
- 1 = input value cannot be less that minimum slider value
- 2 = input value cannot be greater than maximum slider value
- 3 = input value cannot be outside of slider range
- (val1 val2) = minimum and maximum values through text input
If the minimum slider range is limited to a positive value, then Audacity would prevent typing a minus sign.
Audacity should probably also prevent typing a decimal point if the slider is set to integer.
I’m not certain that this suggestion is possible, but I think that it probably is.
What should happen if the user enters a “speed” of zero? This should probably be valid, but would need to be treated as a special case (using a conditional). A speed of zero would mean that the plug-in would randomly generate a constant value. This could be useful if the user was applying the effect to multiple tracks and wanted to spread the tracks (randomly) across the stereo field but without the individual tracks moving.
Again, probably not a bad idea, but a divergence from the original version so I’ve not applied to David’s plug-in. If I was choosing then I’d probably set the default to 1.0.
The code could be simplified and memory usage reduced further still. I’ll start a new post as this one is already long.