VL Node connection limit bug

[tobyk]

EDIT: I think it’s a node or connection limit bug, see posts below.

First off I apologise for giving you such a monster patch to demonstrate this bug with.
I’ve been trying to recreate the conditions for this bug in smaller patches but it only seems to happen in my monster patch.

I’ll be happily patching in VL when after a connection suddenly TTY renderer spews out errors.

It happens in one of two patterns: I’ll find a totally unrelated node has turned red, usually a time based node like LFO or stopwatch.

OR it happens in another pattern where creating an LFO or Stopwatch and then giving it an iobox will turn another unrelated node red.
I’ve managed to create a repeatable version of the bug in this pattern.
Once again sorry for the mess, I can’t seem to isolate it reliably.

Tested in Beta35.8x64.
(I tried to test it in latest Alpha but that causes lots of other errors with my test patch, ambiguous references for the IPAddress type amongst other things).

TTY Error is

VL.Lang.Platforms.CIL.Runtime.PatchTracer.Trace(Boolean, UInt32, System.String, UInt32, !!0 ByRef, UInt32, !!1 ByRef, UInt32, !!2 ByRef, UInt32, !!3 ByRef, UInt32, !!4 ByRef, UInt32, !!5 ByRef, UInt32, !!6 ByRef, UInt32, !!7 ByRef, UInt32, !!8 ByRef, UInt32, !!9 ByRef, UInt32, !!10 ByRef, UInt32, !!11 ByRef, UInt32, !!12 ByRef, UInt32, !!13 ByRef, UInt32, !!14 ByRef, UInt32, !!15 ByRef, UInt32, !!16 ByRef, UInt32, !!17 ByRef, UInt32, !!18 ByRef, UInt32, !!19 ByRef, UInt32, !!20 ByRef, UInt32, !!21 ByRef, UInt32, !!22 ByRef, UInt32, !!23 ByRef, UInt32, !!24 ByRef, UInt32, !!25 ByRef, UInt32, !!26 ByRef, UInt32, !!27 ByRef, UInt32, !!28 ByRef, UInt32, !!29 ByRef, UInt32, !!30 ByRef, UInt32, !!31 ByRef, UInt32, !!32 ByRef, UInt32, !!33 ByRef, UInt32, !!34 ByRef, UInt32, !!35 ByRef, UInt32, !!36 ByRef, UInt32, !!37 ByRef, UInt32, !!38 ByRef, UInt32, !!39 ByRef, UInt32, !!40 ByRef, UInt32, !!41 ByRef, UInt32, !!42 ByRef, UInt32, !!43 ByRef, UInt32, !!44 ByRef, UInt32, !!45 ByRef, UInt32, !!46 ByRef, UInt32, !!47 ByRef, UInt32, !!48 ByRef, UInt32, !!49 ByRef, UInt32, !!50 ByRef, UInt32, !!51 ByRef, UInt32, !!52 ByRef, UInt32, !!53 ByRef, UInt32, !!54 ByRef, UInt32, !!55 ByRef, UInt32, !!56 ByRef, UInt32, !!57 ByRef, UInt32, !!58 ByRef, UInt32, !!59 ByRef, UInt32, !!60 ByRef, UInt32, !!61 ByRef, UInt32, !!62 ByRef)'.

VL Time node bugs.zip (366.7 KB)

[tobyk]

Some more information:

Doesn’t always seem to be related to time nodes. Got a bit further along with patching and now it’s happening with a class of nodes I created myself. They are all operations unlike the time nodes which are processes. As before errors don’t happen when you create the node, instead they happen when you start connecting pins to it.

Sometimes I get an exception pop up ‘Sequence Contains No Matching Element’

[tobyk]

Ok, a further theory. It seems to be functioning something like a rough node limit, but the limit only applys once the node is connected, I.E to an IOBOX. Some nodes sometimes won’t trigger it. Eg NOT, AND and Togedge only trigger the limit sometimes. Complex nodes like processes seem to trigger the limit everytime. If I get this error I can delete any of those kinds of nodes to clear it. Swap one for another as long as the total in the patch doesn’t exceed this apparently limit.

[tobyk]

Yes seems to be a limit on the patch itself. Refactoring into sub processes or operations so you have less nodes on your patch seems to be a workaround.

[Elias]

Sorry for this one. My bad. Was a little sloppy when writing that part. The error you get is indeed about an internal limit of how much values the system can push out at a time when running a patch in the debug code path so you as a user can see the values running through. So nodes with more the 64 inputs or outputs and also patches with many many pads will basically run into this. Will fix that in upcoming alpha builds and report back here once that is done. Thanks for the reminder.

[Elias]

Will be fixed in upcoming build (https://teamcity.vvvv.org/viewQueued.html?itemId=22525). Thanks again for the report.