[msteelParticipant]

I had a few drops, with the DVS which was connected to the DANTE card of the MixRack (I/O port 1).
The problem was solved by setting the dLive clock on the DANTE card and assigning it a frequency of 48kHz.
In the Dante Controller, the master clock is fixed on the DANTE card.

Yes, you must either clock the Dante card from the dLive (by setting “sync to external”) or else set the dLive to clock from the Dante card (in the Mix Rack audio settings).
If you do not, then the mixer and the card will run at slightly different rates, and periodically you will get clicks/pops/dropouts.

If clocking the Dante card from the dLive, then the Dante system will know that the card needs to also be the Leader Clock for the Dante network and Dante Controller will complain if there is some reason that cannot happen (for example if two Dante devices are synced to external).

If clocking the dLive from the Dante card, the card might also be the Leader Clock of the Dante system or it might follow another Dante Leader Clock and pass that clock along to the dLive.

[msteelParticipant]

This reminded me of a thread I read recently. It doesn’t really sound like what you describe, but it might be worth reading just in case, especially since it kind of sounds like the IPv4 known issue comment from Audinate. https://community.allen-heath.com/forums/topic/dhcp-leaking-with-dante-control-bridge-disabled

As far as automatic vs manual addresses, I am not aware of any issues with DHCP and either of the A&H Dante cards I use. I did have a situation where auto assigned IP addresses contributed to a problem with clicks and pops in Dante Virtual Soundcard. There were a lot of pieces to the problem, but the part relevant to addressing was that with a link local address, Windows identified the Dante interface as a “public” network. As a result Windows Defender was more aggressive with its packet inspection. Somehow the packet inspection was causing clicks and pops in Pro Tools, even though neither Pro Tools nor Dante Controller complained. After switching to static addressing, the interface became a “private” network and Windows was not so hyper.

[msteelParticipant]

I remember on some mixing console or another I wanted to accomplish that type of thing and set up two mono->stereo reverbs as “left” and “right” with the returns panned differently. I doubt I had an actual pan control in that case, so spatial location was probably by relative send levels. I doubt the difference was worth the effort. In any case I don’t do that anymore.

[msteelParticipant]

Here are some answers:

1) The DT168 Getting started guide says:

“Preamp control of the DT168 by a dLive mixer requires dLive
firmware V1.8 or higher and a dLive M-DL-Dante 64×64 or 128×128
card. Use of the iLive/GLD M-Dante card is not supported.”

So, I’d say that is a yes.

2) Not entirely sure, but the fact that control requires a Dante card, seems to indicate that the preamp control is through the Dante network.

3) All of the control network ports build into the Mix Rack and Surface(s) are bridged together through the GigaACE link(s). This is useful in some cases where the dLive system itself is a small self-contained network. But in cases where you want to connect the system to a building network, say for iPad control through existing Wi-Fi infrastructure, then only one of the devices should be physically connected or you will create a network loop. Logically, all the devices will be on the network and will need IP addresses compatible with the network either through DHCP or through static allocation.

4) As best as I can tell, preamp gain is not directly available on the IP8, even for Mix Rack preamps. Any preamp control through the IP8 would be by recalling a scene. Conceivably you could set up a whole bunch of scenes with appropriate recall filters and toggle through a small number of fixed gain settings for each channel.

5) I haven’t used Shure integration. But some it would make a difference whether your Shure devices are using the same VLAN for control and for Dante, or separate. The dLive Dante card can be on a separate network from its control network, so there are multiple possibilities depending on how your networks are set up, and whether they are routable to each other.

6) Don’t know this one. If I had to guess then I would think the association would be saved in the show file, and associated with the “socket” that belongs to the I/O Port and channel of the Dante card. Routing things differently in Dante Controller would probably mess things up, but patching the socket to a different processing channel would probably “just work.” Since the surfaces to not do any processing, all processing happens on the Mix Rack, and as such changes there will apply to all surfaces and IP controllers that use that same processing channel.

7) Read the “Multi Surface” document to get an idea about how that works to use one Mix Rack for FOH, Monitor, AND lobby. And make sure that works for you.

[msteelParticipant]

I will add that my experience indicates that the clock on our Mix Rack drifts by almost 1 second per day. If you need the clock to be accurate you will need to set it fairly frequently.

[msteelParticipant]

As far as I know, the Mix Rack clock can only be set through an AH-NET (Surface) connection. I believe that Director uses this connection/protocol to connect to a Mix Rack. But if Director does not have the UI enabled to set time-of-day then I do not know of another way besides a hardware surface.

The Mix Rack does have a web server interface, primarily geared toward firmware updates. That is the only other place I can think where there might be an interface to set the clock. See the article here about how to enable that interface if you want to check it out.

[msteelParticipant]

I don’t really know the internal architecture of the I/O slots, but it seems that they have a fixed capacity of 128 channels. To act as a redundant link, you would need 170 channels for a C Class surface and 302 channels to support an S Class surface. The GigaACE protocol and the built in GigaACE port can handle this, but the IO Ports cannot.

As an aside, I believe the same 128 channel limitation is the reason that I/O Ports are not supported by secondary surfaces in a multi-surface setup.

[msteelParticipant]

MIDI includes both a specification of circuitry and cabling to connect one device (keyboard, sampler, synth, etc.) to another, as well as a binary data message format to send on that circuitry and cabling.

TCP/IP MIDI uses the binary message format defined for MIDI and instead sends it over a TCP/IP socket connection, usually from one networked computer to another.

To learn about MIDI (including SYSEX messages), search for “MIDI Fanatic’s Technical Brainwashing Center” and you will find (a mirror of) jglatt’s (nearly) comprehensive MIDI site.
The TCP/IP bit is more in the realm of computer science.

[msteelParticipant]

A note on why I think IO ports are not supported on secondary surfaces:
1) Secondary surfaces are always connected through an IO Port.
2) IO Ports have a limitation of 128 channels in each direction.
3) A surface (primary or secondary) uses some of the channels in the GigaACE link for Mic/Line, AES/EBU and headphone signals.
4) As a result, there are not enough channels left to support an IO Card. If A&H had chosen to allow it, at best the upper channels on the IO card would not be accessible.
(Note that the GigaACE protocol itself and the built in GigaACE ports have a much higher channel count capability than the IO card slots – I believe the white paper on GigaACE says it can handle more than 300 channels in each direction. Therefore it makes sense that a primary surface, using built-in GigaACE ports on each end, can support all the surface Mic/Line/AES sockets as well as multiple IO Ports in the largest S-class surfaces)

Now, if you are actually wanting to put an IO card in a secondary surface, I have not tried it, but I have wondered if it might be possible to use an IO card in a secondary interface anyway.
1) A&H have published some of the channel mappings between a surface’s IO sockets and IO Ports. These appear to be fixed mappings between the surface and its built in GigaACE card.
2) Since these mappings appear to be fixed, I have wondered if the audio might always be sent regardless of whether the surface is primary or secondary.
3) If in fact, the audio is always sent, then it would be accessible by patching from the appropriate channels of the Mix Rack GigaACE card.
4) Because the secondary surface limits the user form patching unsupported channels, routing of this type would need to be done on a primary surface.
5) Also, of course, only about half of the IO Port’s channel count would be accessible.
If anyone tries this out, please report back to the forum because people would want to know…

[msteelParticipant]

I believe that what you are seeing is this:
1) The CDM32 only has one IO port, so as a secondary surface, the FOH must be connected to a GigaACE port installed in Port 1.
2) The signals coming into Mix Rack IO Port 1 are coming from the FOH surface I/O sockets, and the signals are sent to Mix Rack IO Port 1 go to the surface’s headphone jack PAFL and output sockets. As @brian said, IO Ports are not supported on a secondary surface, just a primary surface.
3) The FOH console has detected that Mix Rack port 1 is, in fact, connected to its own built-in GigaACE port. Because it knows this, it also knows that only some of the signals are valid, and it knows what they are. As a result, it does not allow you to route to/from the GigaACE directly, and instead shows that IO to you as surface sockets.
4) The MON console does not know what is connected to IO Port 1 on the Mix Rack. So, it does not do any translation for you, and just shows you that there is a card there and lets you figure out what signal is what on the card.

I would not expect that you would use tie lines in a situation like this. If you are designating channels 1-64 for FOH and 65-128 for MON, then you simply choose which Mix Rack sockets go the those channels. The difficulty that would arise is if you want to use surface IO from one surface on the other/both surfaces. In that case you must do the patching on the surface where the IO physically resides.

[msteelParticipant]

Were you attaching specific MIDI messages to scenes manually, or using the default messages that happen with every scene?

Did you start using surface roles in a multi surface setup? I have observed that for some reason the default messages are not sent when surface roles are in effect.

In the Allen and Heath Midi driver preferences panel you can see the connected status, and there are “lights” that blink with incoming and outgoing messages. That can tell you if the driver thinks any messages are being sent or received.

If the driver appears correct, you can assign a specific message to a scene or a soft key and see if that goes through.

[msteelParticipant]

Strip assignments can be made globally safe. Look in “Other” in the Global Safes and/or Scene filter pages. However, the safes are not granular enough to allow you to safe an individual layer – you can just safe a bank. This same granularity is present in the scene update page too. It sounds like you have already set up layer A in a lot of scenes and want to edit other layers. At this point I can’t think of a nice way to do that and keep your work on layer A. The only way that comes to mind is to edit each scene individually. That sounds decidedly un-fun. Maybe someone else will think of an easier way and chime in.

If you already have (or can afford to spend) a fader strip on top for a band DCA, then you might use the DCA spill feature instead of changing banks.

But in case you have to do a lot of tedious rework anyway to accomplish what you want, I will tell you how I set up the console for theatre. I generally do not change the strip layout from scene to scene. Instead I put DCAs on the top layer where I usually work and where I want assignments to be able to change. Then I change the DCA assignments (and names) on a scene by scene basis. This is partly a holdover from mixers with a fixed layout. But it has several advantages. I can scope DCA assignments individually, making it possible to change the “layout” in multiple scenes at once using the scene update feature. Additionally, it allows me to set a normal level using the channel fader and then all the DCAs end up about 0dB under normal circumstances. Because the channel faders generally stay up, I designate a DCA that is always muted and assign mics there when they are not in a scene.

[msteelParticipant]

I would like to see tighter integration in scenarios like this, but I don’t think it is possible with the published MIDI commands. If you do not have the “Track Embedded” setting turned on, you could try that, but if I remember correctly it does not do what you want either. When using multiple surfaces, the scene selection pointers are not linked between surfaces either. My opinion is that this behavior is tightly bound up in the system design, whether intentionally or simply as a byproduct of design choices.

In understanding how dLive works, it is helpful to remember that Mix Racks and Surfaces are each independent units that have their own set of scene memories. These components then communicate with each other, but that communication has limited scope and the units always remain independent to some degree.

As far as a MIDI command to move the scene pointer, note that you can only make a TCP MIDI connection to a Mix Rack. It then makes sense that the available commands are limited to controlling a Mix Rack. The program change message for scene recall is a bit of an exception, where the Mix Rack recalls its scene and then instructs the Surface to do the same (sometimes. If I remember correctly, when using surface roles in a multi-surface situation, MIDI scene change commands may not get passed along to surfaces).

[msteelParticipant]

There is an “Undo Go” command (RESET+GO maybe?) I wonder what that would do in this situation. Might be worth some experimentation to see.

[msteelParticipant]

One other thing to note about surround mains in dLive, is that the maximum configuration is 5.1. One of our rooms has a system that is (essentially) 7.1, and so in addition to a 5.1 main bus we also need another stereo mix bus to feed the rears.

[Author]

Posts