Commit 285f29c9 authored by Jonathan Wilkes's avatar Jonathan Wilkes
Browse files

initial update of list for 2019

parent 6ea41e6b
[Automated Testing Framework](#automated-testing-framework)
[Change to Double Precision Floating Point Format](#change-to-double-precision-floating-format)
[Inject Purr Data Directly into the Web](#inject-purr-data-directly-into-the-web)
[API for HTML5 Web Apps](#api-for-html5-web-apps)
......@@ -60,57 +60,40 @@ Testing framework can be fully implemented in Purr Data itself. However, some
familiarity with shell scripting tools and the platforms supported by
Purr Data will be useful (i.e., Windows, OSX, and GNU/Linux).
Change to Double Precision Floating Format
Inject Purr Data Directly into the Web
### Goal
Change Purr Data's numeric data type from single-precision floating point
to double-precision floating point.
Add a WebAssembly target and pure HTML5 GUI framework for running Purr
Data from a browser window
### 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).
Installing Purr Data is often the biggest hurdle for newcomers. Running
it in a web browser simplifies this process and allows Purr Data to be run
on any device, with any architecture, as long as it has a web browser installed.
### 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.
For the core, we want to produce a WebAssembly binary that can load a patch
and produce audio using the Web Audio API. If possible, we want to also
leverage Chromium's newer callback-based interface to compute realtime audio
as efficiently as possible.
For the GUI, we need a framework that can display and edit a Pd patch
within a container in a web page. It should be possible to run the core
WebAssembly binary with or without the GUI displayed.
The challenge with the GUI is that Purr Data currently uses multiple
toplevel windows to display a patch and its visible subcanvases, and
properties windows for certain widgets. The framework needs to allow
viewing all of these in a container within a *single* browser window.
### Difficulty
Hard. This is mitigated somewhat by the prior work of Katja Vetter
and others who have done double-precision implementations for most of the
core audio engine. Still, this change touches many different parts of the code
and will no doubt result in some insidious crashes and runtime errors that
will require a well-rounded knowledge of the C programming language, floating
point type standards, and Purr Data's internals including the core DSP
API and algorithms.
Hard. There has been some prior art for building a WebAssembly binary
for the core audio engine. However, the difficulty will lie in building
the GUI framework that has a workable UX within a single browser window.
### Languages
C, some C++ (for some of the external libraries coded in C++),
plus basic shell scripting familiarity (both `find` and `grep` will come in
handy here).
C, HTML5, and Emscripten
API for HTML5 Web Apps
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment