[ThatComplicatedMidiGuyParticipant]

Metering not working for Groups, Solved: You *can’t* leave “post preamp,” selected as pickoff point in the editor. Any other choice results in a properly working group meter.

[ThatComplicatedMidiGuyParticipant]

Glad to hear! I’ll pull the dropbox files.

@ A&H folks – I found another small annoyance: Say you have several identical layouts within the scope of one Layout Manager file. You realize that you need to change, say a single (mono) meter to dual (stereo) meters in the same place in several different layouts that are identical. (At least in terms of physical layout, each controls a different Stereo Aux.)

…you update one, then copy those dual meters from that first one and paste it to the same place in #2, 3 and so on. …but when you paste – the object doesn’t automatically paste back *in* to a container, even if the original source was also in a container.

So, you have to copy/paste, then move it a little so the #2 container recognizes the object is supposed to be inside of it. It’s super annoying when you’ve already got things neatly aligned, and then have to do that all over again. I would love to have the option that, when I paste something that falls within the zone of a container, it automatically pastes inside the container to avoid that extra step.

[ThatComplicatedMidiGuyParticipant]

@ Blangford… I tried importing your text as an XML file and couldn’t get it to work, any chance you can attach it as a file?

I’m currently on week 2.5 of using this for IEM and have both ST Groups/auxes working perfectly. My current working beta doc is attached for reference. In my show I have ch98-128 reserved for IEM channels, but also use a handful of groups for things like Audience mics, Drum Mix–>IEM, etc. Hope this helps sir.

Oops, XML file size is too large:

https://www.dropbox.com/sh/29kias82x9fc4g7/AABe9w1vPhPf223QIMENTzV4a?dl=0

I put both our secondary campus default template show file and the custom control layout file in there. Feel free to give it a look.

[ThatComplicatedMidiGuyParticipant]

Big +1 here. We keep firmware/software updates carefully managed, but I’ve been bitten by this one on at least a couple of occasions early on with this desk.

I feel like One Mix is arguably the weakest part of the dLive ecosystem, for the compatibility-between-firmwares reason, but also because OneMix occasionally blows out all the settings for no reason whatsoever. …also also, two login screens for an end user? …and pan sliders that are really difficult to see when you’re actually touching them? No me gusta.

…we’ve jumped ship for the new “Control,” app at our primary venue. I have the user logins to burn, and all the layouts get stored on the desk. Customization isn’t as quick or dynamic as it is with OneMix (IE can’t drag and drop faders,) but so far it’s been arguably more stable, and the end user simply needs to open the app.

[ThatComplicatedMidiGuyParticipant]

If I were doing that thing, I would *maybe* get an ip8 as well to keep on the side. I’ve used c1500 both with, and without an ip8 as sidecar, and much prefer having those extra 8 faders; if only for keeping DCA spills tidy, for keeping Tap Tempo far far away from where I might have my “go” button mapped, and for things like quick access to FX sends/returns, or the occasional wedge.

[ThatComplicatedMidiGuyParticipant]

…aaaand one more bug: GR meter, Does *not* appear to work for Stereo auxes, but does for inputs.

Also, for what it’s worth, I realized I do have enough logins available to make this a viable option for IEM iPads for our site; band *loves* it so far! Really an improvement on a number of levels as opposed to running MixPad.

[ThatComplicatedMidiGuyParticipant]

…okay one more thing I’d like to see here in future updates: Double tap (or triple) tap option to return knobs to center (Pan, specifically.)

[ThatComplicatedMidiGuyParticipant]

@ Nikola, thanks! That’s exactly what I needed. It didn’t occur to me the fader setup was identical to ip8. duh.

@ Mr X – 10 user logins per console.

[ThatComplicatedMidiGuyParticipant]

Yeah, the layouts are stored in console, which is pretty cool. It makes sense from an administrative perspective, and I would imagine that saves from having the blowouts you sometimes see with MixPad. (Layouts just get completely messed up every once in a while, it’s an open ticket w/ support.) You just have to build the layouts, then push them to the console from the editor.

I also like that you can assign specific layouts for specific user logins, although it means application is limited for use as an IEM controller due to the limited number of logins available.

[ThatComplicatedMidiGuyParticipant]

One other thing that would be useful is a shortcut enable/disable setting for faders so that you could, say, double-tap to set a fader to 0. (…maybe triple tap as an extra precaution?)

[ThatComplicatedMidiGuyParticipant]

Very Cool! This is exactly what I’ve been doing with Touch OSC since the dLive was released. …only better!

I’m already working on several layouts for a few different applications. I noticed a bug with Mains fader though: It doesn’t look like it actually controls the mains fader. Did I miss something?

One other thing I would love to see in the next revision, especially as this is geared toward the installation market: is the ability to limit output values for faders. I do this in Touch OSC for instance, to only allow “unskilled,” users to move a fader from -inf to a **maximum** of 0dB for the entire fader throw. It prevents all kinds of issues in most environments where things need to be relatively dummy resistant.

[ThatComplicatedMidiGuyParticipant]

@ Lishinksy, for the same reason I’m not burning a buss. I’ve already got duplicated channels for IEM reservations, plus a number of other workflows. I’m getting close to capacity with input channels as well; so sure I *could* do that, but it’s an unnecessary complication/waste of resources for the application. (It would also be kind of a pain to dial in: going between key channel and actual channel I’m trying to process.)

[ThatComplicatedMidiGuyParticipant]

I’d like to have this in the MB section specifically as opposed to the dynamic EQ. Although, it would be nice to be able to split detection frequency from being dependent on the chosen center frequency of that particular EQ band. I’ve found that even w/ the wideband detection using the EQ section, there are a number of vocalists I deal with where the targeting is just inadequate. See the attached FFMB screen cap for the sort of variable targeting behavior I’d like to see.

Attachments:

You must be logged in to view attached files.

[ThatComplicatedMidiGuyParticipant]

Alas, this is *also* not currently in the midi spec. (Pan is also missing, boooooooo.) One workaround you could do is use something like live professor’s cue lists, map dLive scenes to cues, then map next/previous/go out to whatever controller you’re trying to map for this function. I’m doing this with an ElGato Stream deck, which seems to be working quite smoothly.

[ThatComplicatedMidiGuyParticipant]

Big +1 here.

@ OP – in the meantime, if you do something like, get an x-dante card for an x32 rack, plus an m-dante card for your dlive, then spit tie-line outputs to the x32, you still get that flexibility w/o sacrificing inputs or busses internally on the dLive. You’ll need to do a bit of routing on the x32, and then your names will have to be manually adjusted on the x32 side, but you’d be doing that anyway if you were using duplicate input channels as IEM sends.

[Author]

Posts