Forum Replies Created

Viewing 15 posts - 46 through 60 (of 218 total)
  • Author
    Posts
  • #83583

    Mr X – I have not experienced that issue at all. Are you using DHCP for network config on the mixrack/surface?

    #83582

    Yes, AH have confirmed discovery issue w/ DHCP. We had an IP8 that was having issues w/ DHCP, so switched to static, which immediately resolved the issue. I won’t rehash here, but see my other post regarding that if you’re curious about the circumstances.

    I have to say though: setting Mixrack/Surface connections to anything *but* static seems like a really good way to have a bad day that *one* time your DHCP server bugs out before a show.

    In my own *personal* experience, I’ve always, always used static IP’s for those critical components that must just work every time. About 7 months ago, our IT guy begged me to change our Mixrack/Surface to DHCP at our second campus. I reluctantly agreed, and guess who got a service call the third week that unit was on DHCP? We lost a good 20 minutes reconfiguring/rebooting everything during an already tight setup time. I… just wouldn’t risk DHCP for any reason again. (In my best Mr. Horse voice:) Nosir, I don’t like it.

    #83343

    Run Live Professor and UAD Plugs on a Satellite. Problem solved!

    #83231

    @ ddff_LV – For most situations that’s true. If, however, you have a device that you’re moving between systems/networks, Static DHCP reservation on the network side is a much more seamless way to move that unit around.

    @ EOTsskleet – Stop using FX returns, use input channels instead. You’ll find a *lot* more processing flexibility using inputs vs returns, generally speaking.

    #83196

    Found one!

    IP8 has issues connecting when set to DHCP. I’ve already contacted support and they’re working on it. Sounds like a device discovery thing. Basically, IP8 will connect as long as it’s powered on and connected to console at boot only. If you connect IP8 at any other time, IE after console has booted, console will recognize that an IP8 exists (surface/controllers, it shows up,) but it will *not* connect. Removing/adding the controller doesn’t remedy connection either.

    Switching IP8 to static IP seems to be the best workaround for now. Static mode connects just fine every time.

    #82987

    Yeah, Agreed w/ Steffen here. Use a scene. For instance: I’ve got four or five different drummer profiles saved as scenes, for the same drum kit, with the same mics/mic positions to accommodate each player’s style. Or, I’ve got IEM mixes saved for particular performers on particular busses, or I’ve got save status for all the IEM just in case something gets blown out.

    For funsies, I’ve also got one that’s called, “6k nightmare – Do not recall.” Which I reserve for that occasional guitar player who keeps asking for more “Me,” in a wedge and then complains that he can’t hear anything else.

    #82443

    I don’t see anything in the midi protocol documentation about TB. (https://www.allen-heath.com/media/dLive-MIDI-TCP-Protocol-1.50.pdf)

    What you *could* do, is make an input channel your TB mic, then have “press,” be custom midi message that unmutes that particular channel, release = mute.

    You would need to use TCP to send out to a computer or something (Bome box?) and then either have that device immediately return the message back to dLive, or interpolate your outgoing message from the IP8 and return it as the desired mute/unmute. Probably easier to just do something like, for ch128 – (Mute off) 90 7F 3f 7F 00, (mute on) 90 7F 7F 7F 00, mapped directly to your button as custom midi.

    It’s a little janky, but totally doable. Hope this helps!

    #82442

    Good to know I’m not the only one! I’ve submitted a bug report to AH.

    I need a bit more data to forward to Jack though: **If anyone here experiences this bug again,** can you please document what’s you see in TX flow Meters in Dante Controller *while* it’s happening? It’s so rare that this issue occurs, I worry it will be some time before I can get that documented. Thanks in advance!

    #82270

    I would echo what folks have said about ME-1. I have five stereo wireless IEM available for our bandfolk, and make those who *can* run wired, do so with me-1. In terms of practical use, I’ve had about 8-9 devices connected running mixpad/director, etc at one time on our networks, but they’re basically enterprise and can absolutely handle the throughput (and there are multiple AP’s.)

    Are you doing this as a traveling rig? Or is this an install? What’s your budget for network? Make sure you don’t skimp there, you want to be as redundant as possible with those connections. (For instance, I absolutely assign static ip to the console, and to at least one hardwired computer for backup control, and plug the AP’s into the switch. If you’re limited on funds, I’d recommend using a mesh network like Google Wifi, keeping the distance between AP’s at a reasonable interval. In other rigs I’ve had really good luck using airport extreme as primary, and airport express as wireless bridge, but I do know those are pretty much EOL at this point.

    One thing I will also caution about having a *lot* of iPads running OneMix – occasionally they blow out settings for *no* good reason at all. IE I don’t allow band ipads access to admin privileges, so they get a “band,” user login. Occasionally when they log they’ll get a “you must have at least one Mix present,” error. At which point I have to log in as admin, replace the mix-buss they were supposed to have on the “my Mix,” layer, and then usually rearrange layout on the other layers, as the arrangement there has also been corrupted.

    I’ve experienced this same error at multiple locations, with multiple dLive units, in different network environments, so it must be a bug. …all that to say, it will be a pain to have to manage that with 12 iPads if that happens on any sort of regular basis to you. (Usually it’s just one or two that blow out at a time.)

    #81870

    I use TCP midi for a number of things in our venue. 1) Live Professor snapshot recall for external DSP cues (AutoTune Keys, etc.) 2) Reaper Start/Stop Cues (I use Custom midi mapped to an action in Reaper for specific non-toggleable record start and stop @ current postion/save all media.) I’ve also successfully mapped out *almost* every midi parameter of the desk so that I can use Osculator to actually link two desks together.

    For instance, say one show I have to run both FOH and broadcast desks simultaneously. I can use embedded recall to link most of the cues I need to happen, but I still want manual control over things like solo boost, or media fades, or even specific DCAs. I’ve created dual documents that allow either bi-directional, or unidirectional control of one desk, linked 1:1 per fader, send, etc. When I move DCAs @ FOH, they respond @ broadcast desk, and vice versa. It’s been incredibly stable so far!

    If you’re using scenes to trigger things via midi communications you *can* use the default program change, but I would actually highly recommend using custom-midi option, per scene instead. You get the advantage that if, for instance, I copy a song cue to another scene, that custom midi cue follows to the new scene copied. IE If I have a song cue that does a thing in live professor, like key change, both my copied dlive scene, and the original will still do that thing. However, if I’m reliant on the default program change value that is tied to a particular scene number, then copy that scene to a new scene, the program change value for the new scene will be different, and my mapping will *not* follow.

    #81302

    +1!!

    #81182

    @ Matt – Musicians on-stage should only be given access to *their* mix on the my Mix page. If you look, layer 2-4 do *not* have mutes on any of the faders. IE, if you set up My Mix page as *Just* the main fader for that particular person’s mix, they can literally only mute their own mix.

    #80906

    You could create a scene mapped to a button that changes the layout of the IP units to not have any functionality. One for on, one for off. It’s an extra step, but if the surface is locked you’re effectively also locking the ip8.

    #80724

    It looks like you can toggle pad on/off and then it will synchronize the pad status between the two inputs! Thanks to Jack for that bit of information!

    #80117

    The problem there is that you’re dealing with a desk that can completely rearrange faders instantly per scene recall, if desired. Thus, you’re talking about not only tracking those assignments, but also the relative movements as that shift happens, for every fader. Then add in embedded recalls… I’m not a programmer, but I would imagine that is a huge amount of data to have to track for a very short transition.

Viewing 15 posts - 46 through 60 (of 218 total)