Pro-grammable fade

Split from

I’ve updated “Pro Fade Out” so that it is now programmable.

By default it is a one click fade out effect the same as the previous version, but with the optional “Pro Fade Configure…” plug-in it can be “reprogrammed” to apply a different fade type.

How it works:
On its own, Pro Fade Out works exactly the same as the previous version. It’s still a one click fade.

The optional “Pro Fade Configure” plug-in, offers a choice -of fade types and an optional sweep filter.
When run, a small file is created in the users home directory (about 115 bytes) called “pro-fade.cfg”. This stores the “preference” settings for the Pro Fade Out effect.

When Pro Fade Out is run after running the configuration tool, it will apply the type of fade that has been set,
Resetting Pro Fade Out to the defaults is a simple matter of deleting the configuration file,
The fade type may be reprogrammed at any time by re-running the configuration tool.

Currently 3 fade types are supported:

  1. “S Curve” (default)
  2. “Rounded” (like the current “Cross Fade Out”).
  3. Linear

To disable the sweep filter, set it to 20000 (maximum).

Additional fade types could be added in future versions.

I think this also opens up the way to providing a one click “Pro Fade In” effect.

The version attached is a “proof of concept” beta version so there are still a few rough edges.
Pro Fade Configure… is a “Generate” type plug-in. (It should really be in the “Tools” menu, but that is not currently supported by Audacity).
Pro Fade Out is an “Effect” as before.
profade-config.ny (1.68 KB)
pro-fade-out.ny (2.26 KB)

Thank you Steve.
This brings us a huge step nearer to the customizable fades I’ve proposed a few weeks ago.
Audacity has an orphine folder called “presets” which would be ideal to save the config file (better than in the home directory, would it be not?).
But it seems to be hard to allocate its exact position from within Nyquist and I can only judge for my Installation on Windows.
At least, your plug-in is highly modular and can be adapted to include a pro fade in and a pro cross fade over time.

I’ve finally found some time to test this (rather than just read Steve’s outline description and instructions).

My initial thoughts (before I tested it and read the associated thread where we are discussing similar ) were

  1. First the negative - it stops this just being a very simple fade-out with no controls or parameters at all (for me as a non-geek-simpleton it was ideal) - the programmable aspect forces me to think about it.

  2. On the plus side - it looks as they we can counter the argument that surfaced on one of the discussions (dev email ?) that it is not really a Professional fade - the increased power given to the user will probably lift it up into the pro-league.

3)I assume that the default will be exactly the same as the existing early implementation Pro-Fade - is that correct?


To address theses points post-testing and post-reading the associated Musical Fade In effect thread)

  1. Assuming that we implement such that only Pro-Fade-Out (and possibly Pro-Fade-In) is distributed with the Audacity distribution and that the Pro-Fade-Configure is available as an optional download for expert and power users - then this will remain as a nice simple easy-to-use one-click effect for the average user (and the newbies). Having said that I think I could live with making the configurator part of the release and not an optional download - I have mixed thoghts about this - we would need to think carefully about the documentation so that it doesn’t scare-off potential users thinking it’s too complicated.

  2. With the configuration tool it is certainly looking much more like a “professional fade” justifying it’s name (a name that also hints at its pro-grammability as Steve points out elsewhere)

  3. I am unclear as to wheteher or not I get exactly the same effect out of the box as the old Pro-Fade. My OOTB settings dor the generator tool are S-Curve (which I thinks is correct) - but the Sweep Filter is set to 0 Hz (and I’m not sure that is correct to match the original Pro-Fade).

  4. I had a bit of trouble finding the congurator after I loaded it into the plugins folder for my test-bed Audacity. It appears in the Generate menu which is a totally inappropriate place for it. I initially looked for it under Effect menu then had a look in Preferences, both of which seem somewhat logical to me - but I certainly wouldn’t expect to look for it under Generate

  5. Am I assuming correctly that Gale should be able to use this effect and the configurator to create handy one-click fades for his favourite Cross-Fade-In and Cross-Fade-Out.

  6. Am I assuning correctly that if we did have the Musical Fade in (or Pro-Fade-In - and I prefer this nomenclature) then the configurator would expand to have an additional separate curve-type for the fade-in (and a separate sweep filter control)?

I am more than slightly worried that we are now discussing the Pro-Fades in at least 3 different forum threads:
a) here
b) Musical Fade:
c) the poll:

But it’s looking good to me - just a tiny bit more polish needed


Thanks Robert. Your suggestion sounded ideal for “Pro Fade” effects, particularly as there was so much diversity in opinions regarding “what sort of fade should a musical fade-in be”.

Writing the preferences to a file in the same folder as the Audacity presets would be better, but as you allude to, Nyquist is not able to automatically and reliably determine where that is.

Yes, exactly.
The next version will support “Pro Fade In” and “Pro Fade Oui”.
After that will come support for a modified “Cross Fade Classic” (possibly renames “Pro Cross Fade” so as to be in line with the Fade-in/out effect)?
The configuration file will also include version information so as to avoid possible conflicts with configuration options belonging to a different version.

It is “very similar”.
I will be experimenting with tweaks to the “Pro Fade Out” prior to release. The original version that I posted is imho a good fade and remains as the benchmark. It would be difficult to modify it after release because users may become used to and like the original release version, so it is important that the fade type is as “good” as we can get it.

This is due to quirks in how Audacity handles Nyquist plug-ins.
The configuration tool is not an “effect” in that it does not process audio. Ideally I think that it should be in the Audacity “Tools” menu, but the Tools menu is currently disabled and there is no “Tools plug-in type” for Nyquist plug-ins.
The only menus available for Nyquist plug-ins are: Generate, Effect and Analyze.
Effect and Analyze plug-ins require an audio track selection.
This “quirk” is possibly another reason for making this tool optional.

Yes. :slight_smile:

Yes, and as I wrote in my reply to Robert, eventually it would support a one click crossfade.

Each of the topics are related but have a different focus. Let’s try to keep “on topic” as much far as possible :slight_smile:

I hope you don’t mind Steve.
I’ve made some changes to your original.

  • The configuration tool no more saves an *.cfg file
  • It modifies the Pro Fade Out plug-in directly.
  • The pro fade out is now very slim again. It does no longer have to load the cfg-file.
  • Only a comment refers still to the configuration tool, no other ballast.
  • The Config tool appears now under effects.

Its name is changed to “Pro Fade Setup”, not because the old name was bad. My goal was to have all 4 plug-ins in one menu, one after the other like:

  • Pro Cross Fade
  • Pro Fade In
  • Pro Fade Out
  • Pro Fade Setup

“Pro Fade Configure” would unfavourably appear in the middle of the other effects.

I thought it would be nice to have the configuration tool in the effect menu as well since it is the place where the user most likely “stumbles” upon it.
It is clear that it will eventually belong to the tool menu. I don’t like the generate menu because it accidently generates new tracks.
pro-fade-out.ny (1.7 KB)
pro-fade-setup.ny (2.62 KB)

Unfortunately that is not a reliable solution because the plug-ins folder may not be a sub folder of default-sf-dir.
On my computer the set-up plug-in returns “Pro Fade Out could not be found”.

I don’t agree that it should be in the Effect menu for two reasons.

  1. it is not an effect.
  2. It should not be necessary to make an audio selection to run this tool.

I agree that the Generate menu is far from ideal, but the plug in does “generate” code, so in that sense it can be said to be a “generate plug-in”.

I think that the idea of directly modifying the plug-in code is very neat (you’re certainly very good at coming up with neat solutions) but unfortunately on this occasion I think it is a non-starter. (see

On Linux the default plug-in folder is:

  • /usr/share/audacity/plug-ins if Audacity was installed from a repository package
  • /usr/local/share/audacity/plug-ins if you compiled Audacity from source code.

Neither of these locations are writeable unless Audacity is run with elevated permissions.
The user may optionally create a folder called .audacity-files within their home directory and put a plug-ins folder there,

On Windows the default-sf-dir can be in one of a number of locations. If you look in fileio.lsp you will find this code:

;; if *default-sf-dir* undefined, set it to user's tmp directory
(cond ((not (boundp '*default-sf-dir*))
       ;; it would be nice to use get-temp-path, but when running
       ;; the Java-based IDE, Nyquist does not get environment
       ;; variables to tell TMP or TEMP or USERPROFILE
       ;; We want to avoid the current directory because it may
       ;; be read-only. Search for some likely paths...
       ;; Note that since these paths don't work for Unix or OS X,
       ;; they will not be used, so no system-dependent code is 
       ;; needed
       (let ((current (setdir ".")))
         (setf *default-sf-dir*
               (or (setdir "c:\tmp\")
                   (setdir "c:\temp\")
                   (setdir "d:\tmp\")
                   (setdir "d:\temp\")
                   (setdir "e:\tmp\")
                   (setdir "e:\temp\")
         (format t "Set *default-sf-dir* to "~A" in fileio.lsp~%" 
	 (setdir current))))

I don’t think we should be putting it in a sub-optimal menu - and it doesn’t fit in either Generate or the Effect menu imo. If we beieve that it belongs in the proposed “tools Menu” then that’s what we should aim for.

There is no real rush as I think it is fairly clear that the configurator will not make 2.0.3 - so I would argue for doing it righ the first time.


This is a bit of a “chicken and egg” situation.
There was a “Tools” menu in some 1.3.x versions (the code is probably still there) but the only thing that was in it was the (optional) Nyquist Workbench module.
The Tools menu only appeared if there were menu items - which in practice meant only if Nyquist Workbench was installed.

It was decided (by ??) that there should not be a menu with only one item in it (though I’m not aware of any user complaints about it) and it was thought that moving Audio Device Info, and Screenshot Tools into the Tools menu would leave the Help menu looking bereft.

Nyquist Plug-ins are currently available in 3 flavours:
;type generate
;type process
;type analyze

These “types” appear respectively in the Generate, Effect and Analyze menus.

“process” and “analyze” types require an audio track selection. The selected audio is passed to Nyquist in a “global variable” so that Nyquist can process or analyze it.
“generate” types do not require a selection, but if there is no selection then a mono audio track is created before launching the plug-in.
“generate” types are not able to access selected audio and have a different concept of time from analyze or process types.

The reason for all of this information is that for a Nyquist plug-in to appear in the Tools menu (assuming that the menu exists) there would need to be a new plug-in “type”.
Creating a new “type” of plug-in is not simply a matter of which menu it goes in, but also involves deciding how a plug-in of this type behaves and how Audacity treats the plug-in.

Personally I thing that a “utility” type plug-in would be a useful addition and plug-ins such as “Regular Interval Labels” should be converted to this type (it is currently an “analyze” plug-in, even though it does not analyze anything.

There is an increasing number of plug-ins that do not generate, process or analyze. This “Configure” tool would be one more and may help to make obvious the need for a new plug-in type.

This penguin thing starts to be a nuisance.

  • no proper playback available
  • No key navigation in multichoice controls
  • plug-ins can be anywhere
  • When found the folder is likely read-only
  • and what next?

It seems that I have to specify my plug-ins with “Windows only”.
The code from the fileio.lsp is primarily made for the standalone version of Nyquist (where the “get-env” was not available). I was up till now never in the situation that default-sf-dir was unbound- However, it may be better to get the current directory via “(setdir “”)” and then to search for the plug-in folder via “listdir”.

As far as I remember, we’ve reached an agreement about the tools menu and the utility version of the Nyquist Plug-ins.

  • The utilities should always be available, if there are Tracks in the project or not.
  • Selections are not modified
  • Label tracks or text can be returned.
  • The plug-in is only executed once, no matter how many tracks are selected.

Ok, there were scarcely more opinions then our two. I guess that features which deal in a higher degree with plug-in development are not very popular among “normal” users and the C++ programmers do seldom follow those discussions.

As one of the developers once said to me: “welcome to the joys of cross-platform programming”
Of course if you used any operating system other than Windows you would be looking at this very differently :smiley:

but it still applies to Nyquist in Audacity.
For example, if you have a folder C:tmp then default-sf-dir will point there.

Unfortunately that is not reliable on Windows either. If Audacity is launched from a shortcut then the location pointed to by (setdir “”) depends on whatever has been set as the working directory.

Yes, I think that we are in broad agreement about what a “tools” plug-in would be. Now we just need to find an interested developer.

My root directory has a temp folder, but it is never taken as the default directory.
Maybe default-sf-dir gets always the working directory (from the shortcut.lnk) - which normally should be right (on Windows).
The self compiled version gets the right location too (unicode release) for both methods.
Over the years one might give me a feed back that one of my plug-ins does not run on his Windows, till then I have to take the risk.