MixRack selection at surface boot-up

Forums Forums dLive Forums dLive feature suggestions MixRack selection at surface boot-up

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #123491
    Profile photo of RuneSRuneS
    Participant

    I’ve complained about this in the past but never written it down as a feature suggestion since it borders on being a ‘bug’.

    If you have more than one MixRack on a network a surface will always connect to the last MixRack it was connected to…regardless of what MixRack it is connect to via gigaACE. This is a huge issue for multi-stage venues since you can accidentally connect to a MixRack on a different stage and recall a show file in the middle of their show.
    Surface>MixRack 1>network>MixRack 2 makes very little sense.

    I would highly suggest that one of two things is done:

    1. A surface will ALWAYS connect to the MixRack that it is connect to via gigaACE when it boots up. I can see no scenario where this is not the desired behaviour.

    2. If thats not an option, then you should be able to select what MixRack you want to connect to if more than one is discovered on the network.

    AH supports answer to this is (and I quote): “dLive is not a network device”. Tell that to the MixRacks on our network, or all the installs with dLive and IP controllers and custom control apps.😊

    #123492
    Profile photo of TobiTobi
    Participant

    I have to admit, I dont understand. How can you Connect your Surface to multiple racks at the Same time? Gigaace is a Point to Point connection, so the Surface will Connect to whatever mixrack is on the other Side of your Ethernet Line, and that should exactly be a single Mix Rack?? How is your “Network structure”?

    #123493
    Profile photo of RuneSRuneS
    Participant

    The MixRack is connected to a venue wide network. (for iPad/IP control etc.)
    If a surface is connected directly to the MixRack via gigaACE it will automatically search for the last MixRack it was used with. (through the network connection on the MixRack it is physically connected to. Essentially bypassing the MixRack it is directly connected to and searching the network for the ip address of the MixRack it was last connected to.

    Now, if you hook up Director, MixPad, Mixing Station etc., you will obviously be able to select the correct MixRack from a list of devices on the network. This is not possible with the surfaces unless you manually disconnect the MixRack from the network by pulling the cable out, the connecting the surface to it, and then reconnect the MixRack to the network.

    This means that two or more dLives cannot exist on the same network unless you have dedicated surfaces that are only ever used with a singular MixRack, or you make sure that no engineers ever load a show file before checking that they are connected to the MixRack they are physically connected to. (are challenge with 9 stages and gear that gets carted around between those stages.

    In conclusion, the MixRack it is physically connected to via gigaACE should of course always be the MixRack it connects to.

    #123495
    Profile photo of TobiTobi
    Participant

    Are you using Network switches in gigaace or what do you mean with “The MixRack is connected to a venue wide network.”?

    #123497
    Profile photo of BrianBrian
    Participant

    I think in his example the Mixracks are all connected to the facilities data/computer network via the standard network port on the Mixrack. The surfaces are not connected to the network, except by their GigaAce connection to the Mixrack. What he is saying is that even when the only connection made on the Surface is the GigaAce connection to the Mixrack, if that wasn’t the same Mixrack it was last connected to, it will connect to the other Mixrack by default. That sounds too crazy to be true, but apparently that is what happens and I can completely understand why this would be a problem!

    Here is another attempt to describe what is happening…… if Surface A was connected to Mixrack A for an event, but it’s a new day and now Surface A is plugged into Mixrack B for a different event (and the GigaAce connection between Surface A and Mixrack B is the only connection being made to Surface A), Surface A will still connect to Mixrack A instead of connecting to Mixrack B which is the Mixrack it is physically connected to.

    I agree that it is a design error/bug that needs to be fixed. I’m sure it’s not super common, but it isn’t “right” or expected behavior and should be fixed.

    #123498
    Profile photo of RuneSRuneS
    Participant

    I realize it is not super common, but it is definately something I worry about. Even though I’m usually careful I almost loaded a show file during a show on a different stage. I was lucky that the meter on a channel moved and caught my eye. Same thing with the lack of write protection on showfiles. It might not be an issue for some, but when you have a bunch of engineers on a bunch of stages that just need to have the same starting point every time, it sucks when the file is overwritten.

    #123508
    Profile photo of SteffenRSteffenR
    Participant

    If the surface would not connect to the last mixrack by default, all others would have a problem after a power failure.

    #123526
    Profile photo of RuneSRuneS
    Participant

    Steffen, in that scenario…the MixRack is still connected via gigaACE and the surface should therefore just connect to…the MixRack it is physically connected to. I have yet to find a scenario where you want the Surface to connect to a different MixRack than the one it is physically connected to via the built-in gigaACE. If you can find one I’d love to hear it, but I think it is safe to assume that it would be an extreme edge case.

    #123534
    Profile photo of SteffenRSteffenR
    Participant

    I just pointed to a possible problem if the default behaviour will get changed without precaution.

    I believe, it is not that simple to identify the network port the mixrack is connected to.

    #123536
    Profile photo of RuneSRuneS
    Participant

    But the default behaviour in your example is not changed. It will do exactly what it did before. The only case where the behaviour is changed is if you want to physically connect a surface to a mixrack with the built in gigaACE ports on both, but actually want the surface to connect to a mixrack it is not physically connected to instead.

    The surface obviously knows whether or not it is connected via gigaACE or not since this enables a number of features…like displaying on the home screen whether or not it is in fact connected via gigaACE.

    #123822
    Profile photo of msteelmsteel
    Participant

    I agree that if there is a GigaACE link to a Mix Rack, then that is almost always the one you want to connect to.

    The difficulty probably lies in detecting whether the Mix Rack is the next thing at the other end of the GigaACE connection, or if there are a bunch of highly transparent switches in between. I have sneaking suspicion that detecting what network route the control data is traversing could be surprisingly difficult. Applications usually don’t care about that sort of thing (or want to). They just want to find the other device’s IP address and start talking. But if a change in network layout could be determined, then it would probably work pretty well to ask if (and only if) the network route has changed from last power down.

    I have experimented with using a surface with a control connection only (no GigaACE or audio). If anybody does that regularly, then strictly following rule #2 in the first post would be annoying, as it would require choosing a Mix Rack every time the surface got powered up.

    #123823
    Profile photo of RuneSRuneS
    Participant

    I honestly don’t think that is an issue at all. There are other elements in the eco-system that require this information to function properly. Also, certain functions are not available on the surface when it is not connected via gigaACE. And if that wasn’t already the case, if nothing else, it wouldn’t be much of a stretch to have a few packets that lets the surface identify whether the audio stream and data stream comes from the same MixRack.

    I think that it is an oversight and since it is very much an edge-case there might not be much of an incentive to fix the issue.

Viewing 12 posts - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.