[<edgar-rft@we...>]

Hi all,

--------------------------------------------------------------------------=

A transcript of (the important parts) from the 'Windows install problems'
thread, on which this discussion is based on can be found at the end.
In short, I (Edgar) had written to George Jenner:

> ... Nyquist has the habit to compute everything in-memory ...
> This is IMHO a severe design bug in Nyquist.

Roger had complained that this is not true (more details see below).
--------------------------------------------------------------------------=


Edgar: First of all I have to apologize to Roger Dannenberg, there was
email traffic between George Jenner and me beside the list so my writing
has caused unnecessary confusion to all unobjected readers.

George wants to use the NyquistIDE to learn how to work with Nyquist
in Audacity so my writing was related to Nyquist in Audacity, not to
the Nyquist 3.0 JavaIDE version (as my writing unfortunately implied).

Edgar wrote:

> Nyquist has the habit to compute everything in-memory.

As Roger rightfully complained, for the original Nyquist program as it
is implemented e.g. in the Nyquist JavaIDE this is NOT true.

The sound object is in real a pointer to a only a very little memory
consuming block of sound samples, read from the sound file on harddisk,
which is read blockwise into memory. As long as the sound object gets
not assigned to a global Lisp variable (by the Lisp programmer) the
Nyquist sound object doesn't need more memory than the current block
of samples read from disk (plus a bit administration overhead). This is
in deed a very clever menchanism and one of the real great advantages
of Nyquist.

Unfortunately just the opposite is the case with Nyquist in Audacity.
What I mean with this I will demonstrate on practical example.

As Roger suggested, if I write in the Nyquist JavaIDE e.g.:

(peak (s-read "very-long-sound-file.wav") ny:all)

where 'ny:all' is defined by Nyquist itself as a maximum length of
1000000000 samples (what with 44.1kHz equals approx 6.3 hours),
the line from above returns the peak value within a maximum range
of 1000000000 samples without huge memory allocation or even a crash
as long as the sound itself is not bound to or computed from a global
Lisp variable. I have tested this with a WAV file of one hour length
and approx. 300MB disk storage memory size.

If I load the same sound file into Audacity, mark the whole track and
apply the 'peak' function via the 'Nyquist Prompt' from the Audacity
'Effects' menu to the sound in the Audacity track, named 's':

(peak s ny:all)

Nyquist within Audacity starts to allocate more and more memory until
it finally crashes (Audacity 1.3.4-beta on Windows 2000 SP 4 as well as
on Ubuntu 7.10 and Mac OS X 10.3.9). This bug is known to me personally
since Audacity 1.2.3 and has nothing to do with the beta stadium of
Audacity 1.3.x.

This effect may occur, because the Audacity sound is bound to a global
Lisp variable 's' (by Audacity, NOT by the Lisp programmer).

Another point is, that with Nyquist, as it is implemented in Audacity,
I cannot 'dump out' temporary sound files like I can do with Roger's
version. 's-read' and 's-write' are not implemented in Audacity.

What leads to one of my next sentences:

> This is IMHO a severe design bug in Nyquist.

What I meant with this is that this is a severe design bug with
NYQUIST IN AUDACITY, not with Roger's Nyquist 3.0 (I apologize again
that this had not been clear by my writing).

In the Nyquist JavaIDE e.g. a 'normalizing' (amplifying a soundfile,
so that the loudest sample is at the maximum limit) would read like
this:

(let ((peak-value (peak (s-read "very-long-sound-file.wav") ny:all)))
  (s-save=20
    (mult (/ 1.0 peak-value) (s-read "very-long-sound-file.wav"))
    ny:all
    "new-sound-file.wav"))

The example is a bit stupid, because there already is a 'autonorm'
feature build into Nyquist (but not in the Audacity version), but
in deed in Roger's version these lines above don't allocate huge
amounts of memory because 'peak-value' is bound to a local 'let'
variable, even with files bigger than the memory of the computer
there are no problems.

If in Audacity I write the same thing as:

(let ((peak-value (peak s ny:all)))
  (mult (/ 1.0 peak-value) s))

Audacity again starts to allocate more and more memory until it finally
crashes.

I'm sorry but I have no idea what this could be called other than a
severe bug with Nyquist in Audacity.

- edgar

--------------------------------------------------------------------------=

Transcript of (the important parts) from the 'Windows install problems'
thread, on which this discussion is based on:
--------------------------------------------------------------------------=


Roger: I can't help but respond to the following:

[from a previous post written by Edgar to George:]

>> (setq s (s-read "a.wav"))
>> (setq maxl (snd-maxsamp s))
>> (print maxl)
>
> The answer depends on the question 'how big is a.wav'=3F
>
>The reason why I ask this is that Nyquist has the habit to compute
>everything in-memory. If you try to find the number of samples of a
>sound that doesn't fit into the memory of your computer, Nyquist
>just simply will crash.
>
>This is IMHO a severe design bug in Nyquist.

Roger: First, the documentation for SND-MAXSAMP states: "Calling this
function will cause samples to be computed and saved in memory." and
"This function will probably be removed in a future version. See peak,
a replacement". If you look up PEAK, it has a clear warning not to call
it on a variable (as in this example). In fact, if you wrote:

(display "peak" (peak (s-read "a.wav" ny:all)))

then Nyquist would NOT save samples in memory. I would say Nyquist has
a habit of NOT computing entire sounds in memory. The only time it does
is when you EXPLICTLY save sounds in variables. I think it's really that
*programmers* have a habit to save everything in global variables. This
is considered bad practice in all programming languages.

I suspect that in many of these cases Nyquist does not actually crash, but=

performance suffers as memory pages out to disk. So I don't see a good way=

to recover until long after things are thrashing horribly. It might make
sense to put an artificial memory limit on Nyquist so that a program like
the one above would fail quickly with an "out of sample memory" error
rather than attempt to allocate enough memory for all the samples. An
built-in function could allow the user to query and change the limit.
Comments are welcome.

-Roger



--=20
The author of this email does not necessarily endorse the
following advertisements, which are the sole responsibility
of the advertiser:

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Jetzt neu! Sch=FCtzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/=3Fmc=3D022220