Nicotux
.".. it looks like we need "PixelShader.h" or have I missed something.
... I think I have figured it out."
fine but how ?
git code still not compile due to missing Pixelshader.h and undefined PixelShaderCode
... I think I have figured it out."
fine but how ?
git code still not compile due to missing Pixelshader.h and undefined PixelShaderCode
Posted Wed 06 Jan 21 @ 2:57 pm
SBDJ
I didn't want to update the project file due to VS version differences.
Set PixelShader.hlsl to compile in its properties as HLSL Pixel Shader, Model 4 Level 9_3. Set its Header variable name to PixelShaderCode and the Header file name to PixelShader.h. Remove the output file name, it's not needed.
When PixelShader.hlsl is compiled, it will generate PixelShader.h containing the shaders compiled byte code in the variable PixelShaderCode.
No need for messing around with resources, binary blobs or runtime compiling :)
Set PixelShader.hlsl to compile in its properties as HLSL Pixel Shader, Model 4 Level 9_3. Set its Header variable name to PixelShaderCode and the Header file name to PixelShader.h. Remove the output file name, it's not needed.
When PixelShader.hlsl is compiled, it will generate PixelShader.h containing the shaders compiled byte code in the variable PixelShaderCode.
No need for messing around with resources, binary blobs or runtime compiling :)
Posted Wed 06 Jan 21 @ 7:54 pm
SBDJ
I will have a look over the code in a bit, I probably missed something at 3am! I assume this was with the updated version groovindj?
Posted Wed 06 Jan 21 @ 7:57 pm
SBDJ
Found a memory leak, I'll have a look at plugging it up.
Posted Wed 06 Jan 21 @ 8:15 pm
Nicotux
I finally figure out either :
the .hlsl was not compiling by default
once added it needs the correct variable name
I do not get the white page, but not resized when window resize at first time
after what everything is working
the strange thing being VDJ related:
when used as deck plugin
transition apply only if track was loaded
the .hlsl was not compiling by default
once added it needs the correct variable name
I do not get the white page, but not resized when window resize at first time
after what everything is working
the strange thing being VDJ related:
when used as deck plugin
transition apply only if track was loaded
Posted Wed 06 Jan 21 @ 8:15 pm
SBDJ
I've just submitted a pull request to fix the resizing/full screen issue and the memory leak I found.
Might be worth adding a SafeRelease template (or pp macro if you must) btw, much easier to work with :)
Might be worth adding a SafeRelease template (or pp macro if you must) btw, much easier to work with :)
Posted Wed 06 Jan 21 @ 8:53 pm
groovindj
SBDJ wrote :
I've just submitted a pull request
What does that mean - you have to wait for Lynn?
Thanks for the help Scott. It'll be be nice to be able to use this finally.
Posted Wed 06 Jan 21 @ 8:57 pm
SBDJ
Yes, essentially I fork his beta branch into my own github repo, work on it there and then create a pull request to allow those changes to be merged back into the original beta branch.
Obviously I can compile it myself, but it's not my code - I've just butchered it a bit - so I'd rather let the author retain control.
Obviously I can compile it myself, but it's not my code - I've just butchered it a bit - so I'd rather let the author retain control.
Posted Wed 06 Jan 21 @ 9:05 pm
groovindj
Hopefully the plugged leak will stop this from happening too:
The deck waveforms (set to 'shapes') were drawing as the file loaded then flattening out or not showing. I had to switch back to 'beats' waves.
The deck waveforms (set to 'shapes') were drawing as the file loaded then flattening out or not showing. I had to switch back to 'beats' waves.
Posted Thu 07 Jan 21 @ 12:52 am
leadedge
Thanks Scott
I have created a new release (https://github.com/leadedge/SpoutVDJ/releases/tag/v2006).
I can't test it with all the possibilities of VirtualDJ, but it looks good to me. Thanks to your changes, the full screen issue is fixed. I have no idea how you did that. The memory leak was because a pointer was not being released as you found. It works with all Spout sources I am able to test with including Resolume and handles sender change and re-sizing OK.
NicoTux - sorry for the brevity of my previous post. I was only half sure I had it right. I have updated the Visual Studio 2017 project files to include the pixel shader changes. I hope I got it right. RH click on PixelShader.hlsl > Properties > Output files, you will see the names required. Then when the shader is compiled it produces the header file and everything builds properly.
So GroovinDJ it should be fine with Resolume now. At least I can't fault it. I have run it for hours with no leak or other issues but you need to give it a run through in practice. All being well I will move it out of beta.
I have created a new release (https://github.com/leadedge/SpoutVDJ/releases/tag/v2006).
I can't test it with all the possibilities of VirtualDJ, but it looks good to me. Thanks to your changes, the full screen issue is fixed. I have no idea how you did that. The memory leak was because a pointer was not being released as you found. It works with all Spout sources I am able to test with including Resolume and handles sender change and re-sizing OK.
NicoTux - sorry for the brevity of my previous post. I was only half sure I had it right. I have updated the Visual Studio 2017 project files to include the pixel shader changes. I hope I got it right. RH click on PixelShader.hlsl > Properties > Output files, you will see the names required. Then when the shader is compiled it produces the header file and everything builds properly.
So GroovinDJ it should be fine with Resolume now. At least I can't fault it. I have run it for hours with no leak or other issues but you need to give it a run through in practice. All being well I will move it out of beta.
Posted Thu 07 Jan 21 @ 2:02 am
Nicotux
Thanks everyone !
@leadedge:
No problem, i use VS 2019 and finally figured out what to do (I just don't know anything about DX)
I added the same tiny patch I submitted for previous version (nothing to do with rendering)
SpoutSender64 already send as per deck name
Can receive from any other decks but master to prevent loopback
works fine
Got Issue (BSOD) with receiver enable both as videofx and videosource
may be due to same name with both instances on master,
if it's really the reason it may be fixed with little mod to the naming patch
(already done in another plugin, the same apply to "release" slot as well as "videoSource")
https://imgur.com/a/V2Pw1oU
Maybe would be fine next step to be ...
- Available again as an overlay
- use of (not already officially in SDK) position selection parameter button
#define VDJPARAM_POSITION = 10
@leadedge:
No problem, i use VS 2019 and finally figured out what to do (I just don't know anything about DX)
I added the same tiny patch I submitted for previous version (nothing to do with rendering)
SpoutSender64 already send as per deck name
Can receive from any other decks but master to prevent loopback
works fine
Got Issue (BSOD) with receiver enable both as videofx and videosource
may be due to same name with both instances on master,
if it's really the reason it may be fixed with little mod to the naming patch
(already done in another plugin, the same apply to "release" slot as well as "videoSource")
https://imgur.com/a/V2Pw1oU
Maybe would be fine next step to be ...
- Available again as an overlay
- use of (not already officially in SDK) position selection parameter button
#define VDJPARAM_POSITION = 10
Posted Thu 07 Jan 21 @ 2:24 am
leadedge
OK, the BSOD doesn't sound good. I am not sure that you can use the same plugin as an effect and a source, I would make different versions with different names. I will examine possibilities of overlay. Wouldn't you need to consider blending and alpha and that sort of thing.
I will have a look at those deck renaming changes. A receiver does not need to generate different sender names though. The possibility of feedback from other decks needs attention, although again it isn't sending.
Do you have a GitHub repo?
I will have a look at those deck renaming changes. A receiver does not need to generate different sender names though. The possibility of feedback from other decks needs attention, although again it isn't sending.
Do you have a GitHub repo?
Posted Thu 07 Jan 21 @ 2:50 am
Nicotux
yes... GitHub Repo same pseudo... not used for a long time (but for contacts) and now empty ... since I leaved linux for windows ^^ maybe time to reactivate
As a deck plugin receiver need to generate the sender names it will not connect to (same deck normal bus and release bus)
it may create different receiver names for master video and master audio and master source slots in a way to be usable without ambiguity, (and ease debugging multiple instances) as they all 3 display as "master"
(it looks like with same name the wrong instance can be call - when not important for things like cover it can crash for receivers - but reason may be concurrent access to the same hardware... BSOD, show this with ArtnetDMX as well)
As a deck plugin receiver need to generate the sender names it will not connect to (same deck normal bus and release bus)
it may create different receiver names for master video and master audio and master source slots in a way to be usable without ambiguity, (and ease debugging multiple instances) as they all 3 display as "master"
(it looks like with same name the wrong instance can be call - when not important for things like cover it can crash for receivers - but reason may be concurrent access to the same hardware... BSOD, show this with ArtnetDMX as well)
Posted Thu 07 Jan 21 @ 3:41 am
leadedge
There is protection against receiving from a sender named "VDJSpoutSender64" but that has not been updated for the naming on different decks. I have now changed it to exclude any sender with "VDJSpoutSender64" in the name.
I also noticed a mistake in the plugin info flags. It should have VDJFLAG_VIDEO_VISUALISATION but there was a typo when adding VDJFLAG_VIDEO_OUTPUTRESOLUTION and this was added twice.
I have made an update but instead of creating a new release each time I have created a Binaries folder for the latest build. Just click on the file to get the download button.
There is an optional #define in the 32 bit receiver plugin to compile as an effect instead of a source, by changing the info name and description. The compiled plugin is then re-named "VDJSpoutEffect.dll". It seemed to work OK, but I took it out due to uncertainty whether renaming a dll like that might introduce problems. It still has the fundamental "SpoutReceiverPlugin" class name.
It would be better to create an entirely separate plugin. But then there is the question of whether it's still OK to draw the received texture in the same way. I am not sure. There is also the question of what info flags should be set. The 32 bit version set none.
Edit: ignore the latest change until I sort it out. Use the release version.
Edit again : I found the problem, so you can compare the two.
I also noticed a mistake in the plugin info flags. It should have VDJFLAG_VIDEO_VISUALISATION but there was a typo when adding VDJFLAG_VIDEO_OUTPUTRESOLUTION and this was added twice.
I have made an update but instead of creating a new release each time I have created a Binaries folder for the latest build. Just click on the file to get the download button.
There is an optional #define in the 32 bit receiver plugin to compile as an effect instead of a source, by changing the info name and description. The compiled plugin is then re-named "VDJSpoutEffect.dll". It seemed to work OK, but I took it out due to uncertainty whether renaming a dll like that might introduce problems. It still has the fundamental "SpoutReceiverPlugin" class name.
It would be better to create an entirely separate plugin. But then there is the question of whether it's still OK to draw the received texture in the same way. I am not sure. There is also the question of what info flags should be set. The 32 bit version set none.
Edit: ignore the latest change until I sort it out. Use the release version.
Edit again : I found the problem, so you can compare the two.
Posted Thu 07 Jan 21 @ 4:40 am
groovindj
UPDATE
I've just successfully completed a three hour stream to Twitch whilst feeding Resolume into VDJ.
No issues (apart from people saying it was quiet, even with VDJ output as hot as I could get it).
I've just successfully completed a three hour stream to Twitch whilst feeding Resolume into VDJ.
No issues (apart from people saying it was quiet, even with VDJ output as hot as I could get it).
Posted Thu 07 Jan 21 @ 12:59 pm
SBDJ
Glad the issues seem to be resolved :)
This makes NestDrop viable for people too now I imagine.
This makes NestDrop viable for people too now I imagine.
Posted Thu 07 Jan 21 @ 2:03 pm
Nicotux
I was thinking that excluding any sender with "VDJSpoutSender64" in the name was not a so good idea when used as a deck plugin because it prevents a deck to receive from another one but in fact it's not so bad because it's CPU consuming and a plugin doing this without the help of Spout may be really simple
i used the same kind of thing the sender does :
sprintf_s(g_noReceiveName, 256, "VDJSpoutSender64 %s%s", (deck == 0) ? "" : "Deck ", (deck <= 0 ? (deck >= -3 ? std::array <std::string, 4> { "master", "sampler", "mic", "aux" }.at(-(int)deck) : std::to_string((int)deck)) : std::to_string((int)deck)).c_str());
and refuse to connect to all 3 "VDJSpoutSender64" "VDJSpoutSender64 master" & g_noReceiveName
allowing all other senders "VDJSpoutSender64 Deck n" where n is not deck ( "plugin_deck" )
"renaming a dll like that might introduce problems"
No, it is not renaming the dll, it's defining another internal name (to be display in GUI) and prevent some issues, specially when used as master, source and videofx (all display the same if same name) and really helps with debugging...
i used the same kind of thing the sender does :
sprintf_s(g_noReceiveName, 256, "VDJSpoutSender64 %s%s", (deck == 0) ? "" : "Deck ", (deck <= 0 ? (deck >= -3 ? std::array <std::string, 4> { "master", "sampler", "mic", "aux" }.at(-(int)deck) : std::to_string((int)deck)) : std::to_string((int)deck)).c_str());
and refuse to connect to all 3 "VDJSpoutSender64" "VDJSpoutSender64 master" & g_noReceiveName
allowing all other senders "VDJSpoutSender64 Deck n" where n is not deck ( "plugin_deck" )
"renaming a dll like that might introduce problems"
No, it is not renaming the dll, it's defining another internal name (to be display in GUI) and prevent some issues, specially when used as master, source and videofx (all display the same if same name) and really helps with debugging...
Posted Thu 07 Jan 21 @ 5:28 pm
Nicotux
Other thing about VDJPARAM_POSITION & VDJFLAG_VIDEO_OVERLAY : I got it working as needed
Tried to put some kind of thing in GIT... first time for years and first time using VS so that...
https://github.com/nicotux/VDJSpoutReceiver64_Overlay
Tried to put some kind of thing in GIT... first time for years and first time using VS so that...
https://github.com/nicotux/VDJSpoutReceiver64_Overlay
Posted Thu 07 Jan 21 @ 6:20 pm
DHoude
Thanks for everyone's help. I truly use these a lot. I noticed one thing that started as more of a fumble.
If I am playing music videos, and Spout Receiver is playing as a Video Effect on the master deck, covering my music videos. If I double click the Skin Main Deck window (it was to get back my larger Output window back). That will turn off the main screen (expected, that is the fumble). But when I double click it again to activate Video, ad get my Output window, Spout Receiver is displaying all Black. If I turn Spout Receiver off, I see my Music Videos. Turn it back on, Spout Receiver is still black.
I basically have to restart VDJ to get the Spout Receiver working again. I know this is not a typical use case, but it can happen pretty easy.
If I am playing music videos, and Spout Receiver is playing as a Video Effect on the master deck, covering my music videos. If I double click the Skin Main Deck window (it was to get back my larger Output window back). That will turn off the main screen (expected, that is the fumble). But when I double click it again to activate Video, ad get my Output window, Spout Receiver is displaying all Black. If I turn Spout Receiver off, I see my Music Videos. Turn it back on, Spout Receiver is still black.
I basically have to restart VDJ to get the Spout Receiver working again. I know this is not a typical use case, but it can happen pretty easy.
Posted Fri 08 Jan 21 @ 1:31 am
Nicotux
Yes there are still some issues with status changes (maybe fixed in some early versions)
and strange result depending on format and track in deck or not
no need to restart VDJ, only restarting plugin is enough
switch it off, close the gui, choose another plugin, then select SpoutReceiver64 plugin again
and strange result depending on format and track in deck or not
no need to restart VDJ, only restarting plugin is enough
switch it off, close the gui, choose another plugin, then select SpoutReceiver64 plugin again
Posted Fri 08 Jan 21 @ 1:45 am
