Why not provide a ref node
Hi, everyone,
I use NodeBox to create circuit diagram just for fun. I usually create a subnetwork as a circuit component. If I want to place more than one component, I have to copy the subnetwork node. I treat the subnetwork node as a template. The problem is that when I change the original subnetwork node, the copied nodes would not be changed at the same time.
If NodeBox provides a ref node, it would be better.
Thanks for your reading.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by john on 04 Jan, 2021 08:44 AM
Hi fybh6464,
See my answer to your other question before reading this one.
For your project I think it may be possible to create a kind of "ref node" for the templates you need.
For each type of component define a template object - a subcomponent containing a group of shapes and possibly other information. This template would not appear on your circuit board, but would be referenced by each individual instance of that type of component.
As a simple example, you could represent the template of "NOR" chip as a large rectangle of a certain size with multiple smaller squares positioned along its edge to represent the various inputs and output. The final rendered node of the NOR subnetwork should be a group node so that whole thing reads as a single object. Just leave it centered; templates do not have positions.
Then, for each instance of a NOR chip in your circuit board, make a subnetwork with a position port, a number port to hold its ID, and a null node port to hold its template definition. You would then tie your NOR template node to the template port of each NOR chip instance. The instance subnetwork could simply output a zipmap of all these properties (with the template input translated using the given position). Your drawing code would then lookup the shapes inside each instance to draw them.
A cleaner way of doing this would be to build a template table. Each row would contain a label identifying the template type, columns for additional values associated with that type, and the grouped set of paths defining its shape. Then, instead of tying the template to each instance, you would tie in a link to the template table along with the type ID. The instance subnetwork could then lookup the correct row in the template table and pull out all the information it would need to render that type of chip in a given location.
With this system in place, any change you make to your template table will be automatically included in each instance on your circuit board.
One aspect of this is that you need to draw a physical link between the node representing your template table and every single instance present in your circuit board. If you have many chips on your board this means the corresponding Nodebox network will have a big tangle of links. I can understand your wish for a way to have each instance absorb its template definition without an actual link; this may be what you really meant by a "ref node".
The thing is: this absence of a ref node is actually a feature, not a bug. Nodebox has no concept of state, and no concept of global variables by design. Although inconvenient in cases like this, the lack of state makes debugging MUCH easier.
In languages which allow global variables, any change to those variable ripples across all the code in unseen ways, with secondary ripple effects which go even farther. This often causes unintended consequences which can be devilishly hard to track down. As code becomes more complex, this problem becomes ever thornier, leading to much tears and midnight hair-pulling.
This cannot happen in Nodebox. You can see every connection. If you change the definition of a subnetwork you already know exactly which downstream nodes will be affected. And if anything downstream does go awry, you can follow it upstream, rendering as you go to reconstruct exactly what is happening.
It takes some experience to fully appreciate how valuable this is. After a long career of coding I switched to NodeBox partially for this very reason, and have never looked back. There is a tradeoff, but for me it's a good one.
That said, you can get around this limitation by stepping outside of NodeBox in a simple way: by storing your definition tables as external CSV files. In my example you could enter your template definition table into Excel and save it out as a CSV. Then, instead of including a template table link for each instance, the instance subnetwork could use an import_csv node to read directly from that external table. Problem solved.
[In this case, since CSVs cannot really hold Nodebox shapes directly, you would have to abstract out the basic features of your chip shapes - e.g. rect width and height - and use those values to represent the shapes. The instance nodes would then reconstruct those shapes using the supplied values. This could be feasible if all your chip shapes are fairly simple. If not, you could still use the CSV to hold the non-shape aspects of a template definition.]
It's true that not everything you want to do can be captured in a CSV file. If you need to make a basic change to, say, the way your instance nodes function then you are screwed. You will have to make your change to one node and replace all the other copies. This can be painful, but it's part of the price you pay for having a stateless language.
Not everyone agrees this tradeoff is worthwhile. Even the creators of Nodebox did allow ref nodes as part of their experimental "Nodebox Live" version for the web. That project is still in beta and has been stalled for quite some time; I don't find it usable.
Please let me know if this makes sense and if you need any other help with your project. I think it's a really interesting project and would be glad to offer additional help if you want it.
John
2 Posted by ahuman on 04 Jan, 2021 12:37 PM
Hi Jhon,
I read this reply of yours twice either. What you sugguested is useful, I think. Actually I had thought of using the table node. The table node is one option. But what you talk about the way to implement the template impressed me. You said the template node's output needn't contain the position property. I think: yes, it is.
I need more time to think about what you replied.
Thanks, Jhon!
Fybh6464.
3 Posted by ahuman on 04 Jan, 2021 01:00 PM
Hi Jhon,
Actually, I've collected more than one hundred node-based software. Most of them serves for the electronic music, and some of them are game plugins. I like elecronic music, but I want a generic node-based editor.
The first time I try to find node-based software is after I found a 3D builder software called Houdini which has a so called procedural modeling feature. Then I found Puredata, Vvvv, Fugio, and son on. But the other node-based software are a little complicated. NodeBox is easy to use and it can produce vector graph. It's great.
I used to use Adobe illustrator and inkscape to make vector graph, but I found that it is not easy for me positioning the geometry objects exactly. I can code, but it is more comlicated.
Fybh6464.
Support Staff 4 Posted by john on 04 Jan, 2021 10:42 PM
fybh6464,
Yes. There are many node-based tools out there, like Houdini, that are more powerful than Nodebox, but also more complicated. The thing I value about Nodebox is its simplicity.
That simplicity does create constraints which make some things harder to do. But I find that constraints can boost the creative process. It's fun finding ways to get Nodebox to do what I want it to.
ahuman closed this discussion on 05 Jan, 2021 07:28 AM.