To be honest I haven’t tried it with MultiBoygrouping yet and I am currently a little busy and can’t test it right now.
But I think you “just” have to specify a different _Network Port _ on Boygroup (VVVV Server) for every instance running as server. Then startup the client-instances with localhost + port of every server-instance they should be assigned to. Like this:
i didn’t check all the details here but just to confirm that the obvious 2k limit of the SharedMemory (Windows) was a bug. anyway we should set it to legacy and provide new Reader (Raw SharedMemory) and Writer (Raw SharedMemory). next you’ll ask for a way to sync them…
internally each of the nodes holds an open handle to the specified location name with a default internal size of 2k. if you resize a location to larger than 2k all of the handles need to be closed first which a single node cannot do if you have a second node open pointing at the same name. see? so as long as you have only one instance of the node (which does not make much sense but still…) you can go > 2k in bytes (but also only with latest alpha). if you have two instances looking at the same name you can only cross 2k if for a moment you point the other instance to another name or even delete it.
anyway that node should be legacy soon and here are the new ones:
Reader (Raw SharedMemory) and Writer (Raw SharedMemory). now we could implement the reader to always only open the handle for reading and then closing it again but i tried that and it costs quite some performance. so i rather introduced a Read and a Write for you to deal with this manually. also syncing should be there and the reader has a helppatch.
from skimming over the thread i understood that (if this is working) this would already solve some issues?
@h99: since the nodes are not depending on each other order of execution is not determined in this scenario. if you alt+rightlick the reader you’ll see that it evaluates after the writer and returns the result in the same frame…