we’re using the spout plugin heavily with resolume and it’s just great + works a lot better than previous solutions, thanks a lot!
I know a lot of fellow vvvvers have built their own vj frameworks for their animations, so have we, now one feature that would be nice would be the ability to share some parameters along with the texture: strings, int/float. bang/toggle. this way we could control the most important parts of vvvv animations from another app’s interface (including their abilities to animate, midimap or beatsync parameters).
this could also open up more possibilities to share (adjustable) vvvv animations with non-patchers.
Now as FFGL sources generally support parameters, and after reading this https://discourse.vvvv.org/t/13966 I realized there’s a quick hack of doing this by packing the parameter values in one (or more) of the unused SharedTextureInfo members…but when i ran into troubles compiling the unchanged FFGL receiver in VS2015 I realized I’m probably not the right guy to do this, hehe ;)
so, how hard would it be to do this nicely?
I’m still up for trying this myself with some major dev hint where to start ;)
+1 for:
-variable number of parameters per parameter type
-dynamic number of parameters (when switching patches in vvvv), not sure if even supported by FFGL
-also sharing layer alpha, speed, rgb and other common vj app properties back to vvvv
-option to design the UI of the FFGL effect (wrong forum I know)
OSC might be the most easy solution for you I guess. I you are into writing your own FFGL effects and sources, than maybe with SharedMemory? I’ve tried sharing values in memory from/to compiled C# application and it works well.
If this does what you have in mind, there is already a FreeframeGL controller plugin and it would be a matter of making a controlled VVVV sender.
I have to say it is not a quick job (neither would using OSC I suspect). From what I can see it would require some C# programming to interface with C++ code. I am not personally all that familiar with C# and can’t immediately see how that would be done but I will look at it.
hey, thanks @id144 and @leadedge, spout controls is exactly i was looking for! I did quite some stuff with c# and c++ interop recently, I will report back asap if I’d be able to do this, let me check!
yes, i think I should be able to do this! Here’s what I’m trying to do, please correct me if I’m wrong:
-export functions to create, open, update and close Controls from SpoutControls.dll, then recompile (mostly done!)
-import the dll in the sender node and call the exported functions
This sounds excellent. It sounds like you have already used “SpoutControls.cpp” and “SpoutControls.h” within your C# project, so it is likely that it is close to working.
Once your sender has used “CreateControl” for as many controls as you have and finally “OpenControls”, it is all done. Then your sender will use “CheckControls” to listen for any changes by the controller, and that is all that should be needed.
But you don’t import “SpoutController.dll”.
This is what you will use in Resolume to see the final result. It is a Spout receiver FreeframeGL plugin which adapts it’s parameters to the controls you have set up in your sender. When you change these parameters they are picked up by the sender and the changes are immediately received back again by the plugin. So it appears to the user that the sender “isn’t there” and the plugin is working by itself.
For testing you can use “SpoutController.exe”. It’s sort of like a GUI dialog. Just start it up and it should adapt itself to the controls you have set up for your sender.
When you change a control, the vector of controls is changed and set to shared memory. Then a signal is sent to the sender to read back the result and you should get the changed values.
I can’t go into too much detail here, but maybe I can help further by email. Get the email address from my GitHub (https://github.com/leadedge). SpoutControls is there as I am sure you have found.
hey, sorry, this has been a mixup in my post: I’m doing another dll, let’s call it Spout4vvvv.dll, which includes SpoutControls.h and exports all the functions needed for access in vvvv. that’s the dll I’m importing in vvvv.
If that is correct I’m almost done, actually everything should be working by now except for retrieving the values back in vvvv, which I’ll sort out asap…
…however, while trying to test if controls get created I realized that the latest update to spout in vvvv broke it’s functionality in resolume, causing resolume to crash every time as soon as I drag the source on a layer…will have to test again tomorrow and eventually report the bug before I can proceed (at least with resolume)…
My mistake - wrong dll name. A dll should work fine. You will only need to export the functions for a sender.
When you have the controls set up, run your sender once and look in “…\ProgramData\Spout” you should find a control file with your sender name there. If it is, use SpoutController.exe for testing.
-only using SpoutController.exe, as my DXInterop seems to be broken, I assume since Windows 10 (+Graphics) “Anniversary” update…need to investigate…
-with x64 version vvvv crashes as soon as I open Spoutcontroller.exe
-I’m confident I’m doing the Interop from C# to C++ correct (ie initializing the controls) as I did similar things before, however, the other way round (getting the changed values from C++ to C#) I’m not so sure ;) it’s possible I’m leaking memory here somewhere, but I’m not sure how to properly test that, nor can I find good examples right now…
got to finish another project before working out the bugs, maybe somebody with more experience with dll import/marshaling can have a quick look if it’s ok, I’ll attach it here. The plugin actually just adds functionality to the normal SpoutSender node, which means if everything is working correct it could possibly be added to the core module (eg enabled via config pin)…but for this I guess some code improvements would be necessary too, hehe…
to test it please download the attachment, copy the Spoutcontrols4vvvv.dll in /dependencies/PLATFORM to your vvvv directory (next to vvvv.exe; as I said for me only x86 works atm, but maybe you are lucky ;)), then open the help patch.
(For everybody else except leadedge: If you do not have the SpoutController.dll yet please go to http://spout.zeal.co/download-software/, download SpoutControls and see here http://spout.zeal.co/download/SpoutControls.pdf how to use the Freeframe Plugin in eg Resolume)
here is the source for SpoutControls4vvvv.dll:
…will make proper release as soon as I find time to work on this again, if anybody tests this please report your findings!
A lot of work here. It’s good that you have been able to achieve what you set out to do.
I can’t get the example patch to do anything, but I might misunderstand the whole thing.
As for the crash with SpoutController.exe. Strange that nobody has reported this before. If the Freeframe dll works, it must be a bug in SpoutControls.exe itself.
It could be a permissions problem. I have found recently using Windows 8 that admin privileges are required to write a configuration file to “ProgramData\Spout” and permissions have to be set up by the installer.
I will update the installer soon, but meanwhile run as Administrator and see what happens.
Another thing to try is copy the configuration file that you have created in “ProgramData\Spout” to the same folder as “SpoutController.exe” and rename it to “SpoutControls.txt” and see if that works.
@leadedge: please note, I can’t say if the ffgl is working (yet), as I first need to figure out what happened to DXinterop on my computer- I could only test with spoutController.exe until now…
also, vvvv x64(!) will crash when I open spoutController.exe, but spoutController stays and seems to have initialized controls just fine, so atm I don’t think there’s any path problems(?)…I’ll report new findings asap (in about 1-2 weeks)! thank you!
No problems. Again I did not read your post properly. I am not sure of the cause of the crash, but when you get back onto it you might find out or give me some idea.
As for the DXinterop problem I am not sure what that could be. I assume that the basic spout functions don’t work. Most problems people report come back to laptops with Optimus graphics. If that is likely for you there are plenty of examples on the Spout forum or we can work it through there.
had some time to work and this, installed new graphics drivers which got my dx interop working again and found that it’s actually working fine with resolume!!
there’s two ways i got this to work, either by copying a full vvvv copy into a resolume plugin subfolder /vfx/myplugin; renamed vvvv.exe (+corresponding files) to myplugin.exe, then started resolume, dropped myplugin on a layer and vvvv would start. tested with multiple instances, works. very nice! OR you copy only spoutcontroller.dll and myplugin.txt into /vfx/myplugin and start vvvv from wherever you like, works fine too. spoutcontrol4vvvv.dll need to lie next to vvvv.exe for both ways to work.
@leadedge: while i really like the workflow to have each source start it’s own exe (and close it again) it’s unfortunately not very suitable for vvvv (being >700MB). The great benefit of this (next to performance improvements if done right) however is to have a custom number of controls with custom labels for each source/vvvv animation. If on the other hand i load animations dynamically into only one instance of vvvv I can not change the control names or numbers dynamically in resolume; forcing me to have generic names like slider1- slider4. I found a workaround by automatically copying the myplugin.txt from C:\ProgramData\Spout to vfx/myplugin when it’s changed and then manually reloading the source in resolume…however, if you intend to update spoutcontrols at any point it would be great to have some kind of refresh button to re-read the txt (or refresh if the file changes).
i will upload a slightly newer version with a smal memory fix as a first alpha release asap.
bad news is 64bit is still not working and i have no clue why…
@leadedge: after some further reading my best guess for the x64 vvvv crash atm is that the spoutcontroller.dll is 32bit and as i’m passing values via pointers, which are different in size in x64 and x86, this might cause the crash…do you think that’s possible?
The second way of working seems to be the best. The idea was developed with Processing in mind and all the file names are the same as the subfolder containing the sketch, dll and control file. You can rename SpoutController.dll to the same name as well for other Freeframe host programs that require that.
The crash is almost certainly due to 64bit/32bit pointers. You might look at pointer conversion helper functions :
I looked at reloading the control file and re-starting. Unfortunately the limitation is with the FreeFrame plugin itself. Once a plugin is initialized, the number and names of the parameters are fixed and cannot be changed. There is no way to tell the host that they have changed. The plugin has to be reloaded.
Also with your 64bit pointer problem I have found “IsBadReadPtr” etc. to be useful :
ok thanks…the workaround is not too bad, just need to reload in resolume as you say…i wonder if i could write a simple myplugin.exe to place in vfx/myplugin which will start the right patch in one (of several) already open vvvv instance; then the original (processing) approach would be valid, one ffgl source per animation, which would also mean specific controls per animation…might give that a try…
64 bit still no luck, going to drop you a mail with what i’ve found + do a 32bit only release now, hopefully somebody here is able to help…
I was wondering what would happen if the controller in some way opened a patch (".v4p"). If VVVV was already open, and a patch was started would this activate your dll?
At the moment the controller allows for .pde and .exe. For pde files, Processing is opened via processing-java.exe and a suitable command line. exe files are opened using CreateProcess.
yes it would- as soon as you open the patch with the spout controller node in it, the dll does get called…i’m just not sure how to open a v4p in a certain vvvv instance- to make this high performant when possibly mixing 2 (or more) v4 textures/patches you would at some point (depending on the complexity of the animations) need to use several instances; eg, we usually share 3 textures: 2 vvvv instances where we dynamically load one animation each which we can mix, and one more instance, layered on top of the other 2 which we use for global effects like strobe, etc…
