Automated Testing Framework
---------------------------

Goal: build a testing framework that covers most of the methods of all internal
and external classes that ship with Purr Data. This should include the "dsp"
method of all signal-based externals, so that we can compare the block output
of each across commits to serve as both a regression and code coverage test.

Benefits: this will make it easier for newcomers to make fixes and improvements
to both the core of Purr Data and its many external libraries. Clear errors
from the CI will help them catch bugs earlier in the development process,
leading to overall cleaner code in merge requests and less disruption to
users from regressions.

Change to Double Precision Floating Format
------------------------------------------

Goal: change Purr Data's numeric data type from single-precision floating point
to double-precision floating point.

Benefits: Purr Data has a single numeric type to represent numeric data.
Changing this type to double-precision has many benefits:
* increased precision in the internal sample format used in the audio engine
* increases the maximum index into an array of audio data without losing
precision. Current single-point floating point indicies severely limit
array indexing, requiring the user to manage both an index and an onset into
the array to retain precision.
* creates a consistent interface between the core audio engine and the HTML5
GUI which itself uses double-precision floating point for represented numbers.
* makes it easier for cases where users want integers, as a double-precision
floating point type can itself contain a 32-bit integer. (Single-precision
floating point cannot.)
* makes it easier for third-party developers to interface with Purr Data. For
example, the upcoming MIDI revision uses 32-bit integers which can simply
be converted to double (while single-precision would lose data and require a
more complicated approach).

Details: this requires some changes to the core, leveraging Katja Vetter's
previous work to find performant replacements for the core DSP classes. It also
requires changes to some of the external libraries-- such as freeverb and
others-- which either have separate APIs based on numeric precision or rely on
the numeric type being single-precision.

This work will benefit immensely from the automated testing framework listed
above. That framework will immediately reveal many crashers and discrepancies
in output of the "dsp" methods of external classes. Developers can then use
the output of those tests to get a better sense of the scope of the work and
prioritize which libraries to refactor first.