OK, I have a more precise idea of what are you trying to achieve now.
In that case yes, a remote server to "repeat" the incoming mocap payload would be the way to go.
I don't know if you are familiar with the network layers model, but here's a simplified explanation of the problem:
OSC is an application layer protocol, it uses a simple model to pack different types of datatypes, so they can be decoded in the other end, for example take this simple message that the chordata system would use:
000:2f43686f 72646174 612f712f 68656164 /Cho rdat a/q/ head
016:00000000 2c666666 66000000 3dcccccd .... ,fff f... =...
032:3e4ccccd 3e99999a 3ecccccd >L.. >... >...
What you are seeing here is an hex dump of the message, on the right you have the ASCII representation of the contents. The OSC specification is a good reading to understand this more deeply, but for the time all you need to know is that this blob of data can easily be transported by many underlying protocols. For local communications UDP is normally used. In your case TCP would be a better choice, and it's easier to implement in remote servers because is the basic protocol that make the internet work.
So your first concern would be to create a server that accepts incoming messages like this one. It doesn't even have to worry about which type of message it is, because it won't be doing any decoding. The server will also need to accept downstream clients and forward any incoming message to those. If you have no idea on how to do that search for "simple websocket chat" and you will find many examples.
With that done you would need to create two nodes for the blender addon:
Websocket output node:
This one will be connected to the output of the armature node, receiving messages with the already calibrated armature. It should be able to:
- Establish a connection with the remote server
- Take any incoming message and send it to the server using websocket
Websocket input node:
This will be placed at the beginning of the tree, acting like the current Notochord node, so triggering a tree activation after each incoming message.
At the implementation level this node will take most of the code from the Websocket output node you created and the current Notochord node.
The message decoding logic is already implemented in the addon, so you shouldn't worry about it, just take each packet as a closed entity and make it arrive to the other end.
So yes, it is not a simple taks. But it's not implossible either. Of course we are planning to include something like this in the official Chordata framework, but it will take some time to arrive. If you want to use it now I would encourage you to give it a try at building it yourself, I would be happy to assist you in the process
