and here’s the problem:
(setq max-len 100000000) ; Empirically determined on my machine, may be hardware dependent.
It appears that not only is hardware dependent, but also Nyquist version dependent.
The easiest “fix” is to remove a zero in the above. This will cause the plug-in to throw an error if more than 10 million samples are selected (rather than 100 million).
"Selection too long for analysis, please select shorter section~%"
Here’s what the Nyquist manual says about SND-SET-MAX-AUDIO-MEM (emphasis mine)@
(snd-set-max-audio-mem bytes) [LISP]
> Sets a limit (a FIXNUM in bytes) on the amount of main memory that Nyquist will allocate for SOUNDs (this does not count table memory). The default is about 1GB. The return value is the previous limit, in bytes. This is not a limit on how big sounds can be. Since Nyquist computes sound incrementally, it can generally play sounds or write sounds to files without storing them in memory. However, > **if you store large sounds in variables, memory usage can exceed your available RAM, causing extremely slow computation as main memory is swapped to and from disk or Nyquist might run out of memory and crash.** > The goal of placing a limit on audio memory is to terminate computations before memory is totally exhausted, allowing Nyquist to print an error message and allowing the user to view or save work. Generally, if you see the message "The maximum number of sample blocks has been reached, ...," > **_[u]you should fix your code to avoid accumulating samples in memory[/u]_**> , e.g. do not assign sounds to global variables. Alternatively, you can use this function to increase the limit, but of course you are still limited by the actual size of memory on your computer, and exceeding that could cause severe performance problems in Nyquist and and any other applications that are running. See also Section "Command Line" for command line options to limit yquist memory, run time, and file access (these options are not available through the NyquistIDE.)
Prior to Nyquist being updated, we relied on plug-in writers to set a limit in cases where large selections could be held in memory. Will McCown did so in ACX Check, and chose a fairly ambitious maximum based on tests on his machine. Unfortunately the "maximum number of samples" that he chose is so large that Nyquist reaches it's maximum audio memory before the maximum number of samples is reached.
So one solution is to reduce the maximum number of samples (as in the "easiest fix"), and another option is to increase the maximum allowed audio memory. This can be done by adding this line somewhere near the top of the code:
The number (3 billion bytes) is sufficient for this plug-in to work with 100 million samples, though if the computer has less than 3 billion bytes of free RAM, then the plug-in is very likely to crash and take Audacity down with it.
So what’s the best fix?
As it says in the Nyquist manual, the best fix would be to rewrite the plug-in to avoid accumulating samples in memory.
Unfortunately, the problem part of the code that accumulates samples in memory is Will McCown’s rather strange code for detecting the noise floor.