totally agreed that this is annoying. but there are some implications that make sense actually.
the error that you get tells you that the process node you would defined has a problem because it would have two output pins with the same name. so you should ask two questions:
do you even need the process node? of not, just switch it off (disable the button besides “Order”), this gets rid of the error.
do you ONLY need the process node? if yes, you will probably not need the index on two output pins.
if none of the solutions work for you, then you need to rename one of the pins indeed.
this is no new problem for us, and the plan is that you can fix the error by renaming only the pin on the process node, or we allow the double name pins and have a visual indication to which operation it belongs. both not implemented yet…
I switched off the process node generation, works now with common names
maybe this should be the default, especially if it has naming implications like that.
edit: after being more observant about it while patching vl, i saw these kind of full-process-nodes being used e.g. as S+H. I myself never used it like that (all operations in sequence, in one node), because i usually try to model stateless operations, which I use as granular nodes from some kind of stateful manager class
So if this can be considered syntax sugar for one-node-processes with unfortunate naming side-effects, it should definitely NOT be the default…
that sounds a bit contra to our intended use then… the reason for Process being the default for a patch is exactly because thats most likely what we want to create in most cases. if not, you can also directly create a Class or Record (by typing those in the nodebrowser).
that sounds a bit like reinventing the idea of what the Process already is… will be interesting to have a look at some of your patches to see how you’re structuring your programs…