Are we far off from being able to debug Ember Magma flows?
The error flagging is hooked up already in our internal build - highlighting the error node, reporting the cause for the error, even turning the respective button for Initial or Simulation flow red so you know which flow caused the problem even if the editors are not open. But the Debugger is not ready yet. Obviously it is on the ToDo list.
Nice, looking forward to it! It’s always easier to know what you are doing if you see what values goes in and goes out of each node. Ever thought of implementing the Naiad way of putting a little circle on the lines between the nodes showing what values are transferred across?
Actually I started working on something like that lat night 
Not little circles (which PFlow Box 3 also uses), but I will color-code the wires based on the value type passing through them, and will add a letter next to the socket, like [F],[I],[V],[Q] etc.
This was partially possible in the old Magma 1,x, but not through the whole flow, just from input nodes. The MAXScript code for determining the type was very slow though, so I disabled it in Magma 2. Now I am rewriting it from scratch, and we might move a part from it to the core in the future, but for now I will try to do it purely in MAXScript as a Proof Of Concept.
Sounds very cool! 
We are nearing the end of Fumes latest beta cycle I want to get back to Ember!
Nice! Are you saying that you will just label it or that you will also put the value that’s being transferred between the nodes? IMO it would be much quicker than going through the debugger.
I am prototyping it in Genome where the Debugger still works. When you launch the Debugger and select a line in Genome or Krakatoa, that line’s values show up at the sockets so you can see how the data is flowing. Not sure if that’s an obvious feature, but it has been around since Magma 2 first appeared last year.
Once we get a Debugger in Ember, we will probably reuse the same code.
So what I am adding right now is a type display that is propagated based on the connected nodes, not on the evaluated flow. So even if the flow cannot be evaluated due to an error, you still get the value types on the nodes and will have much easier time figuring out what went wrong. Later on we hope to be able to provide better internal knowledge what types are expected at each socket and potentially allow the automatic fixing of a flow by inserting conversion nodes (but not automatically without asking like in Box #3, I hate that).
[attachment=1]GNM_ValueTypeDisplayPrototype_v001.png[/attachment]
[attachment=0]GNM_ValueTypeDisplayPrototype_Debug_v002.png[/attachment]
Could it be assumed that you will use the same color scheme as box#3? 
IE purple for ints
pink for vectors
yellow for quats ect,ect,
no, no, no, it’s Indigo for Ints, Violet for Vectors, and um… There’s not a lot of “Q” colors, are there?
EDIT: But seeing as Bobo is making this, I bet the colors will be user defined swatches.
Lol, unless quartz is a color
Too true always two steps behind I am 
And I should know better by now!
The colors ARE customizable (and have been since Magma 1.0). I just skipped them in Magma 2 and used dark blue for all wires, but they are still in the Customize dialog of the Magma 2 editor.
In fact, I tweaked them just before I took the screenshot - I have not decided on the exact colors yet because I have to test them with both bright and dark UI.
Remember, this is Proof Of Concept.
How come the inputs aren’t color coordinated? Am I missing something technical or has it just not been implemented yet? From my still limited knowledge of Magma it would be nice to see just by color what kind of value the input accepts.
The debugging looks great from the screenshot, it’s completely different from what I’m used to but it’s clear and works! I am not sure what you meant by that you selected a line, as all values are displayed not just the values on the nodes between a connected line. Is this again something I am missing that I don’t know about Magma yet?
Anyways, can’t wait to get debugging in Ember .
The answer is that we don’t know what is expected. Well, the node knows internally, but does not expose this info to the MAXScript-implemented MagmaFlow Editor yet. Also in some cases, an operator like a Noise function can accept either a Vector or a Float. We will have to figure out how to represent this… The day this info is exposed in a good way, I will color code both inputs and outputs. In the prototype (which I disabled today until I have more time to work on in the near future), I had to hard-code the logic about what a node produces based on MY knowledge of what each node passes along and how that changes as it passes through the operators. But we don’t want to hard-code such stuff in the UI, we want the underlying core to provide that info. So when we move the same core into Maya on Linux, whatever UI would run on top of that would produce the SAME result without having to recode the UI to do so…
In Genome and Krakatoa, you go to the Debug menu and select Debug Mode. This opens a Debug window with a ListView showing the first N records with ALL operators these values pass through. When you highlight a LINE of this ListView, the values of that line show up at the sockets. If you select a different particle, vertex, face or whatever a line represents in the current modifier, the respective values show up at the sockets. If you close the Debug window, the sockets return to the regular names…
Ok, that clears it up. Thank you.