Duplex communication of data among instances

Hallo, I am building a little module that will let me send labels to an instanced patch to recreate a visual represnetacion of my mapped midi controllers.
Using shared memory as a way to transfer a spread of data I am not able to reset the whole spread when evaluating/de-evaluating a patch where only a part of the spread is sent.
Any smart idea?
Not even so easy to explain what the issue is so here a simple patch …
Shared_test.zip (7.5 KB)

Try ZMQ, is more reliable and fast enough

I had some more fun with ZMQ just to try to understand the different nodes and way of communicating data, still far from understand it 100% but I ve got at least an idea of a possible structure for my purposes.

  • there is a main and unique receiver, let’s call it Receiver, which is open in a vvvv instance
  • there are many Senders, they can live in a single instance or in many different vvvv instances, different subpatches some of which may be not evaluated
  • Senders in not evaluated patches should not arrive to the receiver
  • each Sender gets as parameters an ID (this would correspond to an item in my controller) and a string (this is the label for the item
  • when a Sender is created or its parameters changed the parameters are sent to the Receiver, the receiver at this point should reset (so we can clean up residual values from previously mapped strings) then make a call to all active Senders and get their values
  • so the Receiver should both be waiting for data from any Sender and the same time be able to call all the Senders
  • Senders only should send data to the Receiver at load or change and when asked

Bind the pull, and connect your multiple push to it.

A working patch, but there are some issues when I change the Topic (that is a Control Change ID) on a Publisher subpatch.
Tests.zip (16.8 KB)

had a quick look at it.

interesting that you tried to rig your own publisher and subscriber modules by utilizing dealer/router. sure it could work, but maybe you are making your life harder like this.

as feedback: it might be wiser to keep the port stable. right now you seem to open one port per data entry. instead, I would recommend to open only one port, and send packages that contain both an data index, and the actual data entry.

I am not sure, if you are still in need of having multiple receivers. if not, simply bind that single one and only connect all clients.

interesting that you tried to rig your own publisher and subscriber modules by utilizing dealer/router.

I could not create a duplex communication other way

no there is only one master receiver and many “senders”

I used multiple ports as it seemed the only way it worked binding the senders

I´m using this set of nodes,
send, receiver and network (on an extra instance).

ZMQ_Nodes.zip (6.3 KB)

credits: sebl

there is nothing wrong with having one socket for input, and another for output. you don’t necessarily have to do both through one socket.

i guess you would be best of to use the publisher/subscriber. only there, the concept of a topic has been built in.

connect all publishers, and only bind the (single) subscriber. send a package of 2 raws, where the first is the Topic (or in your case, the control change index), and the second the actual value.

The subscriber will receive all of them if you keep the topic-pin empty (or you can use it to filter, your choice).

for the way back, you could also use the same pattern, but inversed. have a single publisher and bind it to a second port, and all sender get a (connected) subscriber to complement the singular publisher. here the topic filtering will make a lot of sense, since data will only be sent when the subscription fits.

yes, that is the way I tend to use it too. Seems to me like one of the most pragmatic patterns. I guess sebl kept it after Elphi ;)

it is using a proxy to forward multiple publishers to multiple subscribers, to get around the fundamental 1:n limitation of zmq.
with this you can send and receive with dedicated modules from whereever to whereever on your LAN or localhost. all you need is a clever topic system

1 Like

And duplicating the Network patch you can create several networks, one local for internal comunication and send data to other system.

Subscriber cannot send, so in my setup as far as I understand can’ t be used, Router and Dealer seems to be more flexible.

I can ’ t use many Routers in the same Port and bind them, I tried binding the Dealer only but that won t work. I also tried to use proxy but I have no idea if that will work with Dealer/Router.

S.

Actually pub/sub is comparable to S/R nodes (but MUCH more flexible). So you just use the publisher for sending, unless I’m missing something?

Sure, I just woke up this morning with that solution in mind …
I simplified everything and now it is just working as I want.
One only little thing is that I miss having a OnUnEvaluate node.
I attach the patches as they are, still need some polishing.
tx
Network.zip (22.1 KB)

glad it worked out.

It should, because the Proxy node is only wrapping the Proxy class from the underlying NetMQ. It helps to channel all Messages from one socket to another without influencing the vvvv Mainloop at all.
Never tried it, though.

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