ReceiveSpoutTexture: Auto detect available textures (Stride.Textures.Spout )

Using the ReceiveSpoutTexture would be much more comfortable with an automatic detection and dropdown of all available/active textures. E.g. Isadora or MadMapper do automatically set the name of the Spout Sender and do not even show there name in the programm (Isadora “Isadora: Stage 1”, MadMapper “Projector-1”). So currently you need to use another program to detect the name of the Spout Sender to finally enter it to ReceiveSpoutTexture-node.

indeed, something was missing there. did a bit of an overhaul, so now we have:

  • SpoutSender (was SendSpoutTexture)
  • SpoutReceiver (was ReceiveSpoutTexture, now auto-receives active sender by default)
  • SenderNames (new, returns a spread of available sender names)
  • ActiveSender (new, returns the active sender name)

please test-drive this with the latest vvvv gamma 2021.4 preview >= 187 and report your findings.

note this still does not have dynamic enum (dropdown) to choose available names on the receiver…still considering that…

4 Likes

Back from holidays had a test-drive. Works like a charm so far and I also like the “Use Active Sender” Pin which is set active by default. Was just a little confused first moment when I was using the “SenderNames”-Spread and wasn’t aware of the new Pin – but I think it’s the better solution as probably more of the times you will not use multiple Spout-Textures but one.

Screenshot 2021-08-09 152045

Uuups, further testing, I have to submit a “bug”: If you change the texture source “on the fly” in the SpoutSender by connecting another source to the pin, it stops sending. You have to refresh on the receiver side afterwards. This also causes a problem if you are receving the texture in another software as you can see in the third screen recording.

Screen recording describing the problem
changing the input source by relinking (within vvvv only): vvvv-spout-test-recording.zip (1.6 MB)
changing the input source with switches (within vvvv only): vvvv-spout-test-recording-2.zip (958.0 KB)
same problem receiving the spout texture in another software: vvvv-spout-test-recording_isadora_2.zip (1.9 MB)

hey benju, sorry for the delay!

i’m afraid to my understanding this is a limitation of spout. changes on the sender side are not automatically triggering an update on the receiver side. so either you know your source is changing and you also update the receiver, or if you don’t know, update the receiver periodically to reflect changes on the source.

do you have other experience with using spout in other software?

Hey joreg,

i’m afraid to my understanding this is a limitation of spout. changes on the sender side are not automatically triggering an update on the receiver side. so either you know your source is changing and you also update the receiver, or if you don’t know, update the receiver periodically to reflect changes on the source.

I gave it a tetstrun again and I think then the “best” solution is to collect the textures in a Renderer before sending them straight to Spout, or?

So either for Stride: FullscreenQuadRenderer → RenderTexture → Spout
or Skia: Renderer(Offscreen) → ToImage → ImageToTexture → SpoutSender

Stride works pretty good with the performance whereas in Skia, probably due to expensive translations the performance drops pretty fast when raising the resolution.

Spout:
spout_stride_help_bnj-Application_2021.08.25-21.54.27
spout_stride_help_bnj.vl (35.2 KB)

Skia:
spout_skia_help_bnj-Application_2021.08.25-21.52.26
spout_skia_help_bnj.vl (39.9 KB)

do you have other experience with using spout in other software?

Actually, I’m not so much using Spout so far. But in other programs they usually anyway define one output as spout texture, not switching directly between different textures, so kind of the same concept as collecting them in a RenderTexture, I think…

well, yes, it introduces an extra renderpass, which most likely you won’t notice. so if that suits your usecase, it is a good solution.

yes, any use of TextureToImage (which makes a copy from CPU to GPU memory) will always be slow. having said that, there should actually be a way to circumvent this copy at some point. but for now this is what we have.

note though, that at least when sending from Skia, there is a faster way: use SkiaRenderer → RenderTexture → SpoutSender

(and: you had a weird connection in your patch: the IOBox set to 640 (width) was connected to the TextureToImage “Frame Delay” input, which didn’t make much sense.)

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.