Panning plug-ins

[steve]

Topic split from: http://forum.audacityteam.org/viewtopic ... 07#p199907

An interesting way to create a low frequency random signal:

Code: Select all

(lp (force-srate *sound-srate* (force-srate 4 (noise))) 2)

[Robert J. H.]

I had a similar idea:

Code: Select all

(setf control-noise (sum 0.5 (mult 0.5 
  (snd-white 0 10 (get-duration 1)))))
(vector (mult (aref s 0)  control-noise)
        (mult (aref s 1)  (diff 1 control-noise)))

The thing I want to avoid the most, is that I do not have to normalize the noise after cration , but this seems to be always necessary with the usage of filters, although reson has an built-in normalize option.

[steve]

The thing I want to avoid the most, is that I do not have to normalize the noise after cration

Absolutely.

The only slight problem with your snippet (though it may be acceptable for this plug-in) is that the interpolation between the random values is linear, so the transition from one pan position to the next is also linear. This tends to cause extreme left/right positions to exist only momentarily except for the unlikely event that two sequential random values both have values close to +1 or -1. Applying a low pass filter will make the pan smoother and allow extreme pan positions to linger a little longer.

This snippet produces peaks very close to +/- 1.0

Code: Select all

(setq freq 4.0)
(mult 2.0 (lp (force-srate *sound-srate* (force-srate freq (clip (noise) 0.5))) (/ freq 2.0)))

To ensure that it does not exceed +/- 1 the waveform could be clipped (again) after it has been scaled.

Code: Select all

(let ((freq 4.0)
      (sr *sound-srate*)
      (clip-noise (clip (noise) 0.5)))
  (clip
    (mult 2.0 
      (lp (force-srate sr (force-srate freq clip-noise))
          (/ freq 2.0)))
    1.0))

Only a very few if any peaks are clipped to 1.0 because the noise is unlikely to be much (if at all) greater than 1.

[steve]

By the way, I suspect (though I've not actually checked) that the original problem with Panrand.ny was not only excessive memory usage but also a stack overflow if the main function went through too many recursions. For a large number of loops it is generally better to use iteration so as to avoid the possibility of stack overflow.

[Robert J. H.]

It is probably better to use the "scale-srate" function instead of the inner force-srate. (something like '(scale-srate (noise) 0.0001)').
If high precision for the position of the sound is not an absolute necessaty, it may also be bettter to use resample.
With squaring and drawing the square root, the course of the signal could be weighted differently.
There's also the possibility to use "FMLFO" to produce a varying frequency. There's a lot that can be done.

[steve]

There's also the possibility to use "FMLFO" to produce a varying frequency. There's a lot that can be done.

If you don't need it to be truly "random" then you could create a fairly short random control signal and repeat it. If the control signal is more than a few seconds duration then unless there are any particularly distinctive moments it will still sound random even when repeated.
As you say, there are a lot of options and I'm happy to leave the choice to you

[Robert J. H.]

Why not a X-mas special with 24 surprises...

[Robert J. H.]

Here is the corrected plug-in "panning (random)"by David R. Sky.

What I've changed so far:

• correct mono-conversion (-6 dB)
• removed duration after "noise". This was the main reason for the crashes, because the noise was 'duration (sound)^2' long, e.g. 2 min of sound produced 240 min of noise.
• Some input correction
• New default values
• Stereo width offset in order to preserve the full gain for narrow signals
• Simpler code layout, some minor bugs removed.

The code is not especially speed/resource improved. I've tested it with 30 min of a sweep sound without a crash - it still depends on how much memory you have.
The weak point is still to get the highest peak of the random noise. The peak function can't be shortened because the highest peak could appear at the very end. I preserve further improvements for the bundled panning plug-in. However, suggestions are stil appreciated.

panrand.ny

corrected version

(1.33 KiB) Downloaded 338 times

[steve]

removed duration after "noise". This was the main reason for the crashes, because the noise was 'duration (sound)^2' long,

Good catch.
I have applied (only) this fix and reverted my previous change.

I agree that you have made some other good enhancements, but as this plug-in is likely to be retired shortly I'd like to to keep the changes to David's original code to a minimum.

More about your other changes to follow....

[steve]

correct mono-conversion (-6 dB)

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.

removed duration after "noise".

Thanks - that's fixed the problem and has now been applied.

Some input correction

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:

Code: Select all

 ;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.

New default values

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.

Stereo width offset in order to preserve the full gain for narrow signals

Nice enhancement.

Simpler code layout, some minor bugs removed.

The code could be simplified and memory usage reduced further still. I'll start a new post as this one is already long.