FX problem after updating a cue

an easy way to rule out the artnet side is to keep both dp's running(thats when you see the problem) and disconnect the artnet output from one of the dp's.
-In this setup both dp's will be online on the hognetwork, and if they are causing this problem themselves, you would still see the problem on the output from one dp(or the other if you change to the other).




-If the problem disapears, you have a problem on the artnet side. -If so, my guess is that your Luminex node gets confused in some way, and tries to swap source back and forth between the two dp's.
(I don't know how the DP ensures "sync". and if they are not 100% in sync a artnet node that is setup to do LTP merging in some way can then be confused. i guess that it might be possible that we can see a little drift between two dp's?! -Why the problem goes away when you stomp, or suck. i dont know, and can only speculate, but it can be that the dp keeps better sync when sucked or stomped as opposed to when the dp gets info about that it needs to calculate the changes in efx when you edit it..based on priority or something. )

However I don't know if this is true, and in any case this will probably be a more theoretical problem than something that you will see in real life since the sync is hopefully better than this, but I guess that in some cases depending on the speed and size on the changes on each value in the dmx packet you could see something like this.
And also the way the luminex node has merging implemented in software can make this "worse".. In some way they need to deside how to switch between sources.. if one source stops.. how long should you wait before you change to Backup source? one packet?(approx 40 ms if streamed at 25HZ) one second? 10 seconds?..
-If one packet.. what happens if you loose a packet due to network traffic? that will make the box switch over, and i guess the switch can look like a "jump" if dmx values are right(or wrong)
-Anyways, there are tons of reasons this could get wrong, but if implemented in a wise way, this should work. And my impression is that Luminex makes reaaaly good products!

an easy way to rule out the artnet side is to keep both dp's running(thats when you see the problem) and disconnect the artnet output from one of the dp's.
-In this setup both dp's will be online on the hognetwork, and if they are causing this problem themselves, you would still see the problem on the output from one dp(or the other if you change to the other).




-If the problem disapears, you have a problem on the artnet side. -If so, my guess is that your Luminex node gets confused in some way, and tries to swap source back and forth between the two dp's.
(I don't know how the DP ensures "sync". and if they are not 100% in sync a artnet node that is setup to do LTP merging in some way can then be confused. i guess that it might be possible that we can see a little drift between two dp's?! -Why the problem goes away when you stomp, or suck. i dont know, and can only speculate, but it can be that the dp keeps better sync when sucked or stomped as opposed to when the dp gets info about that it needs to calculate the changes in efx when you edit it..based on priority or something. )

However I don't know if this is true, and in any case this will probably be a more theoretical problem than something that you will see in real life since the sync is hopefully better than this, but I guess that in some cases depending on the speed and size on the changes on each value in the dmx packet you could see something like this.
And also the way the luminex node has merging implemented in software can make this "worse".. In some way they need to deside how to switch between sources.. if one source stops.. how long should you wait before you change to Backup source? one packet?(approx 40 ms if streamed at 25HZ) one second? 10 seconds?..
-If one packet.. what happens if you loose a packet due to network traffic? that will make the box switch over, and i guess the switch can look like a "jump" if dmx values are right(or wrong)
-Anyways, there are tons of reasons this could get wrong, but if implemented in a wise way, this should work. And my impression is that Luminex makes reaaaly good products!