Node numbering changes as nodes are added upstream

In resolve 17, adding new nodes to anywhere before the last node cases all later node's numbers to change, which absolutely ruins working with fixed node graphs.

Many colourists will use a fixed node graph precisely because the numbers DON'T change. So you can always ripple a change made to a node on one shot to all or as many other shots as you like. But now none of that works if you ever have to add a node in near the beginning of the tree. If you do, you can never ripple changes too or from that shot as none of the nodes numbers will match your other shots.

It's a small thing but has a huge impact. This will potentially add hours onto a job. I really hope this can be reverted back to how it was in Resolve 16. Or at least add a tickbox in the settings to toggle this behaviour.

Thanks

Agree, this can be a big deal. Can't seem to find a way to turn it off.

Maintaining the node order is important when working with a fixed node structure. With the previous way of working you could get away with adding an extra node (say, for NR) without upsetting the structure.

It might make sense for it to work the old way (nodes numbered by strict creation order) by default, but perhaps there is a “refresh node number order” right click command.

Which would be the best of both worlds - No more carefully constructing node trees, then rebuilding your ”draft” a time or two to get the node order right.

+1

+1
This new behaviour is definitely a problem for me as it stands.

Maintaining the node order is important when working with a fixed node structure. With the previous way of working you could get away with adding an extra node (say, for NR) without upsetting the structure.

It might make sense for it to work the old way (nodes numbered by strict creation order) by default, but perhaps there is a “refresh node number order” right click command.

Which would be the best of both worlds - No more carefully constructing node trees, then rebuilding your ”draft” a time or two to get the node order right.

Yep..that's the correct solution to the fixed node tree engineering annoyance..

Maintaining the node order is important when working with a fixed node structure. With the previous way of working you could get away with adding an extra node (say, for NR) without upsetting the structure.

It might make sense for it to work the old way (nodes numbered by strict creation order) by default, but perhaps there is a “refresh node number order” right click command.

Which would be the best of both worlds - No more carefully constructing node trees, then rebuilding your ”draft” a time or two to get the node order right.

Yep..that's the correct solution to the fixed node tree engineering annoyance..

+1 to adding the right click command, but for those who do not use a fixed structure there should be a user preference to auto update node numbering based on the flow order rather than going by when they were added

One other thought about this issue - while I'd prefer that the numbering remained as in version 16, I would like an option for prev/next node to always go to the previous/next node NOT next number

One other thought about this issue - while I'd prefer that the numbering remained as in version 16, I would like an option for prev/next node to always go to the previous/next node NOT next number

I vastly prefer the way it behaved in Resolve 16. This new behaviour would be a huge time waste for
my workflow, as I want to jump with the press of a "prev/next node" button to go to the specific
node I set up in my node tree. That way I can switch nodes and grade without looking on the GUI and don't waste any time. This is specifically important when you do your first grading pass, where you usually only need a couple of nodes.
The second problem of course, as previously discussed is the one about rippling node changes throughout a sequence.

The best way forward would be to have a preference, to either use the "old" version 16 or the new v17 behaviour.

This is for me the most important feature to fix for v17 before I can productively switch to it!

+1 for right click option!

+1 also. This updated renumbering totally blows away fixed node structure…
I think that this sould be a master project settings option

+100

for us teh use fixed node structure this is a disaster.

please revert to old behaviour.

For those that don't (like myself), this is a nice improvement.

That is why, an option in the projet or user settings will be more that welcomed, in order to satisfy everybody. More and more colorists are working with a fixed node structure (especially the lucky ones that assisted to one of Walter's presentation ). This new automatic node renumbering just ruins all.
It is essential to, at least, bring back the older system.

I don't see any benefit to the new behaviour. I'd quite like it if previous /next node always went to the the previous /next node as opposed to the next numbered node but the actual numbering changing has no benefit and messes up the possibility of using Ripple effectively.

I don't see any benefit to the new behaviour. I'd quite like it if previous /next node always went to the the previous /next node as opposed to the next numbered node but the actual numbering changing has no benefit and messes up the possibility of using Ripple effectively.

That's pretty much sums it, it mature rippling very difficult because you cannot guarantee that the correct number will be there when it's needed...

This would kill fixed node structure functionality, and make the ripple node changes to selected clips a useless function. If it does get added as a feature please make disable-able in preferences.

Grading feature films my basic structure is usually 20 nodes. Commercials about 13 nodes.

+1


Sent from my iPhone using Tapatalk

Hold on... I think it works again in my version now! Cool.

this as been addressed in v17 beta 7 with the addition of a user preference under [color] that use the [creation] number of the node as in v16 and earlier version.

THANKS BM!

Thx BM team!! U are the best!

I really appreciate the BM team's responsiveness!!