I have been working on something that would provide similar possibilities as Syphon on OSX on Windows.
Inspired by /dx9ex and Sharedtexture, I started working on a dll that should allow software developers to easily share the necessary data about a shared texture with other applications. I called it Wyphon, and ideally it becomes good enough for other application vendors to add to their software too.
For this I wanted to create a very simple API, so it will hopefully not only stay a vvvv feature. I created a c++ dll, and on top of that I also implemented a WyphonDotNet dll in c# for managed applications. The current source-code can be found here: https://github.com/mrft/Wyphon
I didn’t use the concept of clients and servers like Syphon, but I assumed that there would/should be a high level of trust between the applications that share texture (and in the future maybe other) data, so I used the concept of ‘Partners’, where every WyphonPartner can share textures and can get notified of textures shared by other parties (by subscribing to an event in .net or by registering a callback function in c++).
I also started creating some simple nodes (under Network/Wyphon) that use these dll’s to use in vvvv. The current source-code can be found in my Wyphon branch on github at https://github.com/mrft/vvvv-sdk/tree/Wyphon
But now it is time for some feedback and help from other people.
Did I forget things in the Wyphon.dll? (for example, I think I should provide a lock for each texture to all wyphon-partners, so applications can synchronize their access to the texture)
To give you an idea of what I am talking about, in c# it should be no more than:
using Wyphon;
WyphonPartner wyphonPartner = new WyphonPartner( "<My application name>" );
//if you want to get notified of other joining or leaving partners
wyphonPartner.WyphonPartnerJoinedEvent += WyphonPartnerJoined;
wyphonPartner.WyphonPartnerLeftEvent += WyphonPartnerLeft;
//if you want to get notified when another partner starts or stops sharing a texture
wyphonPartner.WyphonPartnerD3DTextureSharedEvent += WyphonD3DTextureShared;
wyphonPartner.WyphonPartnerD3DTextureUnsharedEvent += WyphonD3DTextureUnshared;
//Start sharing one of your own textures
bool success = wyphonPartner.ShareD3DTexture(handle, width, height, format, usage, "my texture");
//Stop sharing one of your own texture
wyphonPartner.UnshareD3DTexture(handle);
I will try to post a first version here soon for you to play with and see if it can easily be included in md.vis.
I built Wyphon upon another class that just makes it easy to share messages between multiple ‘partners’, and i think I could quite easily create my version of S/R nodes, that would work locally between different vvvv-instances, instead of only in the same instance.
I guess that would also simplify a few things for md.vis (instead of having to send OSC messages to different ports)? Let me know if that would be useful.
[[And another vague idea I had: I am not entirely shure, but I think boygrouping can only be done between different machines because it’s based on ip (and since most pc’s have only 1 ip-address, unless you start messing with vitual NIC’s). Using the same ‘message sharing’ mechanism, I think (devvvvs will know) it should be possible to allow boygrouping quite easily between vvvv instances on the same machine (allowing for better usage of today’s multi-core architectures). But this is probably something that should be discussed in another thread.]([And another vague idea I had: I am not entirely shure, but I think boygrouping can only be done between different machines because it’s based on ip (and since most pc’s have only 1 ip-address, unless you start messing with vitual NIC’s). Using the same ‘message sharing’ mechanism, I think (devvvvs will know) it should be possible to allow boygrouping quite easily between vvvv instances on the same machine (allowing for better usage of today’s multi-core architectures). But this is probably something that should be discussed in another thread.)
after starting the texture sharing test this is the first interesting stuff what tty drops out:
Creating NEW wyphonPartnerForAllNodes
ERR [WyphonNode Evaluate Exception](WyphonNode Evaluate Exception) creating new wyphon partner: Unable to load DLL 'Wyphon': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
interesting because i’ve put everything in vvvv’s own plugins folder also wyphon node was outputting 0 for wyphon id in every instances, a single 0 for partner id in every instances, a single slice empty string for partner names and an empty string for status. after starting the sender the wyphonsendtexture turned red and throwed the same exception as above.
same symptoms were present with S, R nodes too
so i started dependency walker to see what’s really missing. it was msvcp100d.dll, msvcr100d.dll and ieshims.dll which was also interesting because as far as i know ms visual c++ 2010 runtime was installed for me. it couldn’t find it after reinstalling msvcp 2010 so i started to search for those dll’s and placed next to wyphon dll’s manually.
now texture sharing works as it should and i get every partners and their ID’s in wyphon node. however S and R nodes are still not working they don’t miss any dll’s now but both throws an “Object reference not set to an instance of an object.” exception and the R node outputs nothing and the “found” pin is 0.
I’ve tested it on windows 8 x64 with vvvv b29 x86
for features i like how you referencig textures with wyphon receiver (i mean by ID) and something similar would be awesome for the R node too to keep track on which slice coming from which partner or if you put a description input on S node too you can tell which slice is coming from which S node (if the data stacks up to a spread in the R node coming from multiple S nodes with the same name)
update: for some mysterious reason which is beyond logic S, R nodes suddenly started to work. all i’ve done is writing this comment. so i see data from multiple S nodes behaves the same in R as with classic R nodes (the data from last changed S node will be put out in R nodes) so it would be awesome to have a similar “partner” like system as with textures and stacking up data in R nodes coming from multiple S nodes. even by generating ID’s or adding an additional description in for S
Thanks for trying it out! (and glad you got it working)
The S/R nodes I built right now were trying to mimic vvvv’s standard S/R nodes (with LTP), only removing the boundaries between vvvv instances, but you are correct in assuming that I could add some extra pins with extra functionality.
Maybe i will add them (and make them inspektor visible only) in a next version, because it does add some functionality that some people might find useful.
I added S/R nodes for color and double spreads (instead of only strings), and did some other improvements and bugfixes.
I have thought about the extra pins on the S/R nodes, but I think it will make things more complicated.
If you want to listen to only 1 or a few partners (the filter pin in Wyphon receiver nodes), why not add some more R nodes and use different ‘channel’ names, and Cons the output of these R-nodes together?
Isn’t it simpler to keep the way S/R nodes work consistent everywhere?
Anyway, please try it out again, and let me know how it goes at your side.
Now, if we want to get VJ software developers in the loop, I should probably fix the fact that I don’t send the correct Format and Usage values first, and then write an example DirectX application, that’s not vvvv, that is able to send and receive shared textures.
An implementation for OpenGL textures would be cool too, but that does seem to work a little differently afaik (you can share a complete ‘displaylist’ or something?). Then if Elliot Wood’s OpenGL in vvvv is becoming more than a blogpost, we’d be opening up some some nice possibilities here… People who know more about OpenGL sharing features, don’t hesitate to share useful information here.
hiya! i’ve tried to implement it in md.vis to test it in real-world situations so here are the bugs:
wyphon works great as expected that’s good.
now S+R nodes gave me some headache. first “Found” pin isn’t working. it outputs 0 while it obviously receives the right data (i can see the sent values)
also it’s very instable with longer strings (i mean somewhere around above 250 characters which shouldn’t be long) in some situations the R nodes won’t update anymore or the vvvv receiving the data just crashes (VS debugger says: Unhandled exception at 0x66C54B05 (clr.dll) in vvvv.exe: Stack cookie instrumentation code detected a stack-based buffer overrun.). for example i wanted to send 12 absolute paths by the S string node and the receiver didn’t make it.
oh and i almost forgot sending constantly changing values (be it double, string or color) consumes unreasonably high performance
here’s with md.mix:
and here’s with the provided help-patches
another feature request: can you make S+R nodes for the new Raw datatype (System.IO.Stream) as well? much faster sometimes if you deal with a lot of numbers or strings.
keep up the good work!
Idea, how about merging the different S an R nodes and add a scope pin. Patch and subpatches, parent patches, local computer and if made at some point - network.
oh yeah i’ve also noticed with the main wyphon node that changing the Name input pin will produce duplicates of the partner id’s and names. those spreads will be repeated as many times as many times the Name input pin is changed until i won’t start another partner. also exiting a partner meanwhile this bug is present will remove only the first “instance” of the closed partner from the buggy spread.
also changing the texture description in the wyphon sender node won’t update in the receiver until i reload (alt+right-click or CreateNode) the sender node.
Hi microdee, thanks for wanting to be the alpha tester :)
Bigger spreads were indeed not possible, max message size was 1024, which was plenty for Wyphon, but not for sending spreads of course :) And the ‘Found’ pin didn’t do anything, just copied from Vux’s nodes, hehe. I removed it…
New version soon…
I am not sure the high debug numbers you see are real (do you see this reflected in processor usage or framerate drops?).
Some of the other problems you mentioned might have been solved already, but I will check.
Wyphon node was basically the same version as in the first zip.
I successfully created a D3D11 Wyphon receiver based on some of Microsoft’s D3D11 examples I downloaded somewhere, but the strange thing is, it will only run from VS, not if I want to start the exe from explorer (throws an error and I am forced to end the application). So no Wyphon examples that are not vvvv yet…
Creating a Wyphon sender seems a bit more complicated if I want vvvv to be able to use the texture, because the texture then must be created first on a D3D9ex device (by the D3D11 application), and then opened in D3D11. Once I’ve got this working, I probably could add some helper functions to Wyphon that would do this for you. This way we would have enabled the sharing of textures for the weakest of all possible partners.
here’s the latest version, which seems quite stable.
It was quite easy to implement my own Wyphon-sender and -receiver based on Microsofts Direct3D examples.
The only thing that doesn’t work yet is showing that texture in vvvv, although I created it on a D3D9ex device, as far as I know, and my D3D11 receiver successfully uses it. Seems D3D9ex is very limited in what it can share, like colour format etc. So there’s a few more things to figure out in order to make vvvv successfully open a (dx9ex) shared texture that was created by a D3D11 application.
Please report if it does or doesn’t work for you.
EDIT: 1/02/2013 There was still an ord2enum node between WyphonReceiver and SharedTexture that shouldn’t have been there…
In attachment you will find 2 simple applications that will help you to test Wyphon functionality. They are some kind of proof of concept that sharing textures between D3D11 (the examples) and D3D9 (vvvv) applications actually works.
It could also be useful for people wanting to implement Wyphon in their own application, to test if their server, or client actually works. I should release lib-files also for people that want to use Wyphon.dll from c++ (and some documentation).
Have fun.
Remark if you are trying to use this in combination with vvvv: at this time there seems to be a bug in the SharedTexture node, that sometimes causes textures not to be loaded correctly.
More news: I managed to compile AND make everything talk to each other on 64bit as well, which means you can even share textures between 32 and 64 bit applications.
As a proof of concept I created 2 versions of the simple example programs, and I updated the example plugins.
You will see that you can share textures from the demo-app to vvvv, or the other way around, and you can do this from and to the 32bit or the 64bit app.
Hope you like the sound of this as much as I do :)
So, without further delay, here are some example files… let me know how it goes.
