Complex definitions can quickly become a mess of wires. Using the wireless options on inputs can obfuscate connections and is pretty inflexible if you want to swap out components. Furthermore, everyone has experienced the pain of trying to connect two components that are very far away from each other on the canvas. Let's be honest -- it's not great.
NBBJ digital presents: Telepathy
Marc Syp // Concept + Prototype
Andrew Heumann // Rockstar Production Coder
Telepathy is a wireless sender/receiver that allows you to send Grasshopper data to anywhere on the canvas using a simple key naming interface. Connections are created automatically based on the key name, and multiple senders can pipe data into a single key channel. Multiple receivers can collect data from all senders, and wildcards are also possible.
With Telepathy, you can access any of your data simply by selecting the appropriate Key or simply naming the receiver appropriately. It is also useful for collaboration. Recently we used it at the AEC Tech 2017 hackathon to allow multiple people to work on separate parts of a definition. Because we defined a consistent naming convention, we were able to have one person manage the master GH definition and drop in contributors' code, et voila! It all wires up automatically, and updates are performed easily with window select, delete, and paste.
Take a look at the video for a demo of how it works!
At NBBJ in 2015, one of my most pressing interests was to develop infrastructure that supported internal product deployment and good code hygiene and modularity. Andrew was building the early guts of HumanUI at that time, and I was building a cloud analytics plugin (still proprietary) that would eventually track all of our Rhino + Grasshopper usage across our firm.
One of the goals on the tool-maker side of the equation was to reduce the complexity of access to data in a visual programming environment (specifically Grasshopper), by providing a UX that simulated the way that a textual environment uses scoped variables. The first version of the concept for Telepathy was called Sonar, and it was one of my first serious attempts at a C# Grasshopper plugin that would actually be useful. It was a complex mess of code that was doing all kinds of gymnastics to push/pull entire data trees from component inputs/outputs, which meant managing lists of trees, merging, splitting, and handling complex component expiration scenarios.
Stumbling on some difficult data management and flow control issues, I turned early and often to Andrew, who has basically taught me everything I know about C#. He kindly and patiently helped me for a few days with my existing codebase -- but then had the brilliant idea to change the implementation paradigm to inherit from the generic parameter component and use wireless connections. This has the added benefits of allowing users to visualize existing connections, navigate the graph using standard GH UI paradigms, and leverage the built-in flowcontrol mechanisms of Grasshopper. He rewrote it from scratch in an afternoon, it worked beautfiully, and Telepathy quickly became an indespensible element of our work.
We have added a number of new features to improve UX, and there are likely a few more to follow. That said, it has completely changed the way we build tools at NBBJ, allowing us to modularize for clean, readable code and even hot-swap entire HumanUI interfaces with different business, analysis, and visualization logic. We hope that you find it as useful as we do.