[01soundman]

While I appreciate the IT industry reference (I worked for a major computer manufacturer for 33 years), I don’t see that it applies here. This is a unit that ships in a road case with casters. It’s meant to be “out and about”, making “always powered up” a bit difficult. I would think sitting in a rack as it is (see above) would eliminate seating issues.

Said another way: If cards need to be periodically reseated or systems should always be powered up, why is that not also true for the desktop PC industry?

If my desktop PC failed every 30 days, I would not be satisfied when Dell told me I just needed to leave it on all the time and/or reseat the CPU every month or so…

[01soundman]

Just had the third M-DMA ‘failure’ in as many months. Reseating the card resolved the ‘failure’. So much for the “reseat all cards annually” approach; looks like I need to do it every 29 days.

I’ve notified the US sales/distribution contingent of the failure and awaiting their reply.

Starting to strongly suspect a defect in the connectors/planar in the iDR10.

[01soundman]

What follows is an update of where the above took me.

The installer/seller of the system came to my site and we contacted the Tech Support folks for the US Distributor. After several minutes of discussion, I was asked to put the ‘allegedly defective’ module back in the iDR10 and test to see if it worked. Sure enough, it was fine.

When I questioned why this was possible, we were told possible causes were:

The Phoenix connectors have “come loose” before and should always be checked to be sure the cables are not putting tension on them. (Connectors had been checked and replugged prior to call. All connecting cables have sufficient strain relief to put significant slack in each line.)

The card itself can ‘disengage’ from the planar/system board connector even though both mounting screws are firmly set.

Their recommendation:

Check all connections monthly.

Unplug/reseat all cards annually to ensure this doesn’t reoccur.

It may just be me but this seems unreasonable. It also seems to indicate that the card connectors are not fully seating in the planar connectors (in the back) and, therefore, point to a potential (mechanical) engineering defect.

This particular iDR10 isn’t kicked around out on some stage floor or jostled in the back of a road rig. It’s a fixed installation; mounted in a rack on a concrete floor.

Comments?

[01soundman]

Good deal. Haven’t noticed any problems associated with it so I’ll ignore it until I do.

[] RayH

[01soundman]

quote:

---

Originally posted by jeffs7

Hi,

I am having trouble getting ACE to run through a managed switch. Has anybody else been able to get this to work successfully? Did you have to do anything special?

~Jeff

---

You are running the ACE connection through one of the iLive network ports, yes?

Just to be sure…
Ray

[01soundman]

Outstanding!! I just received my CPU upgrade for the iDR10 a few days ago.

Since I’m running a dual-rack configuration, I’d really appreciate someone from A&H reviewing how things are set up today and give me an indication of whether changes are needed before I upgrade to v1.9.

Current configuration:
144 surface (RAB2 w/ACE, M-MMO in port B, and fullsize MMO card in A/B slots because I was going to have to deal with this in v1.83),
iDR-32 master w/ACE in Port B,
iDR10 slave (64 inputs, 8 outputs, RAB2 w/ACE & Dante)

Notes:
(1) The Dante card is used to feed a nearly full complement of 64 channels from a combination of the two racks. Any concerns over Dante firmware version vs. v1.9?
(2) My ideal world would be to upgrade to v1.9 and then use both MMO cards in the surface for dual Aviom (or A&H ME!!) systems.

Thanks for the encouragement, Nicola! Eager to get v1.9 installed!

[01soundman]

Would like to revisit this thread to see if the following is still true:

Follow up: To my dismay, I found the following in the Hardware Reference (v1.7), “part 1-34”:
“Surface Port B and firmware version V1.7. It is possible to fit the M-MMO option and assign its outputs, but note the following:
The Status screen does not recognise the Port B option even if one is fitted. Use the TouchScreen or Editor OUTPUTS screen ACE Link or ESA tab to assign signals to the M-MMO option fitted in Port B. Use CH33 and higher. These are permanently mapped to the M-MMO output sockets according to the table below.”

The “table” shows AVIOM (the object of this little adventure) “Not Used“.

[01soundman]

quote:

---

Originally posted by ahjeff

….(we are looking at revising this option for the next version, to make it more clear). ….

Cheers

– Jeff, A&H

---

PULEEZE make sure to let us know (special flag, bold print, something) if that change makes it into 1.9 when it’s released!

I use this feature to feed a Dante card and want to be sure I don’t upset folks due to channels ‘missing’.

Thanks!
RayH

[01soundman]

quote:

---

Originally posted by Stealth

….. “As gil has pointed out the best way would be to fit the Digital Multi output module to either your surface or …”

---

Thanks, both Gil and Sam.

At the moment, my plan is now to put a Digital Multi Out in the A/B slots of the Surface, remove the M-MMO from the RAB2, and move an existing Dual Mic/Line module from slot A to Slot C or D.

Is that an approved configuration?

Any concerns?

Thanks!!
Ray

PS. Would anyone like to comment on potential latency issues that may arise from the fact that this Dual-rack system has the 144 Surface (& Aviom out) attached to an iDR-32 (master) at FOH with the iDR10 (slave) roughly 130 feet of CAT5E away from the iDR-32. My concern is that band members onstage will hear Aviom IEM signals only after they’ve made the trip from the stage (iDR10 slave) to FOH (iDR-32 master) and then back down another 130′ CAT5E cable to the Aviom hub onstage.

[01soundman]

This is GREAT! Would you puleeeeze consider dual-rack support? If so, I’m more than willing to send you XML files and work with you to hammer out the ability to read them.

Thanks for the work to get this far!!
Ray H.

Dual rack iLive system:
144 surface,
iDR-32 master,
iDR10 slave (64 inputs, 8 outputs)

[01soundman]

quote:

---

Originally posted by Stealth

…. I have added this feature to the request list.

Regards
Sam A&H

---

That’s all we can ask. Thanks Sam.

RayH

[01soundman]

quote:

---

Originally posted by sound

I’m talking about the EDITOR Software – sorry if it wasn’t clear enough (Thread title).

---

Just happened upon this thread and would love to have seen an answer from Stealth/etc. to say how to display the ‘current scene’ as you suggested; other than the Scene Simulation window, where ‘current’ is the one ABOVE the highlighted one if you have Auto-Advance on.

RayH

[01soundman]

Within iLive. Dante is static. (1-1, 2-2, …., 64-64)

[01soundman]

This is GREAT input! Please continue the conversation.

And while you’re at it, help ease my concerns over recall time. Sounds like the way to go is to do an initial ‘store all’ as a “master template” scene, copy that for however many scenes I have (looking like 95-100 or so), then modify each scene as we rehearse/etc.

Here’s the catch: Can I recall these scenes “between syllables”? Having done this show on the analog desk that the iLive replaced, I’m aware of two or three scenes where I’m going to be hitting “Go” when the actor takes a breath… (Yeah, it’s that tight.) So recall time has to be instantaneous.

As something of a sidenote, I actually build ‘bridge’ scenes where Actors A, B, and C are onstage, Actors D and E come on stage with dialog and join A/B/C; then A and B leave; and all the while EVERYONE is talking…

I’m on 1.82 and haven’t tested the waters but, based on the comments above, this is the way I very well may go if the recall time isn’t a factor.

Again, THANKS for all the input. VERY helpful!

RayH

[01soundman]

I, too, have a 144. Never have been happy with the LED vs. Label difference. Would like to see the strip labels brighter than they are now in comparison to the LEDs…

Ray

[Author]

Posts