Oh wait, you actually can use a Panel to stream textual data and a Read File component. That at least would be real-time, but it only works for textual data.
The Rhino Python sticky dictionary is shared across all GHPython instances and the editpythonscript editor within the same Rhino session, enabling one to send any data type between multiple Grasshopper canvases (and Rhino).
1 Like
I saw Mateusz ran several definitions at CITA in the background. I think it was something with the bendy wall project.
Do you know what was the workflow behind?
Yup.
Since this is something I was planning anyway for GH2, I wrote a very simplistic implementation using standard components for GH1 in Rhino 6.0
(ignore the audio, didn’t realise the screen capture software was also recording Harmontown that was playing on my other screen).
7 Likes
Cool!
But that wouldn’t work in GH 0.9?
// Rolf
I’m not even supposed to be messing with Rhino 6.0 for non-critical stuff, let alone Rhino5.
2 Likes
What would be the benefit of such workflow or reasons to use it?
Does it result in faster execution time or it would be more ‘clearer’ to read the gh definition??
Let me give you and example:
I work a lot with very “dirty” meshes. They need some very heavy processing for cleaning them up before I can start doing my atual analyse of the. If the GH definition is to recalculate starting from this cleaning process, every change (like iterative form finding) would take forever. I can’t even have the Cleaning Definition opened because it slows everything else down. For other steps in the process I have different definitions for different meshes (depending on quality), so therefore it makes sense to modularize the definition for only those steps that need variants. And so on. But at times several such steps must be active at the same time in a long process chain (due to user interaction, one can not save part-results temporarily only to open next definition, and so on, it must be one responsive chain of definitions).
Although there may be alternative solutions, like DataDams, and logical “process paths”, too big definitions isn’t easy to maintain. Definitions should be like components (chained into networks), only on a higher level.
// Rolf
1 Like
In addition to @RIL’s example, here’s what I imagine this is useful for:
- You can split up large files into consecutive smaller files. Making each file more readable, more re-usable, and more debuggable.
- You can store various states of data to work on, and switch between them either through the GH UI or using the file viewer in your OS. You might just want different states, or you may want heavily reduced versions of the same states so that you can work on a small part of the logic and only switch to the full-blown-it-takes-20-minutes-to-compute finished model at the very end.
- It allows you to work together with other team members more easily. Person A is in charge of facade shapes, person B is doing the rationalisation, person C is populating facade elements, person D is all about creating shop drawings, machining instructions and material bills, each working in their own gh files but sharing data.
There are other reasons, but these I think are the most important.
Eventually for a proper implementation I’m imagining that both cluster hooks and these data exchanges are the same sort of object. It has to work both to and from separate *ghdata files, and also directly into other *.gh files, and of course across cluster boundaries.
9 Likes
I’ve been asking something like this before on the old forum. There is some definition which should be defined step by step, and it is perfect to have a way to do this spending time for the calculating only current step.
Thank you, it is good long waited component 
I use Geometry Cache now the most problem with it is that you have to find the one to reload in a quite a big definition and then another one etc. Adding to it boolean parameter entrance would be not bad.
Lately our files in the office have become bigger in size and harder to handle (even for a powerful iMac). Something like this would bring so much benefit to the whole workflow! Can’t wait to see it happen!
Thanks
I forgot to point out that we work in OSX environment, so no R6 for us yet. But i’m positive that improvements and compatibility will surely come soon.
Thanks for the heads up though, we might try to find a windows pc and give it a go! 
Isn’t this what elefront plug in does? I think it enabled something similar to this functionality.
Edit: Nvm, its not exactly what you are looking for.
Haven’t tested it extensively, but for simultaneously open grasshopper files, it looks like Link might be it?
http://www.hksinc.com/hksline/2015/01/19/linking-grasshopper-files/
David,
I am finding the Data Input/Output quite a useful addition. Thanks for that.
I am wondering if it would be possible to implement it, such as that the file path input and output can be set by using a path string as supposed to manually doing it by right clicking the component itself.
Can yes, but as always the question is what should happen if more than one file path is provided.
This is such a common problem that a consistent answer really is needed eventually. So many properties of things could be exposed as inputs, but would either not work or be undefined or convoluted if two or more inputs are provided. Slider and Graph mapper ranges have the exact same problem.
Well,
we could start by allow only one path for the time being. And if users come up with various needs we could address them in a more systematic way.
In my case, the use of Data Input and Data Output is an attempt to break my large definition into usable chunks, and reuse them in other projects as needed. A sort of “seed” file definition.
One other suggestion is to have the Data Output create automatically the file in the same folder where the gh definition is located and allow the Data Input to have string path input.
2 Likes