The 3Dgraph panel is where subtrees are displayed and manipulated. Each node displayed represents a section A||B and the paths connecting them to their parent can be toggled off and on. The larger sphere for each node represents the gap (G = B-A) and the two smaller spheres represnt A and B.
How a subtree is colored depends on an initial offset for hue, chroma and value (hsv) and the coloring scheme chosen. The color assigned to a node is that of the first node in the list returned when there are nodes with equivalent A||B's that occupy the same spatial coordinates (there is a cycle). The color assigned to different nodes with equivalent A||B's need not be the same and depends on the coloring scheme in effect. Though for the schemes tried so far this is the case, it is easy to envision one where it's not. In that event, the colors of the other nodes can be examined in the pick window when the node(s) is selected. The frequencies of the notes that derive from nodes sharing the same spatial coordinates are, however, always the same and a case where they arent hasnt been seriously considered.
Each node (or set of nodes with equivalent A||B's) can be clicked on and played using one, two or all three of the frequencies it represents (A, B, G). The duration and instrument used are set in the composition panel. When a node is played it is also selected and its information displayed (nodeid,parentid,A||B) in the picked window. The entire tree or the current node selected in the picked window can be sent to a composition panel where there is a staff for each of the three voices a node(s) can represent. Trees used by a composition must be saved in the database before the composition can be since they must be retrieved when it is.
The 3D graph of a tree can be re-displayed at any time using different mapping functions that map A,B and G to x,y, and z. The ability to view data differently can be useful in bringing different patterns to light so that they can be used as possible riffs or themes when transfered to the composition panel. Some of the mappings used are listed with the images below and all implemented so far map nodes with identical A||B's to the same spatial coordinates. This, however, need not be the case and a mapping that considers other factors such as how a node was generated would have the advantage of visually seperating nodes with the same A||B.
Search: @d4$1
Mapping: x = 10×sin(A), y = 10×*cos(B), z = tan(G)
This is the mapping used by default.
The following screenshots depict the same tree of justly intoned ratios rotated and remapped to different sets of spatial coordinates.
Database: template = 0010100100000000 x 498; juststop = true; starting_section = 1/360×Φ11 || 1/360×Φ12.
Search: @d400%1:1:0:1 + @d400%16:15:0:1 + @d400%9:8:0:1 + ... etc.
Mapping: x = 10×sin(A), y = 10×cos(B), z = tan(G)
The above graph rotated.
Mapping: x = 10×sin(A), y = 10×sin(B), z = tanh(G)
Mapping: x = 10×sin(A), y = 10×sin(B), z = tanh(G)
Mapping: x = (G + 10)×sin(B)×cos(A), y = (G + 10)×sin(B)×sin(A), z = (G + 10)×cos(B)