Audacity Fade effects


I strongly recommend the implementation of Text-envelope in the standard audacity installation. I was really happy, when I stumbled over it some years ago. If you’re low-sighted its much more frustrating to have no possibility to modify the envelope than using a plug-in that up till now works on a destructive basis. I don’t believe it to be to complicated, there are other plug-ins which are much more difficult to get familiar with.
there’s a little confusion about the commas and decimal points and the allowed seperators. First of all, in switzerland, the decimal point is used, so no need to lump all Europeans together regarding the usage of the comma. Which seperator one wants to use is certainly a individual preference, I like seperation by spaces the most. For myself, I’ve expanded Text-envelope in order to use it as an pan-envelope as well (since it can’t be achieved otherwise without a mouse). The percentage determines the position of the signal in the stereo field. For “normal” users it may be better to create a seperate plug-in on a text-envelope base, where the choice of dB/% can be omitted.
In the actual plug-in, as it is, I miss certainly the different curve-types. I always have to pre-calculate the input for the text-box in excel if I am in need of a logarythmic, exponential, gaussian, LaPlace or other type of interpolation. Therefore, an additional multichoice with, let’s say, two other curve styles would be nice. Standard tasks as fade-in and (pro-) fade-out could also be included in this box. Of course, it should be clarified that the other inputs are ignored.
I hope this feed-back helps a little.

I’m in no doubt of the usefulness of some kind of “text envelope” not only, but especially for blind, partially sighted and other non-mouse users.
As non-mouse users have no other way to modify the envelope (other than compression) I think that accessibility must be the overriding priority with this effect.

The question is in getting the balance right between providing enough features and flexibility without it being too cumbersome.

After some very useful feedback from the Audacity4Blind, the current version seems to have a lot going for it and is at least close to that balance.
It seems that the main use is when there is a need to make a section go to a different level, then back again.
The “Manual Duck” effect ( ) is also quite popular, though a little less flexible in some ways.

What I have in mind at the moment is to go somewhere between these two effect.

Q. Would a “text envelope” effect be sufficiently flexible if it had just three sections to the envelope?

The Manual Duck effect fades from the initial level, to a new level (section 1), then remains at that level (section 2) before fading back to the original level (section 3).
What I have in mind is a similar 3 section envelope, but in which all “control points” can be set to any value:

Essentially this means that there is a fade at the start of the selection (Start Fade), and a fade at the end of the selection (End Fade).
The section between the Start Fade and the End Fade is an extrapolation.

  • Initial gain level of Start Fade
  • Duration of Start Fade.
  • Final gain level of Start Fade.
    (Extrapolate from end of Start Fade to the beginning of End Fade.)
  • Initial level of End Fade.
  • Duration of End Fade.
  • Final gain level of End Fade.

I think that this would cover the vast majority of user cases.
If more fade points are required, the effect could be repeated section by section along the track.

As with the full version of “Manual Duck”, a choice of fade shapes (linear, log, sine) could be available.

Would this be simpler?
Would this be sufficiently flexible?
Would the “fade shape” need to be individually selectable for both Start Fade and End Fade, or would it be a global option? I think I’d prefer individual selection, with a clever choice selected automatically for the extrapolation.

Point taken (pun intended :slight_smile:)
The important issue is that Nyquist can currently only use a dot as a decimal separator.
It is possible (but quite complicated) for the code to substitute dots in place of commas, but then there could be a problem if someone uses commas as value delimiters.

If multiple values are entered in the same text box, then probably the best workaround is to insist on users entering a dot as the decimal separator, then the value delimiter can remain flexible.

With the “three section” envelope proposed in my last post, there would only be one value per text box, so I could probably code it to support dots or commas.

Having thought about this some more, this idea and the previous “list of time/gain pairs” do not have to be mutually exclusive.
If each of the settings is a text box, then it could still support an advanced feature for advanced users of using a list of values in one or more of the text boxes.

I don’t propose working on the “advanced feature” unless there is definitely a demand because it will be a lot of work sorting out how best to implement it. Just writing to say that it would be possible.

well, you probably can guess, what I think about a simplification. if I want to get the 3-section envelope in the current version i have simply to specify the start and end values and then to enter something like 3 (s) 50 (%) -2 (s) 70 (%). What could be simpler? In your proposed version, i had to move between 9 sliders (1 choice db/linear 2 x shape selection 2 x start gain 2x duration 2 x end gain). Additionally, I’d loose much flexibility and the ability to enter pre-calculated values (which is of course seldom enough of use for other people).
What do you mean by extrapolation? I think the result would be rather unpredictable. Assumed we’d like to produce a 3 sec envelope that fades in the first second from 100 % to 50 % and in the last second from 20 % to 100 % again. If you extrapolate those two fading lines you’ll receive a curved middle-section (which can go below 0, as in our example or above 100 %, depending on the values). The current version goes linearly from 50 to 20 % in that area. A little edge smoothing wouldn’t be bad however (if one wishes).
At the moment I can’t think of a useful application for two different shapes in one plug-in call but who knows, what’s desired?

That sets the standard. It must be no more complicated than that.

With what I have in mind, the default fade shape would be linear (like the text envelope).
All numerical input would be by direct text entry (same as the text envelope).
A gain field left empty would default to unity gain (same as the text envelope).

Taking your example, in the proposed version, to create the same (identical) envelope would require specifying:

Fade at start:

  1. The Initial gain level of Start Fade
  2. 3 (seconds)
  3. 50 (%)

Fade at end:
4) 70%
5) 2 (seconds)
6) Final gain level of End Fade

Exactly the same number of settings.

Where I think this may be a little simpler is that (5) specifies the duration of the end fade, rather than entering a negative number to do so.
It is possibly a little less abstract to consider one fade at the start of the selection and one fade at the end, rather than a string of gain / time pairs.

Possibly the main benefits is that if, for example, you want a log fade from unity gain to 10% then a log fade from 10 % to unity gain, there is no need to launch a spreadsheet application. Simply set each fade as logarithmic and the curves are calculated automatically.

A good question.

The simplest method would be linear extrapolation between the end of the “Start Fade” and the beginning of the “End Fade”.
If both Start and End fades are specified as linear, it would make sense to keep it simple.

For other fade types, I’m experimenting… no conclusion yet.

Cubic extrapolation is a possibility, but as you point out makes the mid point difficult to predict (though it could be bounded to prevent clipping or “below silence”.
[as an off-topic curiosity, sending the envelope “below silence” produces phase inversion].

I agree, but it would need to be (yet another) option, so perhaps not worth the extra complication.

So I take it that you (personally) would like to keep that flexibility?

Would it be useful for you to have a plug-in that has just one text input for entering envelope parameters? (which include the initial and final gain as the first and last values). Would that be easier when preparing envelope data in Excel?

I think that the layout with two sliders for start and end gain is perfectly straightforward. The values these points should have come most likely firstly to one’s mind even if the shape of the curve between those points is not yet clear. When I model a curve, even if pre-ccalculated, these values often stay the same (100 % or 0 % in most cases) and the rest is found by trial and error.
It is somewhat funny, before I got blind, I was graphics designer and I always struggled with vectorgraphics when choosing the right line typ for a specific section. When I changed the wrong point to bezier-mode, the design could not even have been printable on a DIN A0 page… But there’s the big difference, I got a instant visual feedback. Most people can’t imagine what the different interpolation types represent and so they use the linear one in case of doubt. I wonder if a aural feedback would be of any help. What I have in mind is approximately this:
Before the sound is returned to Audacity, the selection is played by a special manner. In pseudo-code something like this:

(setf s (mult envelope s)); return the sound to Audacity
(setf right s); right channel: result
(setf left (sim click-sequence; every second or in fractions of it
points-set; optionally buzz-tone for the points of the envelope 
(mult sine-tone envelope)))
(s-save-autonorm (vector left right) "" :play t))

That’s only a coarse idea and I didn’t test if it is possible to play the sound and at the same time return the s variable - probably not. if it worked, It may help to see whether one has set his points at the right place or how they must be modified in the next plug-in call. there are a lot of situations, where I miss aural feedback sadly, especially in analyse plug-ins but that’s another story.

I don’t think that sounds can be played from Nyquist within Audacity.

On my machine (windows 7 64) it works fine. Try the following code on a mono-track:

(setf s (abs-env (pluck 60 2))); return middle C
(s-save-autonorm (abs-env 
(force-srate 44100 (scale-srate s 0.5))); slow down s
ny:all "" :play t))

The question is only, if it works under all operating systems. (s-save has a misleading name though, it saves nothing (in contrast to s-play) and the autonorm suffix ensures that you don’t shoot over 0.9 amplitude. I am using it in a plug-in, where all nyquist-functions and their description can be displayed. if selected, an example of the function is played prior to the text-output in the debug-window.
I only didn’t know if a sound can be returned at the same time. Please tell me if it works on your machine too.

How about as a first step writing a proposal in the Wiki with mockup GUI etc. (as this thread is getting harder to follow) ?


A mock-up GUI is not very useful for blind and partially sighted users.
There is a concurrent discussion about text envelope on Audacity4Blind.
I’ll merge the information into a new proposal when the information is all in.

It doesn’t work reliably on my machine.
Sometimes it will work, but most times it returns the message:

warning: could not open audio, error -9985, Device unavailable.
 44880  88740  132600 
total samples: 176400
AutoNorm: peak was 1.23344,
     peak after normalization was 0.9,
     suggested normalization factor is 0.729668

On the occasions that it does play, it plays it too slow and low.
Why do you have (scale-srate s 0.5) ?
On my machine this plays at the correct pitch and tempo (when it works)

(setf s (abs-env (pluck 60 2))); return middle C
(s-save-autonorm s ny:all "" :play t))

I was not able to find any documentation on “snd-play-autonorm”
but I checked using “snd-play”

(setf s (lp s 2000)) ; doing 'something' to check that it works
(s-save (force-srate *sound-srate* s) ny:all "" :play t))

Again this works some of the time on this machine but not 100% reliably.

I note in the Nyquist manual:
“(play: [SAL] or :play [LISP] is not implemented on all systems;”

hmpf, what a pity! I never ever have this problem, but I feared as much. The scale-srate is of no importance, if you’d applied the code to a music track, it would have played the music at half speed and one octave deeper, just suitable for analyze purposes (force-srate isn’t important either). I gather you tested under Linux? It seems that I have to include a OS detection function in my plug-in. Anyway, I don’t wanna stray off-topic. Thus we can discard any audio feedback ( -sigh- ).

Ps. you were a little bit faster. Could the result be improved by an start-adjustement per snd-set-latency? the description of s-save can be found on the smu homepage. can also some functions be inspected that are not yet on the Audacity-page.

s-save(expression, maxlen, filename, format: format, mode: mode, bits: bits, swap: flag, play: play) [SAL]
(s-save expression maxlen filename :format format :mode mode :bits bits :swap flag :play play) [LISP]
Evaluates the expression, which should result in a sound or an array of sounds, and writes the result to the given filename. A FLONUM is returned giving the maximum absolute value of all samples written. (This is useful for normalizing sounds and detecting sample overflow.) If play is not NIL, the sound will be output through the computer's audio output system. (play: [SAL] or :play [LISP] is not implemented on all systems; if it is implemented, and filename is NIL, then this will play the file without also writing a file.) The latency (length of audio buffering) used to play the sound is 0.3s by default, but see snd-set-latency.

Note: nil doesn’t work as file name, use an empty string instead (“”). the function is in fileio.lsp, but it would be more interesting to know what happens in the low level (snd-save) function.

That is not happening here.
On my machine, when applied to an audio track your code is playing the audio at double speed and one octave higher.

The problem with playback from Nyquist on my machine appears to be with how Nyquist is accessing the sound system. It looks like there is a race between whether or not an audio port can open before Nyquist starts playing. I’d have expected that increasing (snd-set-latency latency) would fix that, but that’s not working correctly. On my Linux machine, increasing the latency just adds a delay after the sound has played.

Interestingly, playback from Nyquist seems to be completely reliable on a virtual Linux machine (running in Virtualbox). I presume that this is because the host sound system keeps a port permanently open for Virtualbox, whereas audio ports for Audacity are opened on demand.

Just playing around with “previews”:


(setf beep 
    (mult (pwlv 0 0.1 0 0.15 0.5 0.3 0.5 0.35 0 0.5 0)
      (osc (hz-to-step 1000) 0.5))))

(defun preview (sig)
  (s-save sig 
    (truncate (* 3 *sound-srate*)) "" :play t)
  (s-save beep
    (truncate (* 0.5 *sound-srate*)) "" :play t))

(preview s)
(preview (mult 0.5 s))
(preview (mult 0.25 s))

On my XP machine, setting the latency to a high value causes a pause between each preview playback that is proportional to the latency setting.
The latency setting persists for the duration of the Audacity session, so if using Nyquist playback features it is probably advisable to set the latency somewhere near the top of the plug-in in case previously run code has changed it to a problematic value, then restore it to the previous setting after the plug-in has run. For example:

(setq old-latency (snd-set-latency 0.3))
... plug-in code ...
... play functions...
(snd-set-latency old-latency)
... plug-in output...

If I want to change speed and pitch of a sound that is returned to audacity, the following lines produce the same (i. e. 1/2 speed and 8 va basso pitch)

(force-srate 44100 (scale-srate s 0.5))
(force-srate 88200 s)

With s-save it’s sufficient to use (scale-srate s 0.5), since the standard format for files is 44100. But on your Linux, the case seems to be just another one. As your code example shows, a ppppreview (or -listening) was possible and the OS issues are therefore even more annoying.
Besides, with s-save, there is no need to call “(autonorm-off)”, it’s already disabled and the peak value is returned anyway. It took me a while to eliminate the status-reports in the debug-window because I didn’t want them to appear in my plug-in output.
What a bummer that the latency adjustement doesn’t work on Linux either. Stupid question, but is Audacity accessible within Linux, I mean, is there a Screen-reader program available? It wouldn’t make sense to embed a preview feature for visual impaired people, when they don’t use Linux. And what about the Mac? According to the release notes, Voice-over seems now to work with Audacity 2.0.1. Could anyone test the s-save function from above?

There is are a few Screen-reader programs for Linux. The most common one being Orca.
Unfortunately there are some serious accessibility issue in Audacity on Linux that (probably) make it unusable for blind users.
I don’t have a Mac.

I’ll put in a bug report for the latency issue on Linux, and then someone will need to test if it also applies to Mac OS X.

Thank you very much Steve. Here’s another preview possibility:

(set-sound-srate *sound-srate*)
(defun preview (sig env) 
(let* ((pause 0.01) 
(output (mult 0.5 env
(snd-oneshot (osc (hz-to-step 1)  4) 0.0 (- 0.5 pause))
(stretch 4 (hzosc (sim 500 (mult 500 env))))))
(output (sim (pan output 0.5)  (mult env sig))))
(s-save output ny:all "" :play t)))
(setq Text-envelope (pwlv 1 1 0.3 3.5 0.2 4 1)) 
(setq Text-envelope-exp (pwev 1 1 0.3 3.5 0.2 4 1)) 
(preview (s-rest 0) text-envelope)
(preview (s-rest 0) text-envelope-exp)
(preview s Text-envelope)
(preview s Text-envelope-exp)

It may be a good idea to keep the preview of a constant duration, no matter how long the selection is (the original is just resampled). Additionally, the sine tone could be replaced by clicks only. their distance could refer to the amplitude or the steepness of the transition, i. e. the slope, accenting thus the character of the curve.
I realize now, how difficult it is to design a general purpose plug-in, that is of use for everyone. What the Nyquist GUI really lacks is a options or expand button. Thus the main Layout could be kept simple and additional features or controls are only shown, if the user is in need of them. In this way, beginners wouldn’t be overwhelmed by controls they do not understand yet.

Considering the simple GUI design of Nyquist plug-ins, I like the idea of “tabs” for opening addition screens.

Another thing that would be very useful would be the ability to keep a plug-in open after it has run.
This would be useful for plug-ins that require two (or more) passes, but more significantly to what we are talking about, could provide Nyquist plug-ins with a similar preview feature to other effects.

New cross-fade plug-in posted here: