Search the Community

Hello, After tinkering a bit with workflows, there is a feature i believe it is necessary: "on the fly" option for tasks that involve any kind of transcoding. At the moment, when trying to convert to a file a new location from "X" to "Y" format we are forced to choose between the following 2 ways: Case 01) - read from storage 01 -> convert on storage 01 -> move to storage 02 Case 02) - read from storage 01 -> copy from storage 01 to 02 -> convert on storage 02 -> delete copy on storage 02 It might seem pretty simple, but both scenarios create their own issues that could very easily solved with a "on the fly" option: Case 01: Seems pretty straightforward, but there is a problem: The "original file to format Y " conversion creates traffic both ways (reading and writing) to the storage. And then a third time to move the conversion out of its original place. This is x3 amount of traffic on the network. In a 10gbE that might not be a problem, but on a WAN or even a gigaBit ethernet, that can be a show stopper. Also, moving is a kind of "deleting" operation, that might not be "wise" on certain types of environments. Case 02: I believe this one will be the most usual, but still shows issues: The original file gets copied to the second storage location, and then read again to be transcoded. Later, the copy of the original file gets deleted. This creates, again, a x3 the amount of needed traffic on the network and temporarily x2 on the storage space. In both scenarios the process of conversion is going to work, but the stress the nertwork suffers is worthless. In a few hundred megabytes file this is alright, no harm. But going to large sizes and large quantities of files, this becomes slow-to-almost-unusable. Also, we may think that network & storage resources are always scarce. The solution, in my opinion, would be to create a "on the fly" option, that uses the system internal memory, to handle the conversion without relying on the storage as such. Broadly speaking, this would force the workflows to: read the original file -> store it, or a portion of it, on its memory for transconding -> transcode -> copy/render it to the destination location. I believe that this should be an option for all the nodes involved in converting/transcoding/transforming any material. And that should be exposed on the face of the node, when the option is activated Thanks a lot. Miguel.

Hi, I'd like to elaborate on three notes, about the workflows nodes, that have drawn my attention in the last few days. First: There is no way to "disable" nodes in the script. I know that must not seem prioritary, but when an extensive script populated with many nodes becomes buggy, disabling nodes for testing is the way to go. All node-based systems offer this possibility to the user. Second: It seems that the nodes don't rearrange well when a intermediate node gets deleted or cut. The default behaviour is to break the stream erasing the connection between the incoming and the dependant nodes on the graph, when, by default, the majority of nodes systems do connect dependencies with the dependant nodes. Nodes set with a bifurcation: When the copy node gets erased: <- Wrong behaviour <- Right behaviour workflows should exhibit This behaviour happens not only in bifurcations but also on single stream examples. This "feature" can be specially painful when a node has many dependencies, like a multiple-format conversion. Third: In order to mitigate the second point of this post, and also a feature I'm missing a lot, It'd be advisable to create a "dot" node. The majority of node systems provide with this special node type that allows to connect one node to many others in a simple way. And also serves 2 purposes: 1) allows to keep the graph tidy and easy to read 2) in case one node connected to many has to be replaced, it gets way easier. Some Examples: Unreal Engine: Natron/Nuke: Blender: The "dot/reroute" node provides a lot of flexibility to the graph, speeds up the operation a great deal, and helps to make the graph way easier to read. Thanks Miguel.

Hi!, I'd like to propose a future development that i think i would improve speed and usability on the workflows graph. Like in Unreal engine node editor, i'd like to suggest the creation of a contextual menu, pretty much like the one that exists now when using the right clic on the grpah, but limited to "Tasks and outputs" nodes only. The way it would work is the following: On the output of any node, the user clic+drag to create the line, but when releasing it on a blank area, instead of "loosing" the connection, a dialog box appears showing all the possible/compatible nodes that can be connected to the one we just drag the line from. I hope that this GIF helps to clarify my point: I believe that this feature can help a big deal to increase the speed when building the graph. Thanks a lot Miguel.

Hello, I believe that it is necessary to include a list of recent workflows scripts used in the "File" menu. Mainly for the sake of simplicity+Speed of operation. Thanks Miguel.

Hello, Not sure if it is my version, but it seems that workflows does not have the "undo" option. This is a bit of a problem when the script becomes populated with nodes and something does not go right, or the operator has a "way too fast" set of fingers. Thanks miguel.

It would be a good addition to the software a "node/extra input" that interrupts the flow of an stream until a signal is given to it. The following example paints it clearly: On the image I'm setting up an scenario were a piece of data has to be converted to a .tif format and then copied to another storage elsewhere. After the copy is successful, the .tif conversion requires to be deleted. According to the Overview, the thrash node will be executed before the copy one has a chance to be performed. This can very easily become a hazard and a serious threat to the integrity of the data/storage. A very quick way to solve this would be to provide an extra input to the "Trash" node. An input that halts the node until the signal is provided thru it. Like the following example: Most of the Node systems provide every node with an array of inputs that will modify/condition its behaviour. We can think of this "Wait for" node as the "Mask" input of a Merge node in a compositing software, or a secondary input like a "target" in a logic blueprint. Another option Would be to create a generic "HALT" node that would interrupt the execution of the stream/branch until a signal over a second input is satisfied. I think this is a mild feature request that could benefit the entire software and its usability. Thanks Miguel