Is this a reversion? patch-nodes/x should change “-” to “_” during code generation.
xod-client 0.16.0
Yep, thanks for pointing. Terminal labels are not processed, nor restricted in any way.
We plan to restrict the pin labels to “no more than 4 alphanumeric characters”. That will “solve” the problem mentioned and guarantee always-beautiful label layout.
We could allow more chars (e.g. the hyphen/minus) and escape them, but it looks like an incomplete solution: if minus is allowed, why division, greek omega, emoji poo are not? Perhaps, custom labels are desired, but to avoid C++ interchange ambiguity they should be implemented using another, orthogonal mechanism.
Is it OK?
I would be sad to be restricted to 4 characters. Indeed, full unicode! Well, except for a programming language from … a long time ago.
Don’t want to upset you or anyone but let’s face it: there are some technical restrictions on the pin labels:
The first restriction limits us in maximal length (width) of pin labels. The current layout made to show WWWW as the widest label. Anything wider would collide and interfere visually.
The second restriction limits us in character set. input_
⅀ is not a valid C++ identifier.
The proposed “Four ASCII char max” rule will satisfy both restrictions. Similar convention has been used for ages in datasheets to label IC pins: GND, Vcc, IN1, OUT3, EN, SCK, MISO, SDA, etc. Once you get them, they are not so ugly. They even have a charm.
However, I agree it’s much more natural if we could have arbitrary labels, the same we use in Internet every day.
A rough idea I have is to add an alternative label attribute to the pins which places no restrictions.
So, C++ always use main label. And the patch board shows… what does it show?… that depends on label length… not elegant.
Or maybe we should limit the length to four characters but allow unicode and present it to C++ as input_u2018_u2019.
I have no clear and smart solution to the problem. I’m open to hear your thoughts.
I’ve noticed the label/layout problem. I’ve used a few other graph-based tools, like Grasshopper, and Antimony. They chose left-to-right layout for the graph, and top-to-bottom for nodes. Antimony encourages words for “pin” labels, whereas grasshopper encourages single letters (and is un-apologetically idiosyncratic). Nodered doesn’t even label the pins. Personally, I find longer pin-labels a better idea, for the same reason long(er) argument names are better: more semantic expression. The pin-edge (top/bottom vs left/right) and the “natural” graph layout (flow down, or flow right) seems an unresolved design issue in the graph/flow-based world. The latin’ish alphabet world would seem to have a preference for graph flow to the right. Right-to-left scripts would like the opposite(?). And several ideographic scripts like top-to-bottom (and right-to-left).
How important is the readability of the generated code? Debugging becomes more difficult as the c++ names diverges from the display-name, but I think the advantages for the XOD user outweigh that sufficiently. Your idea, like display: "⅀", name: "input_u2018_u2019", is intriguing (some unicode is permitted [1][2] in c++ names). I would strongly support the idea of insulating the visual-graph from the limitations of generated code (e.g. the displayed label is full unicode). My midi-note node should obviously be named ♫.
I think this also relates to my desire for a library-patch-name being a “display” name, and not equal to the file-path.
…For some value of charm. But, for usability, I’m strongly against the limit of 4 characters. For patches, and less hardware-related things, I think the 4 char label is not so good. Since I’m working on MIDI at the moment, I’ll give the example: ControlChange(channel, control_number, control_value) . All references use those terms.
So, I promote the idea that labels/names should be easy to understand and carry useful information: exactly what we strive to do in our own code. I think this is even more important for casual-users and non-programmers.
Thanks for being constructive.
One of the biggest points in visual programming critique is very low “code” density. In a horizontal graph layout which Antimony and other products employ, much space is wasted because they have to allocate an equal width for all labels regardless of their actual text width. I mean, if a node has inputs “x0” and “a very long thing”, the x0 has to have a big tail of white space. The density problem is notable in their title screencast. For Antimony it could be a no problem, but in XOD I often work with much more nodes on a patch.
We actually considered many flow variants for XOD with our UI designer. That was a hard choice, and I’m sure it is optimal. There is a problem with pin labels. But I hope it has an elegant compromise solution which does not involve fundamental rework. I want to find that solution with the help of you and community.
Explicit is better than implicit, agree. One additional thought: if one is not familiar with the problem (node) domain, full labels won’t help. E.g. if someone doesn’t know what the MIDI is, control_value and VAL both make no sense to him.
Good point. Agree.
I like it. It is compact 
I think supporting full Unicode is not a big deal. The problems start when the labels are long.
It could be potentially solved by introducing “display names” for patches. E.g. the xod/core/multiply could define “×” or even “${X} × ${Y}” as its display name to have it rendered as “× 100” where 100 is the value bound to Y.
I see some parallels here. Can we use the same mechanism for labels?!
I often see “short labels” on consoles of professional and soho equipment. On synthesizers, for example. VOL, PWR, PROG, AUX… all these are abbrevs. Do they really make interaction harder? Or is it not a problem because these letter combinations are widespread in a given domain/context?
In the current layout, I wonder which is better:
Maybe you have an idea how to keep the labels long and allow them not to overlap?
The only idea I have is some kind of tooltips that would show the full name (and a bound value) on pin hover, but in the regular mode, they are kept short. Do you think it could work?
Good point.
Well, dox suggested a change to short names (now in awgrover/midi)! He’s more familiar with the MIDI world.
Nope! Vertical stacking gives more room, but is that the best for graph-style programming? We just have to try variations till we get it right, I guess.
Seems promising. I think rhino/grasshopper does something like that (their labels are very terse!).
Thanks for the constructive discussion.