I’m trying to stream an EX9.Texture over network with TCP protocol. I red the documentation page and looked at the girlpower example but, as listed in the patch, “some frames will be dropped or even the whole stream will be received wrong. Some more logic will be done…”
I saw only now that the example in girlpower launches a cmd window with /c argument and if I move the cmd window foreground the stream works fine. I don’t understand what is the function on the cmd window.
That’s just a link to a patch, which path you can see in the title bar once opened.
Then on my senior machine - read it old - if I put any other non vvvv window in front the renderer’s content is quite fine, because it goes to 30fps. If you create a mainloop node and set foreground to 30 fps you’ll see it’s fine.
That said, I really don’t know how to improve fps performances.
Could this happen because original collada animation it’s based on 30fps?
Let’s hope that someone more expert than both of us will give a some tips.
To be honest, I don’t think there’s anything stupid in that patch, or related to that patch. I’d rather say I’m ignorant on topic, thus my question.
Anyway, patch any other content, sound-reactive maybe?, and see if it runs smoothly on “client” renderer with >30 fps.
@@h99: there’s a misunderstanding. I’m stupid not your answer/question! Stupid beacuse I didn’t understand that the streaming behavior was influenced by the fps changing of vvvv in background/foreground mode.
Yeah, you always need one Socket to bind any used endpoint (i.e. address). Only then, one (or many) other Sockets which are connected to that endpoint will be able to communicate over that endpoint.
Technically, it does not matter, which Dealer is binding, this is a design decision you have to do yourself (for example if you send Textures from many devices to one machine, you’d bind the receiver, if you send Textures from one device to many, you’d bind the sender)
ask yourself, what kind of communication is it, if you consider scaling up from the beginning
if it is a 1:1 relation, you might want to use two Pair (Network ZSocket), but trust me, that hardly ever scales well.
if it is 1:n or n:1, you will need to Bind the 1, but not the n
if you find yourself in need of an advanced n:n situation, it will be necessary to dissolve it into a n:1 <-> 1:n situation (kindly helped by Proxy (Network ZSocket))).
A few weeks back I was talking about this Configuration setting in Inspector with joreg. I thought, that it is ok to be only accessible with Herr Inspector, because one has to decide what to bind very conciously, instead of just switching it on and off until it works.
Would it have helped you, if the Bind choice would have been a regular pin?
Yep, If I bind one dealer it works. I didn’t see the configuration pin in the Inspector.
I have to send a texture from 1 PC to 4 PCs. The relation is 1:4 but if I bind the 1 and not the 4 the 1 Dealer node becomes red and nothing works. It works only if I bind the 4 Dealer and not the 1. Something wrong?
Also some frames of the stream drop during the streaming. I try to change texture resolution and fps of the sender/receiver patch but I have always some drops. Any suggestion to fix this problem?
the behaviour you are describing is actually intentional, you unwittingly discovered a load balancing mechanism:
each time you hit send, only one of your four dealers gets the message (like a real-life dealer really, only one player gets a specific card when the deck is dealt, this is done in a fair and circular way).
so a quick fix would be to simply select your raw payload as many times, as you have recipients (4 in this case), so each recipient gets a copy of “the card”.
however, your scenario would probably be served better, if you use a publisher/subscriber pattern, where receivers can express interest to the sender, and everything else is done automatically.