SpoutLibrary : unable to setup multiple named Spout Receivers about spout2 HOT 11 CLOSED

Hi Ben,
The two receivers should not behave like that. I assume that receiver1 and receiver2 are separate instances of the library. Is it possible to make me a small sample in Openframeworks that shows the problem?. Perhaps using the library example. That way I can look at it quickly.

from spout2.

Yes they are 2 separate instances, although I'm not sure what the code inside SpoutLibrary does.
I'm using JUCE so it would be a long way to use ofx, and I'm afraid that it would maybe work on ofx and not in JUCE :)

Basically I'm doing :

SPOUTLIBRARY * receiver1 = GetSpout();
SPOUTLIBRARY * receiver2 = GetSpout();

receiver1->CreateReceiver("tex1",...)
receiver2->CreateReceiver("tex2",...)

If I'm only doing that, I'm only receiving an image on receiver1 if the SpoutPanel has selected "tex1", and only an image on receiver2 if it has selected "tex2".
If I put an empty name for the sharingName, then they both are receiving the selected texture in Spout Panel (EDIT : my code automatically set the "useActive" argument to true if sharingName is empty)

I tried using SetReceiverName, but doing so forces a texture name check for both instances, even if I only do it on one receiver.

I checked that the pointers of receiver1 and receiver2 are different and they are, the FBO generated for them are as well.

Do you have a working example of receiving 2 named textures, even in oF ?

Thank you

from spout2.

I attached some screenshots.
So receivers are set to receive different names, but when I create them, they both grab the same texture : the one in the Spout Panel. "useActive" is forced to false in the CreateReceiver call. When I change the selected receiver in Spout Panel, nothing changes, but when I reload my app, both textures are then receiving the other one (the newly selected one in the Panel).

What's even weirder, is that if I change the names back and forth on one of the receivers, and force it to the name of the active texture, if the other one is not set to the name of the active texture as well, it stops receiving, without changing anything on it !
So I guess there is global variable change in the lib that makes it change behaviour across all instances when doing CreateReceiver (I'm not using SetReceiverName at all)

from spout2.

Update :
I updated to the latest commit, no changes.
I also tested with 2 instances of the app, I get the same behaviour, except that changing one receiver name will not break the other one instantly.
But they all respond to the same active texture, even if I force the useActive to false.

I would test using directly SpoutGL, but because I'm using JUCE and it has its own way of dealing with GL and DX, it's very hard to have them mixed (a lot of redefinitions, conflicts, etc.)

from spout2.

I found the problem using the 2.006 example for multiple receivers.

2.007 methods for receiving have changed significantly. Now you just attempt to receive and if a connection is made, "CreateReciever" is used internally. After that you query for sender details. One important thing is to call "IsUpdated()" every frame to check for sender changes and, if it returns true, update the receiving texture.

The current difficulty is a "cart-before the-horse" problem because the receiver has already been updated with a sender change. Rather than go backwards for 2.006 compatibility, I have created a multiple receiver example in the beta branch. I hope this works for you.

from spout2.

Thank you for this, I changed the code and updated to the beta branch, but same problem : as soon as I change the name, nothing is working anymore. Even worse, even when I set a valid SenderName, it's still black.. only empty name (using active sender) works.
I see that the multiple receiver is working, but the ofMultipleReceiverExample is using SpoutSDK, not SpoutLibrary. I can't really use SpoutSDK as the header are including way too many dx/gl stuff to be compatible with JUCE... The SpoutLibrary is very neat and easy to integrate, but maybe this is where the problem lies..

from spout2.

Ok now I get really weird things :

• I have 2 senders called "test" and "Spout Sender", active texture is "Spout Sender"
• when I set SetSenderName to "" [empty], GetSenderName returns "Spout Sender" and texture size is good
• when I set SetSenderName to "test", GetSenderName returns "test_1" ??? Receive is returns true but texture size is 0x0
• when I set SetSenderName to "Spout Sender", GetSenderName returns "Spout Sender_1" and tex is 0x0 (even though it's the active sender in Spout Panel)
• when I set SetSenderName to "notexisting" [whatever sender name that doesn't exist], GetSenderName returns "notexisting" > no "_1" added to the end ! I thought it could be my way of passing the name variable, but apparently not.. this may be why it works with SpoutPanel but not when passing SetSenderName ?

I managed using SpoutPanel to have at some point 2 different textures in the same app, but it's not usable as I need to setup specific sources and load it from start, not needing to select the source every time I start the project. And using Spout Panel, if you reload the app, they will both reset to the same source as they're getting the active one.

In your of example, you mention that SetSenderName can be used instead of SpoutPanel, but is it actually working ? (I also noticed that the IsUpdated may not be always triggered, at least receiver2 shows some weird dimensions when changing sender)

from spout2.

The example I made is working from my side.

I think the problem could be that SpoutLibrary does not separate sender from receiver. I have not found any way to do that. SetSenderName is for a sender. SetReceiverName is for a receiver.

I really need to see some code that you are using. It doesn't have to be something I can compile.

from spout2.

Ok so double bad for me !

• Using SetReceiverName definitely works better :)
• I had some badly made optimization where 2 receivers with the same name were merged, so then changing one of them wouuld remove the other's reference, and this is why sometimes changing one would change the other one.

It all works perfectly now and it's beautiful to see !
If you're curious about the project, the goal was to have Shared Texture feedback in custom dashboard on my show-control software Chataigne ( https://benjamin.kuperberg.fr/chataigne and https://github.com/benkuper/Chataigne ) so it's now easy to have both control and feedback at one centralized place to control all softwares. Additionally, this is also able to serve and stream to webpages so you can easily access this dashboard from any device (pc and mobile).

Quick demo of the working double receiving and remote control :
https://streamable.com/y3sx23

Me happy !
Thank you very much for the reactive and helpful help, I hope all goes well for you and your son in Australia ;)

from spout2.

I assume that this is resolved. The demo looks impressive indeed. I will close in a day or so unless there is anything else you have found in the meantime.

from spout2.

Yes, this is all good thank you again !

from spout2.