PinGroup Solution Update

[dottore]

Hello,
It seems vl has some issue in handling the solution update on pingroup change (at least in the default behaviour).

to reproduce:

• open “HowTo Create Pins Programmatically” help patch
• try to remove one of the entries in the string, to remove one of the pin group entries:
  
  

On my side the recompilation of the patch invalidates the change itself, repristinating the original string with three entries.
I’m on 7.0-0200

I worked around the interaction glitch by patching this:

the pingroup reacts properly.
where I want to arrive is here, where the issue shows up more obviously:

Here we have two identical nodes that want to edit their pingroups in the same frame, invalidating each other.

This pingroup update thing feels quite a critical issue, especially since rely on this language feature in designing many VL libraries

[yar]

This feature has literally been buggy (if not cursed) for as long as I’ve known it. I have tried to use it actively in patches, but once it reaches critical mass, it is almost impossible to work with. Yes, it constantly reloads, overwrites, glitches. One of the main problems is the latency that builds up with a large number of such nodes and inputs to them. After a thorough test of this feature, I almost never went back to it, but I think it’s just not ready for production (like some other features that are in the concept stage).

[dottore]

Yes, it’s an unstable feature, but also so critical for us library developers!!
Devvvvs should give it some love, conceptualize its mechanics and fix them (if possible).
It feels it wasn’t tested properly in differentiated scenarios.
Like the one I posted, where there are concurrent pingroup editor nodes:
it looks like there’s no mechanism for shared solution editing, so instead of aggregating the edits from different nodes and then applying them in the next frame (which would be a better compromise), each of them triggers some process (recompilation/…) right away, probably invalidating the solution that the others are handling…
any thought @gregsn @Elias ?

[yar]

I think it’s just a side feature (from the main patch and node structure) that became a concept and nobody worked on it as a feature. In general, I can’t disagree that this is potentially a very powerful tool if it were to be made to work.

In general, dynamic nodes in a broader sense are a very interesting thing.

[antokhio]

The problem there that it’s going to drop connections if input pin is changes, therefore making it unusable in sub patch for instance, you gonna loose connections without knowing…

[yar]

It seems to me that this feature automatically raises several questions at once.

1. Will spreads be considered as multiple inputs by option? For ‘dynamic’ pins in case of spreads you have to create two types of nodes: those containing pin groups and those not containing pin groups. This seems to be changed sooner or later.

2. Will multiple connections to an input ever be considered?

And then it seems to make sense to think about ‘dynamic inputs/outputs’. Without answering the more fundamental questions, this may only be a temporary solution. As if the pin API in general could be rethought and greatly improved, and these changes could drive a large number of different useful changes at once.

[Elias]

Fixed in upcoming preview. Instead of applying changes right away, the system will record them and apply them all at a later time when it is safe to do so (the editor is idle, no user interactions). In internal tests both your patches you posted behave correct now, even when dragging nodes around.