Time is handled differently depending on whether you are running the script as a “generate” type plug-in or as a “process” (Effect) type plug-in.
In the case of generate type plug-ins, 1 “unit” of time is 1 second.
Try this in the Nyquist Prompt:
In process type plug-ins (“Effects”), time is stretched according to the length of the selection. In this case 1 “unit” of time is the full length of the selection. This example will produce white noise that is half the length of the selection:
By default, the Nyquist Prompt runs code as “;type process”, so this will also produce noise that is half the length of the selection:
For “;type process”, this “should” produce noise that is twice as long as the selection, but there’s a bug in the current version of Audacity that prevents it from exceeding the length of the selection:
The audio returned by Nyquist replaces the selected audio.
So if you select 2 seconds of audio and Nyquist returns 0.5 seconds of audio, the track will shrink by 1.5 seconds.
What you’re doing here is mixing (adding) the noise to the original audio that was in the track.
Nyquist returns the sum of (a mix of) the original selection and the noise. Because the track component of the mix is exactly the same length as the selection (it is the selected audio), the returned mix is the same length as the original selection. When the returned audio replaces the original selection, we still have that original audio because we added it into the mix.
The really useful thing about the (somewhat strange) way that “;type process” effects stretch time, is that if you want to return exactly the same amount of audio that is selected, then you don’t even need to know how long the selection is. You just return sound of length 1.
(sum *track* (mult 0.2 (noise)))
will add the exact same length of noise as the selection length.
Don’t pay too much attention to the coding style in “aud-do-support.lsp”. That was written by myself and has a lot of very ugly code to bridge gaps between Nyquist and Audacity. It probably is worth taking a look at the functions in there as there are some useful functions that are not part of the stand-alone Nyquist (such as the two little functions and the little macro at the top). The big functions are for enabling Nyquist to send commands to Audacity through Audacity’s scripting API.
Good point about the formatting, much easier to read, will use it from now on.
As for the .lsp files, uhmmm, you have presented a veritable smorgasbord of possibilities.
Some great macros and also, the possibility of creating new ones.
My thinking is not to mess with the original files, but rather create a new one and add it to load in nyinit.lsp
Of course then any ny scripts that use the new functions/macros would not be standard.
Another possibility, since there is already a SAL parser, it would be theoretically feasible to create another “language”.
I’m quite enjoying Lisp now, so wouldn’t change, but thinking about something simpler which would hopefully entice more people to try out Nyquist.
Yes, and for that reason it is nearly always best to include all custom functions and macros in the actual plug-in .ny file. You can then share your plug-ins with others, and easily install on multiple computers.