Commit 823bc0cc authored by Jonathan Wilkes's avatar Jonathan Wilkes
Browse files

add two additional ideas submitted by Purr Data users

parent 0203b03c
......@@ -153,3 +153,91 @@ like netsend, netreceive, etc.)
* Possibility to vectorize DSP algos using SIMD. Also more crude experiments
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).
ASCII art to Purr Data diagram conversion
Goal: make a GUI interface where the user can either type or paste in
ASCII art for a Purr Data diagram and have it converted to a floating selection
in the current Purr Data diagram.
Details: Often Purr Data users rely on ASCII art in forums, mailing lists
and other documentation to give examples of Purr Data programs. This is
convenient because it's quicker than taking a screenshot of the Purr Data
GUI and takes up less space, too.
The ability for the user to type ASCII art into an object box and get a new
selection of a Purr Data object chain would be useful. This would let users
paste ASCII art from the mailing list directly into the interface. It would
also make it easier to create Purr Data diagrams using only the keyboard.
Bonus Goal: make it possible to convert a subset of Purr Data diagrams into
ASCII art.
Bonus Goal Details: Unfortunately Purr Data allows arbitrary positioning
of objects on an integer-based x/y axis. Thus, not all Purr Data diagrams
can be represented as ASCII art.
The bonus goal would add a feature to check if the currently selected Purr
Data diagram is able to be represented using only ASCII art. This could be
either a) a button that does an analysis, or b) realtime feedback to let the
user know when they have positioned an object or connection in such a way
that makes ASCII art impossible.
This is a non-trivial problem. For example, one could add a button to Purr
Data that would constrain object positioning to a predefined grid. Then one
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.
Navigation of "Wireless" Objects
Goal: make it possible for the user to navigate among all extant wireless
objects that are bound to a particular symbol.
Details: Purr Data diagrams typically consist of objects-- English words in
boxes-- connected by Bezier curves. In a complex diagram, however, the
Bezier curves can end up obscuring the flow of the data in the diagram. For
these instances, "wireless" objects like `[send]` and `[receive]` may be
used to send data from one object to another without making an explicit
However, such "nonlocal" connections can quickly make diagrams difficult to
maintain. It would be helpful if the user could query a particular "wireless"
object to find out how many other objects it communicates with.
Internally, all related "wireless" objects are bound to the same immutable
symbol. This makes it easy to find all related objects for a given symbol.
Probably the easiest UI for this would be a button to query all related
connections. Once Purr Data's engine finishes the search, it can send back
the ids of all the objects it found. Finally, the gui can just print a list
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).
Terminal REPL
Goal: make a little REPL interface with which the user can interact with
Purr Data programs and program state.
Details: Purr Data is being used in situations where the hardware is an embedded
device. While the current GUI runs on most common hardware including the RPI,
there are situations where it would be more convenient to simply interact using
a text interface (locally or over ssh).
The user can already communicate with Purr Data's audio engine over a socket
connection. So the "read" and "evaluate" part already exists. However, Purr
Data does not print a response nor loop in this situation.
Additionally, the UX of sending raw messages to Purr Data's interpreter is
quite lacking. The syntax for creating new environments and objects was not
meant to be used directly. Objects are referenced by index number, and the
diagrams themselves must be referenced using hex identifiers.
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.)
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