Commit 2271408b authored by Jonathan Wilkes's avatar Jonathan Wilkes
Browse files

add profiling and accessibility ideas

parent 18214a72
......@@ -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.
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