What is the best practice for debugging a patch that breaks on start-up while running on a different machine, considering that:
second machine has exactly the same installation and dependencies;
all patch files and respective links are in the same place;
I have a main patch that loses upstream connections to the main render window, even though there are no errors reported in TTY, and there are no red nodes or anything like that. Subpatches within it are working fine. Reconnecting links does not bring the main renderer back to life. All black.
Hello, try to have a look at the patches XML code - open the patch with a text editor - and then try to understand if there are broken links - which could be links coming from/pointing to no longer existing ID, and pointing to/coming from existing ID, for example.
Now, in case of broken links, TTY should report something, you’d say; I suggest you to start vvvv, on default 0.v4p patch generate a TTY renderer, and at this point run the patches showing these issues.
In brief you should have a TTY running before you open “broken” patches.
Or post them here; someone can have a look at them.
Thanks for the reply. Before I was going to do that, I started to strip down the sub-patches to only 1 and increment from there. This is producing results. It does look more and more like a patch migration issue, where some key node is losing its link?
So, more and more it seems like a project “packaging” issue, which has been a long-time request, from what I see of old posts (like here: https://discourse.vvvv.org/t/8430
Well, honestly never happened to me that patches working on a machine are broken on another - exception made for missing files, which is not your case, you say; and hardware issues.
Mainly because the entire Contribution mechanism would be failing a lot, which is not.
The issue shouldn’t be “a patch migration issue”, unless some mistakes have been done during this process.
I’m going to check for a 3rd time to be 100% sure, but I have reproduced both the file structure and the vvvv installation on both machines (Win 7, beta31.2 x86. There is a good deal of network communication, but I’ve also reproduced this perfectly (and I can see it’s working). So all that is different are the GPUs: I have K5000 on the development machine and K6000 on the production computer. According to specs, this shouldn’t be an issue either… But I agree it sounds unlikely.
So I’ve started a debug routine by stripping down my main patch down to one sub-patch only. Then it worked. Added a couple more to be sure. All working. I interrupted the process and went back to my initial version of the main patch: and it’s all working now… (?!!) So I’m more puzzled than before. Although on the surface it may seem like a case of someone very confused about their own project file structure, this is not the case. But like I said, I’ll check again. And post back results.
Take the .xml from the computer whick works, then drag and drop the .xml file into your root on the other machine.
Then you are running DX11, perhaps a difference between the 2 computers in terms of update … just a tought.
By the look of it (since quad got renamed), you open your patch with b31 update, but had it open with 31.2 (vvvv automatically rename from earlier to newer, but not the opposite).
Please note that for now I’m not accepting any naming change anymore on dx11, until we can have rename system per pack and not per vvvv version.
I believe consolidating vvvv version with the add-on pack solved the issue, but I’m not sure, because I tried many things. So, @vux was right, most likely.
But my question above remains: how does one go about debugging errors thrown by the TTY? I get things like:
00:00:47 ERR : System.NullReferenceException in VVVV.DX11.Nodes: Object reference not set to an instance of an object.
Stacktrace:
at VVVV.DX11.Nodes.DX11LayerGroupNode.Destroy(IPluginIO pin, DX11RenderContext context, Boolean force)
at VVVV.DX11.Lib.RenderGraph.DX11DeviceRenderer.Render(List`1 windownodes)