I had VVVV to Resolume working great for years (as long as a sender is open before vvvv). I recently updated both vvvv (from betav37 to betav39) and spout(from 2.005 to 2.006) and now I can’t get spout sender to send out of vvvv. I am running on a desktop nvidia 1070 and intel cpu. I have tried running both programs as administrator, I have tried different gpu/cpu/memory modes, and I have tried reverting back to previous versions, but going back to my last working version of vvvv did not solve the issue. Is there a way I can get previous versions of the spout installer? github has source code for previous versions but no downloadable installers.
I had the same issue, vvvv support is very frustrating,
after trying different settings in the spout control panel decided to use vvvv dx11 wich seems to work a little bit better,
one key tip is to open spoutReceiver, then the vvvv patch and once you are sure you are receivig the video, open resolume, its like vvvv need to be the first sender to start
Thakyou @lisandroperalta. It looks like VVVV has to be the first sender to start. I hope that solves it until I can re-visit and test VVVV.
The latest Spout installer is now available from the new Spout website download page.
Previous installers for 2.005 and earlier are on GitHub here.
Just an update after messing around on my system for a few days… I cannot get the dx11 spout sender to send no matter what, I can however get output of a dx11 renderer output and convert to dx9 and use the ex9 spout sender (same old style of make sure spout rx is running before launching vvvv and make sure vvvv is the first sender to register its name). Installing the previous version of spout did not change anything, this issue has nothing to do with spout, I am convinced the issue is with some microsoft library update effecting vvvv sharedMemory handles bs (I tried different vvvv versions).
So to be clear, other applications like Resolume are working OK?
If you open the Spout demo receiver first, without any other Spout application running, then start the VVVV sender RH click in the receiver. Do you see the VVVV sender name listed? Does the display show anything at all?
It might have something to do with NVIDIA settings. In the control panel, find “Threaded Optimization”. Is it ON? If so, set it OFF.
It should not make any difference, but we can eliminate some possibilities if you try the latest demo receiver here
Also it might not help at all, but at least we can look at simple diagnostic. In the latest Receiver, Help > Diagnostics, Click Copy and paste the result here.
I installed vvvv_beta_39.1_x64_setup including addon pack and confirm that the VVVV sender has to be started first.
I tried again with the latest Preview - 3e3e53d8ba 64bit Version 18/04/2020 09:31 and found an application error when the patch was started. This appears to happen when the list of senders in memory is updated with the VVVV sender’s information.
It seems that if the beta version is used and VVVV is started first, the patch behaves normally. I could not find Joreg’s plugin code, so I can’t help much directly but will try to help if he needs it.
If you still can’t get it working, we will need to explore in more detail as started above so that I can reproduce the problem.
I will try to set the ‘Threaded optimization’ 'setting to OFF as it was set to AUTO previously in all my testing. I just grabbed the latest receiver and will use it in the next few days to recreate the issue and fill up the log with some data.
I am able to get everything working now, workaround being, convert dx11 tex to dx9 tex and use it on an ex9 spout sender. I will explain what happens to the dx11 sender that fails though - when I start the vvvv patch, the sender name will appear in the available list (will not auto select) but once I select it nothing will open and the name will disappear from the list if I try again.
A little background, I have played around with vvvv for many years and have many patches that previously used the dx11 sender just fine. Spent a few months not making new visuals, and either microsoft updates or updating my vvvv to check out some new features (the easy pbr shader) caused some kind of issue. System is average desktop with i7 and 1070.
Thanks for all the help and the input on getting everything working, spout is awesome and works great everywhere else I try it.
Yes there is something strange going on. I can debug this if I can reproduce what you see. The fact that the EX9 sender works might give a clue. Threaded optimization is definitely a problem - reason unknown.
There is a fault adding the sender’s name to the sender name list which shows up as an Application error with log if you use the preview version. Perhaps you could ask Joreg to look at this with a debugger. There are some other minor things that I can point out if he decides to update.
hello,
experience same behaviours here and found that
all the sent textures needs to be r16g16b16a16_float
cheers
1 Like
Thank you @circuitb. That fixed my issues. I was either going from a dx9todx11 texture or out of a normal dx11 renderer with their defaults. By using Renderer(DX11 TempTarget) and setting the format all my dx11 spout stuff is working.
This could be because the format written to the sender’s shared memory map is zero instead of the actual texture format. A receiver will then create a shared texture with default format DXGI_FORMAT_B8G8R8A8_UNORM.
Can you try setting the VVVV texture format to B8G8R8A8_UNORM?
Also the problem with sender name registration could be linked to the maximum number of senders. The plugin uses a default value of 10, so that must be set with “SpoutSettings”. Can you confirm that this is set to 10? If it already is, there must be some other problem.
B8G8R8A8_UNORM is working here but there’s something wrong on the vvvv / dx11 side
feeding the sender directly from a texture without going through a Renderer(DX11 TempTarget)
ONLY works if i convert the texture to
<string format=“B8G8R8A8_UNORM”;>
or
<string format=“R16G16B16A16_float”;>
This is looking like a texture format problem. As far as I can tell, the GL/DX interop for linking with an OpenGL texture is failing. I have yet to fully trace this through.
I have found that the texture format for the sender information is set incorrectly as D3DFMT_A8R8G8B8 (21) instead of the actual format DXGI_FORMAT_R8G8B8A8_UNORM (28). I don’t think that is the fundamental problem though. This should be fixed but I can bypass it for testing. Unfortunately when I set up VVVV again to test, it works OK and I have yet to get a repeatable fault.
Meanwhile it seems that your workaround solves the issue.
I found the plugin source and can build it.
I see at least the format problem as suspected. The default texture format is set to 21 (DX9 RGBA) instead of 28 (DX11 RGBA).
It’s an easy change for a test, so I have recompiled the plugin with 28 default. The dll contains many other plugins, so it might not be advisable to use it permanently, but here it is to try. Please let me know if it works for you.
I have been using vvvv_beta_39.1_x64.
- Find VVV.Nodes.dll in C:\vvvv\vvvv_beta_39.1_x64\lib\nodes\plugins\
- Make a copy and rename to something else as a backup
- Replace with the test version
looks like it fixes the format part,
i guess Joreg leave the 21 (DX9 RGBA) format since
the dx11 contrib is not part of the native vvvv installer nor the addonpack
but nobody use dx9 in 2020?
OK that’s good. This means that an RGBA texture can be used. Otherwise I was thinking it was a driver issue.
I think that originally Joreg set the format to 0. Then the Spout side assumes the shared texture is DX9 RGBA. The latest version changed that to 21, which is indeed correct for DX9 RGBA, but for a DX11 texture it causes problems for copy.
There is another error in the code. MaxSenders is hard-set to 40 and copy to-from the sender names memory map assumes this size. If the map size is set to less and another sender is started first, there is an over-run and it will cause an exception.
I think I can change this. But in the meantime, make sure you set Maximum senders to 40 with SpoutSettings. If it is set to less it only will be OK if VVVV is started first. Then it creates a sender names map of this size.
There are some other things I will look into before contacting the developers. Hopefully this can be updated to work again.
hello,
MaxSenders set to 40 works here!
thanks,
Joreg has kindly responded to my pull request.
If you scroll to the bottom he has asked for testing.
1 Like
Setting max senders to 40 in spout settings allows me to open software in any order. I can now just decide to run a vvvv patch on the fly and it will actually work no matter what software I started first. This thread has been super helpful, thanks.
I am also running the new version of the dx11-spout from github, it works great, and I am ensuring that all my renderers are set to R16G16B16A16_Float target format.