sorry if this is more of a VUo in VDMX question will ask vidvox as well…
keep getting complete crashes in VDMX - have taken my free frame VUo Plugins out of the free frame folder but still getting this error message in crash reports…
“vertex plane to world”. keeps getting a mention…not sure if this is in my vuo comps running in vdmx. eg.
Crashed Thread: 41 CVDisplayLink
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: exc handler [75460]
Application Specific Information:
BUG IN CLIENT OF LIBDISPATCH: Queue type doesn't support dispatch_sync
t= 20.2301s VuoCompiler.cc:3312 loadModulesAndSources() Loaded into user environment: [b663cd02] /Users/ed_mundio/Library/Application Support/Vuo/Modules/MM.Points_0.vuonode
t= 20.2303s VuoCompiler.cc:3312 loadModulesAndSources() Loaded into user environment: [e557e542] /Users/ed_mundio/Library/Application Support/Vuo/Modules/owlbert.generatorSetUp.vuo
t= 20.2303s VuoCompiler.cc:3312 loadModulesAndSources() Loaded into user environment: [f0385869] /Users/ed_mundio/Library/Application Support/Vuo/Modules/owlbert.randomNonRCustomExtendRange.vuo
t= 20.2304s VuoCompiler.cc:3312 loadModulesAndSources() Loaded into user environment: [a99cbd33] /Users/ed_mundio/Library/Application Support/Vuo/Modules/owlbert.randomNonRepeat2.vuo
t= 20.2498s VuoCompiler.cc:1634 compileModulesFromSourceCode() Compiling owlbert.generatorSetUp
t= 20.2499s VuoCompiler.cc:1634 compileModulesFromSourceCode() Compiling owlbert.randomNonRCustomExtendRange
t= 20.2499s VuoCompiler.cc:1634 compileModulesFromSourceCode() Compiling owlbert.randomNonRepeat2
t= 20.4379s VuoCompiler.cc:3223 loadModulesAndSources() Removed from user environment: owlbert.generatorSetUp
t= 20.4400s VuoCompiler.cc:3312 loadModulesAndSources() Loaded into user environment: [e557e542] /Users/ed_mundio/Library/Application Support/Vuo/Modules/owlbert.generatorSetUp.vuo
t= 20.4895s VuoCompiler.cc:3223 loadModulesAndSources() Removed from user environment: owlbert.randomNonRepeat2
t= 20.4928s VuoCompiler.cc:3312 loadModulesAndSources() Loaded into user environment: [a99cbd33] /Users/ed_mundio/Library/Application Support/Vuo/Modules/owlbert.randomNonRepeat2.vuo
t= 20.4953s VuoCompiler.cc:3223 loadModulesAndSources() Removed from user environment: owlbert.randomNonRCustomExtendRange
t= 20.4988s VuoCompiler.cc:3312 loadModulesAndSources() Loaded into user environment: [f0385869] /Users/ed_mundio/Library/Application Support/Vuo/Modules/owlbert.randomNonRCustomExtendRange.vuo
t= 40.3680s VuoGlPool.cc:1511 VuoGlProgram_use() Oval Shader (with halo): WARNING: Output of geometry shader 'vertexPlaneToWorld' not read by fragment shader
t=496.1272s VuoGlPool.cc:1511 VuoGlProgram_use() Image Shader (Lit): WARNING: Output of geometry shader 'vertexPlaneToWorld' not read by fragment shader
t=554.9701s VuoGlPool.cc:1511 VuoGlProgram_use() Shade Edges with Color: WARNING: Output of geometry shader 'vertexPlaneToWorld' not read by fragment shader
WARNING: Output of geometry shader 'fragmentNormal' not read by fragment shader
t=668.2783s VuoCompositionState.c:100 vuoCopyCompositionStateFromThreadLocalSto Warning: Couldn't find the composition state in thread-local state.
Thread 0:: Dispatch queue: com.apple.main-thread
Have you found a workaround?
not yet- love creating vuo generators and might be doing something silly just not sure… THANKS for any suggestions /leads cheers Paul
Other notes
Vuo version: 2.3.0
macOS version: macOS 10.15
How severely does this bug affect you? It prevents me from completing a specific task with Vuo.
Can you try moving all your custom nodes out of your modules folder and then start VDMX? For an untrained eye, it seems like it crashes when it tries to initiate the custom modules. You could also open the system console to see any error messages when opening VDMX with the custom nodes present. You should filter it to something like “Vuo” “VDMX” as it can be quite crowded with messages from anywhere.
Closing this bug report since the problem may be fixed in the latest VDMX version. @owlbert, if you do continue seeing the same problem with that version, let us know and we can reopen the bug report.
I’ve been having problems with some compositions in VDMX where they don’t render properly, they get “cut off” in the output window and preview windows. It’s a bit hard to explain but it’s something I’ve raised before here a while back and thought was fixed. Reading the console logs I was getting the error on this bug report - both in 8.7.2.7 and 8.7.2.9. A lot of my compositions had lit colour and unlit colour shaders so I thought that was the problem, however I have removed all shaders from my comps and and am still getting the error in the console. I also created a brand new Vuo file and pasted in the nodes (that did not include any shaders) in case there was something in the memory that was still being referenced.
After removing the shaders I’ve not had this rendering issue happen yet - however it will be sometimes ok for hours and the I’ll trigger a comp randomly and then it “breaks” a bunch of other comps. I was trying to find the post I did a year or so back regarding this but can’t find it.
Do you know why it would be throwing this error if those nodes are not in use? I have removed any custom nodes, FFGL plugs and any Image Filter Protocol that I was using as effects.
It’s worth mentioning that there are no issues if I have “run Vuo files in separate processes” checked ON - however this is not a solution for my show this weekend, as there is a momentary pause each time I load in a new composition, even if it has been loaded in before. I did a 4 hour show with all the same the files I was troubleshooting today containing shader nodes on the weekend past without problems, with “run Vuo files in separate processes” checked ON.
-It looks like the files are in Dropbox. I might consider moving out of a Dropbox in case there is any remote chance that the file sync is causing a problem.
-This message:
objc[15894]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff94150cd0) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x126768cd8). One of the two will be used. Which one is undefined.
…is extremely concerning, but I am not sure what is the cause of it. If this is VDMX, they need to fix this ASAP. I don’t know if it could cause your specific problem, and I am unsure what one would do as a workaround. If methods in both versions of this framework are consistent, it may not actually be causing the problem, but the slightest discrepancy between these framework versions can lead to highly problematic results.
-There is an audio hardware error constantly happening, where the device name isn’t able to be obtained. It seems it may cause the ASIO to eventually attempt to shutdown, but an error happens when it attempts to shutdown. Does all of the software have ability to use the audio hardware/mic, via the System Preferences/Privacy settings?
-Does VDMX itself have some sort of OpenGL lighting system that can be disabled or not engaged? Double lighting calls could possibly cause an OpenGL error (I did take note that you eliminated the shaders in vuo and such).
-If it is possible to reconfigure so that the feedback part of a composition is separate, it might be worth trying out to see if that has anything to do with the error. Sometimes feedback based stuff goes awry with loading on the fly. So, the idea being that geometry generating bits are one comp, and the image passes into some feedback part which is a separate comp, or built in VDMX implementation, or whatever. That may be a nonstarter given the specific look, but I don’t know…so it feels worth recommending if it gets you over the hump for this gig.
Hello, a follow up… I think the shader error in the console may have been a red herring (although I have not rolled back my comps to confirm)
However the issue was still happening, where after loading a certain composition, it causes some kind of error with all the other comps where the audio input stops working and overall it breaks all other Vuo comps. It was difficult to debug as I wondered if it had to do with audio error George pointed out.
However I’m almost certain now that there is an issue with the “make image layer” node. I had this node in a couple of comps and removing this has stopped the “breaking” of the other ones (sorry for my incorrect language here, it’s really hard to explain and I will take some screen recording to demo this)
If this theory continues to be confirmed as I stress test today (fingers crossed) I will log a proper bug here and with VDMX, after this weekend.
thanks everyone for all your detective work- I have found the recent VDMX beta s have fixed some of the problems I was having with Vuo ffgl but not all- and now the majority of my ffgl just crash VDMX… Looking forward to further updates to VDMX - good luck and thanks team Vuo !
Finding VDMX tricky honestly, the support is also not great at all these days. I was actually looking at Resolume as they seem to be more on it but I see they only support Vuo plugins. Love VDMX as a tool but the team are not very active any more with the community like they used to be.
Can confirm there are issues with:
Shader node (reintroduced one into my comp and it bugged out)
Make Image Layer node
3D Square node (replaced these with 3D Cube)
I’ve now been able to recreate the problems, tricky when there are multiple problems as I was using a combination of these nodes in various comps.
VDMX 8.7.2.7
(As said will properly log these but just in case someone else comes across this thread)