THE PROBLEM: Non-linear, node based software running on host based systems; When running into problems with the interface freezing or experiencing an issue that is perceived as a bug, it is important to eliminate user error from the equation where possible. For this, I think we all use something like an engineering “Trouble Tree” just like an EIC would in Broadcast.
THE HYPOTHESIS: In building custom signal flows in Silhouette paint + Resolve + BCC Continuum on the Fusion page, there is the possibility of having the same process stacked twice or possibly feeding back into itself causing problems.
THE SCENARIO: In broadcast work, we have physical racks full of terminal gear that handles these processes in a linear fashion but operate much like tree nodes in the non-linear world. The linear “source signals” are routed or patched using a patch bay into decks, distribution amps, image processors, production switchers, etc… which feed back into the system backbone. So in this linear “node tree” it is possible to get a feedback loop if something winds up getting patched into itself.
When troubleshooting problems in linear hardware based systems, It is typical to patch out a device using the patch bay. I’m wondering if Silhouette can be treated in the same way to isolate issues?
In other words, if I remove the “patch” of a node, leaving it on the palette but bypassing it in the signal tree, does this fully eliminate that node from the list of possible culprits?
I am using a combination of Fusion nodes in Resolve. Some of them are Resolve nodes, some are BCC nodes and one is Silhouette paint. Then, inside the Silhouette paint nodes, I have other nodes (currently, none of them are BCC but this is an option.) I’m having problems with the transport controls in Silhouette. If process stacking can cause these types of issues, I’d like to isolate the problem using a traditional trouble tree.