[JayParticipant]

There is an internal scene #65535 that is aways the current state of the board and is the restore point on a restart. Any scene recalled is applied on top of this, subject to filters.

Everything stays – mutes, fader levels, fx, dyn8, everything. I use mute group 8 as a “mute all”, set it before power down, and depend on it to keep everything quite until I’m ready to unmute the system.

[JayParticipant]

Some obvious questions:

1) Your laptop is set for DHCP and acquiring an address, vs static?

2) You are plugging into the network port, not the SLink port?

3) You are looking for the IP address on the status page, not the network page. When the network page shows “DHCP” it never updates for an acquired address, that is always on the status page. (bit me the first time)

4) The DHCP advertisement is “consistent” – the IP/Netmask/Gateway all agree? I don’t know if the SQ validates it, but I could see it rejecting something that is inconsistent. You wouldn’t see this unless you tried to do WAN routing through your router. The XR18 has such a poor network implementation I wouldn’t trust it as a reference point.

5) Set the console to a static address and see if your laptop can ping it.

[JayParticipant]

Rob,

Dante and Wireless get along fine, as long as the wireless is intelligent enough to filter the multicast. I run it in several theaters. However, we also explicitly run a separate control network for consoles.

A couple questions:
1) How old is the ipad? I have an iPad 3 and a current generation. The 3 is sluggish to the point of unusable, regardless of the network connection.

2) Is your Dante unicast or multicast? If you just have the wireless without a properly configured switch, you could pushing multicast to the wireless and back down the Gigaace network tunnel slowing everything down. You would see this on the surface with slow show and scene recalls.

The iPad connects to the mixrack. Disconnect the link at stage between Dante Primary & the MR. Connect the router at FOH to the network connection on the surface (disconnect from Dante). Remember that you now have 2 networks, same ip range, but they are segmented. You can’t plug a laptop into both at the same time and have it work.

[JayParticipant]

Steffen,

Thanks, but the W&D drawings have the same issues. For that one, it has total width & height, height of surface and angles of incline on the display. The side view doesn’t specify the measurements from the front/rear for the center of the angles or the height at different points.

Hoping to find out today from Cloud 9 what they still need.

Jay

[JayParticipant]

One thing to know about dLive scenes – there is a “base scene” #65535 that appears to represent the current state of the mixrack at all times, including bus configuration and items not recallable in scenes. When you save / recall a show, this scene is always saved and is the basis for everything that is global/role safe or masked off by recall filters when a show is loaded. There is nothing you can do directly with this scene, it is always the mixrack state at the point of the save.

It also means, unlike other desks, you can save a show with no scenes stored and still have it recall to the point where it was saved.

Jay

[JayParticipant]

Michael,

More than welcome. I was looking for 2 posts I made, but only found 1.

What I couldn’t find:

From discussions, reading and experimentation it looks like the MR and Surface are each based on an 8 port unmanaged switch without any features enabled (v1.72). If you count ports on MR (S Class), Surface is similar:
– 2 external ports
– 1 for GigaAce tunnel
– 1 for Mixrack hardware
– 3 for card slots
– (maybe other future connections internally)

This matters in an Enterprise environment because, as a switch, it isn’t passing CDP, LLDP, Spanning Tree, QoS tagging, VLAN Tags, Multicast subscriptions/filtering/querier or other management protocols. This means anything entering the dLive network will take bandwidth away from communication between the MR and surface, and this will create a loop between two Enterprise switches if both ends are on and spanning tree is non-existent.

Bandwidth info:

Bandwidth – GigaACE Network vs Direct

Jay

[JayParticipant]

Steffan’s question on “what else is connected” was targeted at A&H, because it will affect the numbers below.

A MixRack, as of 1.72, is sending about 8 broadcasts a second, some advertising and some looking for devices. 4 are advertising its capabilities while the other 4 are searching for IP8, IP6, IP1 and GPIO. This doesn’t include ARP or any other normal network traffic.

A Surface (and Director) will send the same, with slightly different advertising. Depending on what other devices you have, they may also be doing advertising.

Connecting to the network on either MR or Surface will give you all the broadcast traffic from both devices. Do not connect both ends to the enterprise network as you will have a loop that is hidden to the enterprise switches.

Still, with all that, 22 broadcasts/sec (UDP + ~9 bytes) are nothing on a switched network. A windows laptop creates almost as much random broadcast traffic.

You really need to move the dLive system to its own VLAN on your network, but not for broadcast traffic. 2 issues:
(1) You are now carrying all broadcast and unfiltered multicast traffic across the GigaAce IP tunnel. This will directly impact the performance of the surface/scene recall/etc.
(2) The dLive security is through network isolation, not secure channels. Anyone on the network really has access to the system.

Jay

[JayParticipant]

I’ll give you one more option, but it depends on your exact needs. I use it regularly, A&H has confirmed it works, but it technically isn’t a directly support configuration.

If you don’t need Audio I/O at your additional surfaces, you can treat it just like Director and connect the ethernet (not GigaAce) on the additional surface(s) to the Mixrack network connection and you have full control as another role. Pick up your audio (including headphone) off the MR or another surface with a GigaAce connection.

I’ve had running:
– DM64, with GigaAce card and 2x DX168’s
– tied to S5000 via onboard GigaAce, with Wave v3 and Dante cards
– IP8
– ME Hub + ME1/ME500’s
– 2 Directors (1 wireless)
– SQ6 tied to DM64 GigaAce
– C1500 tied to DM64 network (no audio, it came off DM64) and was effectively used as an extension of the S5000

Musical theatre, 40+ wireless + live orchestra

Could the chose to remove the ability to run a surface like this? Sure. Would they?

Jay

[JayParticipant]

I would be wary of feeding ME from broadcast, different room and different focus.

dLive to SQ is via a GigaAce card in dLive, not SLink. SLink (so far) is an SQ-only name.

I’ll throw out another option, realizing this is an SQ group. If you have a CDM48, then you can split that to 2 roles and run FOH (+ME1) and Broadcast off the same unit. C2500/3500 for FOH and use Director+Dell Touchscreen (or IP8) for Broadcast. In this setup, broadcast has gain tracking active against FOH (assuming FOH owns HA’s) and works much cleaner than GigaAce feed to SQx. You still have a slot and DX port open for future expansion. You will want a pair of analog drops to broadcast to feed PAFL (or run it via an ME1/ME500 in stereo).

Jay

[JayParticipant]

Couple items to add in (and clarify):

– For 100MBit you can also use an optical isolator, also called a network isolator. You can get them for gig but they are expensive.

– GigaAce is much harder to route through a switch. There are a number of discussions in dLive forums on how to do this.

– As Stefan said, use a gig switch because it handles the bandwidth issues better, but you also must
(1) lock the port to 100 or SLink will negotiate GigAce instead of dSnake/DX/ME;
(2) disable all the spanning tree, BDPU detection, CDP, etc. or you will hear glitches;

– If you are running DX168’s via a DX Hub, the protocol is GigAce and not DX.

I have ME’s running off a gig switch on dLive. Before I disabled everything (on a dedicated VLAN) there was an audible click at a regular rate occurring.

Jay

[JayParticipant]

I’m on an S5000 v 1.71, but I don’t think this has changed.

With “Insert A” selected –
Left side, middle of the Dyn8 settings it shows “Unit: XX” to indicate what unit is assigned and below that in a box is [ UNASSIGN ] which lets you remove it and go back to the normal selection screen.

Jay

[JayParticipant]

Yep. You turned them off.

Go to Surface -> Audio -> PAFL

Lower right has “Mains to PAFL”, which controls what you listen to when no input/mix is selected for PAFL. It also happens to be what is metered. You have the ability to “route” L/R Mains to L/R/M PAFL so you can skew the meters as you wish.

(this involved a few minutes of panic one day learning this – nothing was coming out of the board … but it was, just no meters)

[JayParticipant]

One other item to check …

Do you let the iMac go to sleep and wake back up with Soundgrid running (intentionally or accidentally)? If I let my MacBook go to sleep with it running, I have all kinds of clock/playback issues with it and have to reboot. If I shut down everything related to SG, then sleep is fine.

Jay

[JayParticipant]

Nicola,

Good to hear. Can I suggest that you allow the option of setting the VLAN tag instead of “removing” it, if I read that correctly?

If you “remove” it, then the switch will have to insert/remove the tag on all the packets that traverse it on access ports. If you allow us to tag it correctly on both ends then the switch should be able to handle it as a trunked port correctly.

Also, is the dscp also being set (or made settable)?

Thanks,

Jay

[JayParticipant]

Millst,

I spent some time playing with Gigaace via a switch, just to see what was involved.

Test platform:
Cisco SG-300, single switch
Only “A” GigaAce between DM64 and S5000, 1.61 FW

Observations:
– Not running jumbo packets
– All packets are L2 VLAN tagged for VLAN 1 <— This will require you change the default switch VLAN off of 1
– Disabled CDP, Spanning tree, BPDU guard, etc. Still received clock glitches
– Ran the VLAN without an IP address to prevent switch-originated ARP requests or other traffic.

Final results (realizing this was just 1 switch with no other traffic):
– Audio was passing & full surface control
– About every 15 minutes there was a “hiccup” that caused the S5000 to show a loss of sync. Clear. Shows back up.
– Bandwidth was too high to do a monitor port to see what other traffic was on the VLAN.

Overall, the most difficult part was the fact they were treating it as a trunk with everything already VLAN 1 tagged. If they would allow that to be set, tunneling of a high capacity network might be feasible.

Jay

[Author]

Posts