I am trying to simplify and create some redundancy with QLab and LX Console.
If I set up a couple relay cues (i.e. SUBS) in QLab they fire fine via my ODE and Artnet out of QLab 4. If I open an existing file with cues and artnet hooked up to the same ODE it makes the DMX relays flash.
Do I need to make different NODES or something so that both QLab and LX Console can share the DMX output of the ODE?
DMX from both QLab and LX Console
DMX from both QLab and LX Console
Mark Nizer
mark@nizer.com
mark@nizer.com
The ODE will not merge Art-Net packets coming from the same IP address. What will happen if you try to use two Art-Net sources from the same computer is that the ODE will output the levels from the last packet received.
When not actively changing levels, LXConsole sends an Art-Net packet about once a second. Assuming the second controller software does the same thing a fraction of a second after LXConsole. When the ODE receives a packet from LXConsole, it outputs its levels. A fraction of a second later, the ODE receives another Art-Net packet from the same IP address, but originating from the second controller software. Not knowing that this is from a different source, the ODE switches to the new levels. The remaining fraction of a second later, the ODE gets another packet from LXConsole. So, it dutifully switches back to those levels... The result can be flashing output if the levels from the two sources don't match exactly.
Theoretically you could do what you are trying to do using sACN as long as the network interface is capable of merging different sACN sources based on CID, rather than IP address. If the sACN priorities of the sources are equal, then the node would likely merge the two streams HTP. This sounds like what you are trying to do.
sACN has two concepts that are not available using Art-Net. First, an e1.31 packet contains a unique identifier defining its source. Art-Net is dependent on the IP address of the sender to distinguish between sources. Second, sACN has the concept of priority which is lacking in Art-Net. A source with higher priority can "take control" from a lower priority source. The lower priority source is ignored while the higher priority source is sending packets. This means that you can do things like take control of a system from an auxiliry workstation. Or, you can have a backup controller sending packets on the network. While the primary controller is functioning, these backups do nothing. But, should something happen to the primary, after a short time, the lack of higher priority packets will cause the backup to assume control of the output.
I have used the latter example with two computers running the same show using LXConsole. The primary computer is set to send cue//start OSC messages to the backup so it stays in sync with the show, just following along. Because its sACN output is set to a lower priority, it has no effect on the DMX unless something were to happen to the main computer. At that point, the operator can just switch to the second computer to run the show on backup as if nothing had happened. (I should note that although this works in testing by deliberately disabling the main computer, I've never had the main computer or LXConsole crash and the backup save the day for real)
When not actively changing levels, LXConsole sends an Art-Net packet about once a second. Assuming the second controller software does the same thing a fraction of a second after LXConsole. When the ODE receives a packet from LXConsole, it outputs its levels. A fraction of a second later, the ODE receives another Art-Net packet from the same IP address, but originating from the second controller software. Not knowing that this is from a different source, the ODE switches to the new levels. The remaining fraction of a second later, the ODE gets another packet from LXConsole. So, it dutifully switches back to those levels... The result can be flashing output if the levels from the two sources don't match exactly.
Theoretically you could do what you are trying to do using sACN as long as the network interface is capable of merging different sACN sources based on CID, rather than IP address. If the sACN priorities of the sources are equal, then the node would likely merge the two streams HTP. This sounds like what you are trying to do.
sACN has two concepts that are not available using Art-Net. First, an e1.31 packet contains a unique identifier defining its source. Art-Net is dependent on the IP address of the sender to distinguish between sources. Second, sACN has the concept of priority which is lacking in Art-Net. A source with higher priority can "take control" from a lower priority source. The lower priority source is ignored while the higher priority source is sending packets. This means that you can do things like take control of a system from an auxiliry workstation. Or, you can have a backup controller sending packets on the network. While the primary controller is functioning, these backups do nothing. But, should something happen to the primary, after a short time, the lack of higher priority packets will cause the backup to assume control of the output.
I have used the latter example with two computers running the same show using LXConsole. The primary computer is set to send cue//start OSC messages to the backup so it stays in sync with the show, just following along. Because its sACN output is set to a lower priority, it has no effect on the DMX unless something were to happen to the main computer. At that point, the operator can just switch to the second computer to run the show on backup as if nothing had happened. (I should note that although this works in testing by deliberately disabling the main computer, I've never had the main computer or LXConsole crash and the backup save the day for real)
Great info...
I don't have the channel patched that I am sending from QLab in LXConsole so I thought that that would keep it from messing with it.
Maybe I should patch it to something NOT the same?
Maybe I should patch it to something NOT the same?
Mark Nizer
mark@nizer.com
mark@nizer.com