github-actions[bot]
commented
1 week ago This issue is being marked stale because it has not had any activity for 30 days. Reply below within 7 days if your issue still isn't solved, and it will be left open. Otherwise, the issue will be closed automatically.
Primitive nodes sound amazing on paper, but in practice, they force additional widgets that are useless 99% of the time - why would I ever want to randomise or increment steps in a sampler when I just want to have an easier time controlling two advanced KSamplers for SDXL? Even worse, those additional widgets can't be hidden in group nodes! There's also the rerouting problem, but that's manageable and I understand it's a deeper issue.
To illustrate: This means that my workflows with several hundreds of nodes each use a collective 0 primitive nodes when there should be dozens and I have to resort to custom nodes or other, much more hacky solutions. I understand those additional widgets can be useful in some cases, but being unable to hide them makes the primitive completely fail at its job for a vast majority of them.
It also means some things can't be done cleanly at all. For example, take a group node containing a stack of LoRA loaders for an SDXL workflow. If you wanted to apply the same LoRAs to both the main model and the refiner, you'd need to either pick each LoRA twice or use a primitive to simplify it... at the cost of having a bunch of widgets - that you can't hide - asking if you want to randomize your LoRA models on each generation and to set some control_filter_list, whatever that means.
Here's an illustrative picture of how that looks like for 3 LoRA loaders and nothing else:
These additional widgets aren't even visible in the group node menu
Even just a version of it that simply neglects those additional widgets would make it 100x more useful if hiding those additional widgets is too much to ask.