add profiling and accessibility ideas

README.md

@@ -327,3 +327,73 @@ 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.
+
+Core Accessibility
+------------------
+
+Goal: ensure that Purr Data is accessible by coupling accessibility
+with the core UX
+
+Details: especially because Purr Data is a graphical environment, it's
+important to make sure the core functionality is accessible. Rather than
+tack on accessibility as an afterthought, Purr Data should have a UX that
+makes accessibility features a generally useful part of the programming
+environment.
+
+For example: how does one navigate the nodes of a Purr Data diagram? There
+should be a way to navigate among the nodes and their connections
+without using the mouse. If we make sure that each element in the diagram
+is annotated we can tackle accessibility and keyboard navigation at the
+same time. Thus, a robust keyboard navigation implementation will help
+make it possible for screen readers to give meaningful information about
+each node in the graph.
+
+Difficulty: Moderate. For example, it will be necessary to study the current
+GUI implementation to figure out how to extend it to add keyboard navigation.
+It will also be necessary to study pre-existing approaches to making SVG
+diagrams accessible and study the current state of HTML5 tools that facilitate
+this.
+
+Languages: Javascript, HTML, CSS. Some basic C knowledge may be required to
+send a richer set of data about each object from the core to the GUI. However,
+there is already an interface that can do this-- it just needs to be hooked
+into the GUI.
+
+Purr Data Message and DSP Profiler
+----------------------------------
+
+Goal: measure the time it takes for each object in a Purr Data diagram to
+process its data and display the results in the diagram.
+
+Details: Purr Data users would benefit greatly from the ability to profile
+their programs while they are running. This is easy to do for the program
+as a whole, but challenging to do per-object.
+
+A successful implementation of this feature will give an accurate measure
+of the time it takes each object to process its incoming data. This needs to
+support all of Purr Data's platforms: Windows, OSX, and GNU/Linux.
+
+A successful implementation will also be performant enough that the
+measurements themselves don't impact the realtime operation of Purr Data
+itself.
+
+A now defunct fork of Pure Data called ["DesireData"](http://artengine.ca/desiredata/)
+did an initial
+implementation of this idea using the x86 RDTSC instruction. (Though its
+unlikely this feature was actually stable at the time DesireData was
+in active development.) Though this instruction is no longer considered
+reliable on modern machines, the overall approach taken by DesireData of
+adding a field to the t_gobj struct for storing this timing data is
+probably a sound starting point.
+
+Bonus goal: Figure out a way to meaningfully profile DSP objects. DSP objects
+typically process data at a high sample rate (44,100 is common) so displaying
+the data in a user-friendly and meaningful way is tricky.
+
+Difficulty: Moderate to Hard. This feature touches the main artery of the
+message dispatching system, and the bonus goal would touch the main DSP
+routine. In both cases realtime scheduling deadlines must be taken into
+account by careful profiling.
+
+Languages: C for the profiling business logic, HTML5 for displaying the
+results in the GUI.