Hi everyone,
I hope you had the same problem. I write to you because every time I apply an Image filter in Vdmx, which is a simple pixel or more complex, the image flickers, like a white strobe.
It’s really annoying. Does anyone know why? Is there a way to solve the problem?
thank you
@jungbas, in your VDMX preferences, under “Vuo”, do you have the checkbox for “Run Vuo files in separate processes” unchecked? If so, try checking it. I’m not sure yet why the white flashes are happening, but in testing we saw the same white flashes, and checking the box fixed them.
[Edit: I had mixed up checking and unchecking. Fixed now.]
@jungbas, after some initial debugging we asked the VIDVOX folks about it, and it turns out the problem needs to be fixed in VDMX instead of Vuo. David Lublin of VIDVOX offered to send you a build when they’re ready for testing. If you’d like, I can put you in touch with him, or you can email support@vidvox.net and mention this bug report.
Hi, sorry for the delay. Too much work this period, away from vdmx.
If it’s possible yes, I’d like to have a build. I’m having the same issue again, after reinstalling vdmx and vuo few times too. I don’t know if it’s a bug, but it’s a problem anyway. Thanks !
Hey!
Just a follow up here.
I think this issue may have been conflated with another similar one that we had previously fixed in VDMX.
Before I dive in any further, I will note that this appears to not be an issue so far in the Vuo 2.0 beta, so you may want to close this issue out… but if you plan to update the 1.2.x branch, feel free to follow up with us about this.
To the best of our knowledge, this doesn’t appear to be a bug with VDMX. Here’s the high-level summary:
Sometimes (rarely), when loading vuo comps (as dylibs- this does not appear to be an issue when running vuo comps as separate processes) using the c++ API, the image produced by vuo is all-white. When this happens, the following appears in the console log (VDMX’s console log, as the vuo comp is being run within the vdmx process):
[38;5;112m# pid=941 t= 34.6284s VuoHeap.cc:52 sendErrorWrapper() VuoRetain was called for unregistered pointer 0x61400008e380 “(not allocated)”[0m
[38;5;112m# pid=941 t= 34.6287s VuoHeap.cc:52 sendErrorWrapper() VuoRetain was called for unregistered pointer 0x61400008e380 “(not allocated)”[0m
[38;5;112m# pid=941 t= 34.6289s VuoHeap.cc:52 sendErrorWrapper() VuoRelease was called for unregistered pointer 0x61400008e380 “(not allocated)”[0m
[38;5;112m# pid=941 t= 34.6451s VuoHeap.cc:52 sendErrorWrapper() VuoRelease was called for unregistered pointer 0x61400008e380 “(not allocated)”[0m
i don’t know why these errors are being thrown, as every single call to VuoRetain()/VuoRelease() in all of our codebases explicitly checks to make sure that the ptr being retained/released is non-null, and the ptrs they’re getting are coming directly from calls to the Vuo SDK. if this is being thrown from where i think it’s being thrown, the stack looks something like this:
VuoImage tmpImg = VuoImage_makeFromJson(someJSONVal);
if (tmpImg!=NULL) {
VuoRetain(tmpImg);
returnMe = (id)[_globalVVBufferPool allocBufferFromVuoImage:tmpImg];
VuoRelease(tmpImg);
}
(allocBufferFromVuoImage: further retains the passed VuoImage, and doesn’t release it until the VVBuffer using it is released. this is why you’re seeing two “VuoRetain()” calls followed by one “VuoRelease()” call in very quick succession, with the final “VuoRelease()” call some time later when the VVBuffer that was retaining the VuoImage is finally released)