Beta 25.1 - red nodes

Is anyone else getting (seeminly at random) red nodes in patches, where the nodes aren’t actually missing from the patch?

Sometimes random mousing or selecting the node fixes the problem, other times I’ll have to delete and remake the nodes.

Example - Just opened the audio analysis module, and inside it the audio record selector, plus the enum io box connected to it, are red. Both nodes are there, connected, and viewable in the inspector, but seem ‘disabled’. In this case deleting and remaking the audio record selector does not fix it…

Arrrgh. Even just making an audio record selector node in a blank patch results in a red node. This is bad!!

Is anyone else getting this?

ai boni,

actually that is not so bad at all. it will just help us all to identify problems much quicker. as mentioned on vvvv45beta25.1 a red node can mean the following:

  • a missing plugin
  • a runtime error
  • a missing enum entry (like a missing channel at a receiver node or a missing device on your system)

e.g. in the case of AudioRecordSelector (System) my understanding now is that this node is no longer needed on Vista/7. all devices now seem to be choosable via the Driver on AudioIn (DShow9).

for this reason there is this new version of FFT (DShow9 4Channels Win7) which just ommits the AudioRecordSelector. a Win7 version of AudioAnalysis (DShow9) (which would do the same) is still missing though.

concerning red nodes in other situations: yes, there seem to be some false alarms still. would be great if you find them to be reproducible and report here how to get them.

I’m still using XP. Should ARS not still work there? Thankfully using my audio interface the default input selection is the right one, but this setup may change.

I’ll try to let you know about other red node issues. I did have one earlier when opening the Gaussian Blur Pass module from Dottore’s Glow Pass setup, and the enum io box plugged into the technique input pin of the first Gaussian blur shader was red. Deleting it and remaking it seemed to fix this.

Cheers Joreg

I’ve seen thison Xp too, again audio selector, but in my case the ctl panel for the audio was missing too, but in addition, I had two plugins one was hit tester 2d can’t remember the name of the other, I’m awY without that machine, both showed red if I double clicked the patch to open, but were ok if I opened vvvv then the patch. Both were in my Addons folder.
I also had avs refuse to work, the files played in filestream tho, and freeframes swapped Colour channels, or were yuv or something, more details when I return!

right, on XP ARS should still work as expected and not show up red if you simply create it (unless as cat described no device seemed to be available on the system in which case it is nice to be warned about this fact by a red node). i may still show up red though if you open a patch that you have saved on a different PC with a different audiodevice setup. in such a case a red node would point you to the saved/selected enum not being available on your system.

Will check and get back to you

just a note, the gain pin of FFT (DShow9 4Channels Win7) does nothing for me!

sapo – right click the fft node and look what happens when you change gain to 99999

In Gaussian Blur Ratio, the subpatch inside Dottore’s Glow Pass - http://vvvv.org/contribution/glow-pass ,

one of the enum io boxes that selects the technique for each gaussian blur shader is red, and the input pin for technique is nil, even though the duplicate shader in the same patch (there is one for x blur, one for y blur) is fine.

. . . . . . ?

@mrboni:
i can’t confirm this. i opened GlowPass_ROOT.v4p and all looks fine. nothing red here.

edit:
i can confirm it now. had to move the renderer on the 2nd monitor and switch it to fullscreen. now i’ve exactly the same thing like you desrcribed it. if i switch back to windowed everything looks fine again. thx for reporting this.

Thanks Elias

Let me know if you come up with a workaround of any sort. Could really do with using that Gaussian Blur Pass for a gig next week!

mrboni, have you tried making them into 2 separate shaders, might get you through the gig?

@mrboni:
do you need to change the technique? i mean the node is turning red, because the technique enum input pin contains nil for some yet unknown reason, but that doesn’t mean the effect node is not working anymore. at least here. output in fullscreen renderer on 2nd monitor looks good.

Hmmm. I’ll check. I did change the technique previously and save it as a copy. (I wanted double x blur) Maybe it still works.

is string2enum-(enumerations) still working in beta 25.1?!
clean patch, create a stringToEnum, red node.
and even if you modify the input string, the node remains red and outputs nil.

@dottore: does it stay red for you, when you connect it?
for me the node turns grey, once it is connected and the enum is valid. which kinda makes sense (just kinda), since you could connect it to any enum input thus the enum cannot be evaluated as valid, as long as not connected.

hey woei, in the simple patch i mentioned they don’t stay red if connected, but in the big project i’m working on (many subpatches) the problem remains. maybe if send and receive are placed in different patches they have problems with string to enum? (i use string to enum for every receive to make sure it takes the right channel). anyone has the same problem?

hey dott, switched for vux’s S R nodes simply solves the problem

vux’s S R have a framedelay in transmission. keep it in mind.