does somebody around here experience regarding high counts of Bridges and/or active Bridges?
are there theoretical/practical Restrictions?
bridges are connections between gray and blue nodes, ie. links that transmit data via the network.
active bridges are those transmitting data in exactly this frame.
the display of the bridges is mainly for debug purposes. it helps you roughly understand how many connections there are transmitting data. and typically you’d want to keep them at a low count.
hehe
msg too big for UDP; was sent via TCP: /4/14/139/ Scale XYZ
but what explains /4/14/139 to me?
/4/14/139
is the path to the pin
Scale XYZ
given in node-ids as seen from the ROOT.
like this you can identify the location in your patch where this too big message had to be sent via TCP and check if it is really necessary like this or if you can improve your patch.
also note that you can increase UDP package size via Boygroup (VVVV Server) . but be careful with that one. to my experience the higher this package size, the more likely you get UDP packets lost. which may not be a problem at all depending on your patches…
as i already added to Boygrouping:
using midi controllers often leads to high bridge counts.
i experienced a better latency behaviour using a workaround:
use a DMX (Network Artnet Sender) to broadcast the values from your midicontrollers.
use a boygrouped DMX (Network Artnet Receiver) (and some GetSlice (Spreads) )) in your Server Patch to distribute those values on the clients.
Advantages:
*the latency is noticeably lower (maybe Artnet has less protocol overhead)
*less active bridges
*you even don’t have to run those patches on the boygroupserver: take another pc (even some old one) and dedicate it only to be a “Device Server”. obvious that this gains perfomance reserves on the boygroupserver when it doesn’t have to wait for midi-events.
this is also a nice solution to distribute e.g. Audio FFT-data to all servers/clients.