Receive nodes wont get red when sender missing

old behaviour (< 35.1) was: receive node will get red when selected sender is missing (renamed or deleted)

since 35.1 : node just shows NIL as receive string but wont turn red.

→ harder to debug. also sender renaming is hell when you dont remember where you placed the according receives in your project…

sr_not_red.v4p (2.0 KB)

1 Like

under investigation. Thanks for reporting! Also good to hear that red enums are actually perceived as a feature in some rare cases… ;)

To me red Enums have not only been

  • early warning signs with S+R problems,

but also

  • a visual hardware list that auto-checks all the devices availability
  • a project’s life line when upgrading to newer versions, especially with diffff.xml absent or incomplete
  • restless guides while refactoring patches with vvvv-Message

There I say it: They are not only “a feature in rare cases”. When red, they visually highlight that some user-based patch assumption has not been met, or said differently, they spell out the name of an expected item that is currently not available on your system.

1 Like

thanks velcrome for your assuring words!
we’ll work hard to get your nodes red again.

1 Like

when touching that code… maybe it would be possible to sort the enum lists alphabetically!


upcoming alpha comes with these changes:

  • bug fix: invalid enum entries get red again
  • s/r channels sorted in pop up
  • r nodes don’t forget last sender even when sender got deleted
  • ex9 effect: shader technique not red even when null

edit: alpha is up


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.