Commit 18214a72 authored by Jonathan Wilkes's avatar Jonathan Wilkes
Browse files

Add initial draft of difficulty level for each idea plus language requirements

parent 823bc0cc
......@@ -12,6 +12,24 @@ 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.
Difficulty level: Moderate. One of the challenges here is that not all classes
have sane defaults for their methods. For the most obvious example, the internal
class [until] will iterate in an infinite loop when the "bang" method is
invoked. Even with external libraries, such poor defaults are entrenched. A
robust testing system must therefore work around these challenges.
Another challenge is that a substantial number of the external libraries have
never been tested at all. Many are not 64-bit clean. With this in mind, there
will probably be an initial high number of crashes with any testing system.
A maintainable and sensible testing system will therefore take an incremental
approach, starting with the most well-tested and popular libraries and
branching out from there to the more obscure ones.
Languages: thanks to some introspection classes availabe in Purr Data, the
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
......@@ -47,6 +65,18 @@ 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.
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.
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).
API for HTML5 Web Apps
......@@ -78,6 +108,11 @@ the web app (or perhaps using Pd's search path).
* the Pd patch we wanted to open has loaded
* the Pd patch we loaded has closed
Languages: Javascript. Some basic knowledge of C will be helpful if we need
to add a method in the Purr Data engine. However, such methods will probably
be quite simple and won't require implementing any complex algorithms in the
C language.
K12 Mode
......@@ -105,6 +140,15 @@ Either way, this feature vastly improves the usability of Purr Data for new
users, giving them a way to quickly generate sounds and experiment with the
Difficulty: Hard. A lot of the initial implementation of K12 mode was made
in the core engine in C. This will require at least reading a lot of the
source code and making sense of the changes made for K12 mode, plus possibly
refactoring some of that code so that it can be handled in the GUI instead.
On the other hand, there is a working version of the old K12 mode which can
be consulted as a reference implementation.
Languages: Javascript, C, CSS, HTML.
Profile and Optimize Purr Data for Realtime Safety
......@@ -154,6 +198,16 @@ like netsend, netreceive, etc.)
by just hand-unrolling one or two classes when N=64 (i.e., the most common
block size) and measuring the performance impact (if any).
Difficulty: Moderate to hard. The initial profiling will take some time but
isn't particularly challenging. Making changes to the core audio engine,
however, will require some knowledge of Linux system interfaces and some of
Purr Data's internals. Properly assessing and testing any threading techniques
in C is also frought with peril and will require extreme care in order to
keep the code maintainable and avoid insidious bugs.
Languages: basic to advanced shell scripting, C, plus familiarity with
profiling tools like gprof and others.
ASCII art to Purr Data diagram conversion
......@@ -190,6 +244,21 @@ could disallow objects to overlap with each other. Still, the connections
among the various objects (i.e., the arcs which connect the nodes) could
overlap in such a way that makes unambiguous ASCII art impossible.
Difficulty: Easy to hard. This idea runs the gamut-- a simple GUI-side
parser for simple ASCII art is a quick exercise. Handling some of the more
complicated art with multiple and/or crossed connections is moderate. Scanning
the mailing lists for examples and covering the majority of them is hard.
Additionally, converting an existing Purr Data graphical diagram back to
ASCII art is a difficult problem. This will require reading up on the current
state of the art and comparing various approaches from other fields like
OCR and some of the current work converting Photoshop mockups to HTML pages.
However, Purr Data diagrams tend to be much simpler than arbitrary Photoshop
art, so the problem may be more tractable here than in other fields.
Languages: Javascript if converting ASCII art to Purr Data diagram, C if
attempting to convert from graphical diagram *back* to ASCII art.
Navigation of "Wireless" Objects
......@@ -217,6 +286,17 @@ of hyperlinks to the console. When the user clicks any hyperlink, the
corresponding object can be highlighted (or the relevant diagram brought up
with the object in it highlighted).
Difficulty: Easy to moderate. Purr Data's bindelem and pd_bind API are a little
tricky if one hasn't used them before. However, once that interface is
understood it is all that is needed to return a complete list of all
nonlocal objects bound to a particular symbol.
The remainder of the problem is easy and can be done in Javascript. However,
this problem "upgrades" gracefully. Once the initial UI is done, it can be
tested on users and iteratively improved from there.
Languages: Javascript, C.
Terminal REPL
......@@ -241,3 +321,9 @@ It would be very beneficial to create a REPL UI that is more user-friendly
and well-documented/specified. This way Purr Data users can always interact
with and create programs easily on any embedded device, even if there is
no direct display. (This would also be very handy for debugging purposes.)
Difficulty: Moderate. An initial REPL can be created with the current Purr
Data API, but it won't be particularly user-friendly. To achieve that requires
more work and an understanding of Purr Data's message dispatching system.
Languages: C, some shell scripting.
Markdown is supported
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