Talon™ is an augmented/virtual reality development visualization tool.
    Patent Pending.


    Talon™ is an augmented/virtual reality development visualization tool.
    Patent Pending.



Talon Code Mapper™ is a utility that reads software code, learns how it works and shows the developer a 3D rendering of what they created.

It also solves problems of technological debt; like when software was written by a programmer that no longer is around.

Most companies lose programmers and can take ten people an entire year to find the errors on code, and fix it. This software shows those errors in minutes and allows the programming team to fix them.


Chilton Webb

Chilton Webb is a prolific freelance hardware and software developer, instructor, and author, specializing in custom end-to-end solutions for companies around the world. He has created and brought to market nearly a thousand commercial products, articles, training materials, and patents over the last 25 years.

Bridget Black

Bridget has 17+ years of experience in the I.T. Solutions industry. Bridget has been responsible for the strategic leadership, business development, strategic alliances, and daily operations of numerous I.T. related enterprises.

Carlos Chacón

Carlos Chacón is an I.T. entrepreneur with over 40 years experience in startups. He founded and owned one of the Hispanic Business Fortune 500 IT Companies in the U.S. Carlos served as an advisor to the Texas Secretary of State for the World Congress in Information Technology. Twice nominated for Entrepreneur of the Year by Hispanic Business Magazine.

Holly Law

Holly Law is an experienced multi-million dollar producer for the pharmaceutical industry. She brings three decades of sales and marketing experience along with an established track record for other startups.

[Figure 1] [Figure 2] F[Figure 3] [Figure 4]


A method for observing and displaying computer source code and finding bugs in 3 dimensions having the ability to parse, analyze, and display the logical structure of source code written in various languages, in three-dimensional space. This would allow users to find bugs faster and see how source code works, for both education and to inspection. This requires two parts, a parser and a display engine, and the two can be separate products. The dual nature of this system would allow a company to parse data locally without worry that a third party has access to their data, and then display it on many different platforms, such as a computer screen or a VR headset. The structure of source code can be displayed on a flat plane either vertically or horizontally, so that it appears as a giant 2-dimensional map, or as a sphere, with interconnected nodes, or a cityscape, with various buildings representing different concepts as the user requires.


Nodes represent methods, functions, or any encapsulated logical construct. These can be spheres or cubes, or some custom shape. They should be uniform and similar in appearance. Connections represent any line of communication between functions. These can be lines or dotted lines. Variables represent any form of data storage, temporary or permanent. These can be additional flags or symbols on nodes or connections. Namespaces and classes represent encapsulation of functions and variables into artificial objects as commonly seen in object based programming. These can be shapes or colors in addition to the other display elements. Files represent the source code objects as the user interacts with them via the operating system. Directories represent the common artificial encapsulation of files used in modern operating systems. Ground Plane represents the base for most of the 2-dimensional map. Vertical refers to a right angle away from the plane, creating a third dimension. It can be positive or negative, creating the illusion of trees growing up or vines hanging down, depending on the orientation of the ground plane to the user. A proximity based bug is one where data inside safe boundaries changes incorrectly, but does not pass the safe boundaries. A buffer overflow bug is one where data oversteps the area of memory it was originally allotted to.


There exists no current method of visually inspecting large amounts of source code except to read the source code. This requires that the user be familiar with the language, the coding style, and the overall design philosophy behind any given project, which is unreasonable in any small-time frame. Furthermore, there exists no current method of inspecting one's own code to find bugs that the user created, other than to look at the source code itself, or use tools that help the user search their own code. This reliance on using the same method to find a bug that you used to create the bug is arguably the heart of most programming bugs.

Methods and Variations

[Figure 1] The basic concept is that a map can be created by a computer by first reading all the user's source code, creating a simplified variation of it, and then displaying that variation in 3D space such that the representation appears to be a map. This lets the user take advantage of their visual ability to navigate maps, which is much faster than reading code. Lines on this map connect nodes. The entirety of a program could be displayed and viewed in this matter at a glance and the user can zoom further into areas of interest. Clicking on nodes would bring up an information dialog for that node, which links it to the source code itself and provides additional information.

[Figure 2] In the first incarnation, the lines represent connections between functions. Circles represent functions. All functions are first displayed as a grid. From each point, the logical flow of the source code is displayed with a vertical climb for each successive step through the source code. Using this simple base, the logical flow from any one point in code to another (if such a pathway exists) can be viewed directly, and complexity can easily be seen by looking for the visibly tallest structures. A single function and all subsequent functions connected from it can be displayed, or all of them at the same time. In a second incarnation, lines represent connections between objects. Due to the interoperability of objects in an objective language, there would only be one instance of each object on the ground plane, with lines criss crossing each other between objects, arcing over the tops of other objects.

[Figure 3] In one variation, a user might want to view this type of inherently complicated interconnectedness as a sphere with all nodes equidistant, such that all connections exist inside the sphere or around its perimeter. In a third incarnation, a single function is displayed in the center of the ground plane, and serves as the base, with all subsequent functions displayed represent pathways to that function, spreading outwards away from the center. This allows the user to instantly see all functions that access or could potentially modify the function. In another incarnation, a single variable could be monitored in a similar fashion, showing every node that connects to it, and every node that connects to those, expanding outwards from the center of the map. In a fourth incarnation, two sets of ground planes are visible, with similar groups of functions. This would allow the user to visually compare two sets of functions for similarities. Uses might include forensic software analysis for legal disputes and efficiency comparisons. In a fifth incarnation, one ground plane is visible, with one group of functions overlaying it. Color coding allows the user to see changes to the code between two source code repository check-ins. Some nodes and links are red indicating that they were removed, some are yellow indicating they were changed, and some were green indicating they are new. Additional colors might be used to indicate additional features of the check-in system including "conflicts" and "blames". In another incarnation, all areas of source code are gray, and a slider allows the user to monitor a logical 'path'. As the slider is moved, the logical path from one node to another becomes red, with red connections between them. This would let the user monitor an app's behavior visually. These nodes could be illuminated based on an external connection, pipe, or file, so the user could either monitor the app in real time or play it back later. In the event the user needed to play back a recording of the logic, additional code could be inserted into the source code that would log function calls serially. This would allow the user to then view those changes by loading that log file. The original source code would not be necessary in this case. In another incarnation, the user might use this to view the interaction between two different languages, two different instances of the same program, two different products, or client / server combination. two ground planes would be visible, with source code displayed as illustrated above, with the additional change that some nodes from one ground plane could connect to nodes on the other ground plane, indicating communication. In this way, a user could see the way a server communicates with a client, or a database communicates with a server. It could also be used to bridge the gap between two different languages. Lines in this case between the two sets of source code would be displayed in a different color so they can be readily seen by the user. Additionally, the program could analyze the source code and highlight things the user might not realize existed, such as recursion and destroying objects before they are used. These kinds of issues could be highlighted in a different color, so the user can readily identify them. Additionally, the third dimension can be used to display flags and structures indicating file ownership, classes, namespaces, and other contextual information. The size of these structures could scale such that more complicated nodes would be displayed as larger structures. These structures can be in the form of organic tree-like paths, or even large blocks.

[Figure 4]Memory visualization could use the same grid concept, with blocks of data being displayed visually in three dimensions. File dumps of the memory used by a program at the time could be viewed in 3D, and a cache of changes could be used to quickly scrub back and forth through time, letting the user see how changes to memory are occurring. Blocks of memory could be color coded based on how long ago they were read from or written to, letting the user visually see many changes to memory very quickly. Boundaries between variables would be displayed as black areas, letting the user instantly identify buffer overflow bugs and other similar problems like proximity based bugs. To facilitate the above visualization quickly, source code would be parsed ahead of time and stored in an associative array, database, or a form of meta-code, with weighting being done in a final step. In this way, the initial construction of a node map can be performed and cached, and updates to the node map data can be relatively quick. Weighting is done as a final step after changes to the node map are complete, so the display of the data requires no additional weighting computation.

A meta language with the above constraints could be formed like this: ( , ...weight... ) In this manner, the ability to store and analyze this meta data could be done easily via any text editor, with additional details per unique code name stored in other files. This would allow the system to quickly process and update just the weights and displays. Navigation of this map would follow human interaction rules, with clicking on an area allows the user to pull the entire area around, and view it in three dimensions. A virtual or augmented reality version of this could be created that would allow the user to step into the ground plane, or see it displayed before them in 3D. This could be used to quickly teach someone or facilitate learning how existing code worked, without additional information from the original programmer. This could also serve as a secondary means of viewing and interacting with source code as you create it, allowing you to visually see the changes in real time, and allowing you to visually see how your code interacts with other code. This would let novice to experienced programmers more quickly find bugs and logical errors in their code.



Includes, data reading and loading, Up to 500,000 lines of code.
Additional hours of phone support are billed at $350.00/hr.
PRICE: $10,000.00


For clients who wish to continue to render 3D mappings after their initial audit.


For developers and programmers.


Lead Developer (Offsite).

Prices is US Dollars. Audits require 50% down. Prices subject to change. Please make checks or payment to TALON CODE MAPPER™.

Contact Us


209 Camperdown Elm Dr Austin, TX 78748