add initial draft of ideas

README.md

+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.