[JacobParticipant]

Being able to copy/paste whole channels would be great!

[JacobParticipant]

Regarding latency compensation, I hear you. It’s a feature that I appreciate on dLive. That said, I would accept a certain amount of additional latency if it resulted in more flexibility or additional DEEP plugins. Ideally it would be an optional workflow, with a disclaimer indicating the additional latency. It’s worth pointing out that Allen&Heath are already willing to compromise the latency compensation of the console with insert based processing, most notably the Dyn8 engines. Those add 4 samples of latency and it is not compensated for (see What-are-phase-coherent-mixes?). So dLive users already need to be aware that certain workflows break the 0.7ms latency figure and require manual compensation.

[JacobParticipant]

In response to Brian:

#1 – In addition to having a global “pick point” for Direct Sends, we need to have a per channel option as well.

Totally! In addition, I think we need more options for aux send tap points. Not sure why we don’t have options for “Post Filter”, “Post Gate”, “Post Ins B Ret”, or “Post Comp”. It would also be great to be able to select this on a per channel basis. This would be helpful when mixing FoH and monitors from the same desk. Take a vocalist in a typical band as an example. I may want to provide them with an uncompressed version of their vocal mic, but I may want to maintain the compression of everything else being sent to their mix. Right now you have to duplicate the vocal mic channel and send that to their mix. Sure, there’s a lot more processing you get as a result, but you may not have the channel count to support that. It also makes your configuration more complex.

#4 – Improve the processing options on the channel strip. For example, it would be great if we could add a de-esser without burning an FX slot. It would also be great if an additional “slot” or two was added so this type of processing could be added without having to replace something already in place (gate, eq, compressor, etc) or to be able to stack compressors, etc.

Yes! Having a de-esser available on every channel would be nice. You could use a Dyn8 engine to help reduce sibilance, but those aren’t available on every channel either.

That said, the main improvement here would be having some sort of “wildcard” processing slot. To recap what’s currently available:
– Preamp
– Filter
– Gate
– Ins A
– PEQ
– Comp
– Ins B
– Delay

Maybe we could get a new “dPack” processing block after “Comp” where you could assign any existing dPack plugin (like another compressor). Then they could “port” the existing de-esser to dPack. Better yet, convert the existing “Comp” block to another hypothetical “dPack” block for a little extra versatility. So you’d end up with something like this:
– Preamp
– Filter
– Gate
– Ins A
– PEQ
– dPack Slot A (dynamics, EQ, and saturation plugins)
– dPack Slot B (dynamics, EQ, and saturation plugins)
– Ins B
– Delay

[JacobParticipant]

In response to Raunoa’s post:

Timeline View of Embedded Scenes – For timed scenes using the embedded features, a timeline view showing when triggers occur and their duration would be advantageous.

I love this idea! If they could incorporate this into a rework of the embedded recall menu, that would be terrific.

Custom Layer (Softkey) – Currently, layers such as A, B, C, D, E, F exist, but it would be great to create additional layers under Softkeys, like G, H, I, J, etc. Using “scenes” to trigger more layers is a workaround, but it’s not an ideal solution for professional use.

Similar to this, I’ve adopted faux “pop groups”, which are really just DCAs, but I don’t have the DCA fader anywhere on my surface. Instead, I have a soft key configured with the mix key of the DCA, which activates the DCA spill functionality. Just another potential work around for you.

Touchscreen Functionality (Mute & Selection) – Currently, I can scroll through channels at the bottom of the screen when they do not fit, but it would be beneficial to be able to select channels by tapping them. Ideally, this feature could be toggled on or off. I would find this extremely useful as it would allow me to select a channel directly on the screen instead of having to locate it among my fader list.

Agreed. A way to select any given channel or bus, without needing to have it on the surface, would be nice. The fact that I have to add the channel or bus to the surface so that I can push the select key seems silly.

[JacobParticipant]

+1

[JacobParticipant]

+1

[JacobParticipant]

Under-promise and over-deliver. Totally get that, Keith. Thanks for following up. I’ll just offer that I would enjoy A&H taking a more active role in the conversations here. Especially if that included a sneak peek of the next dLive feature update 🙂

I kid, I kid…

[JacobParticipant]

+1 – This would be great. There was a post recently that Nikola chimed in on and I really appreciated the acknowledgement and transparency. I would love to see that for all feature requests going forward. Or at least feature requests that get a certain amount of engagement.

[JacobParticipant]

Just want to take a moment to say that I really appreciate Nicola’s response. It’s encouraging to know that these requests are being seen and acknowledged. I would love to see this more often, even if it’s as simple as a response saying, “Cool idea!”. I also really appreciate the transparency around the potential software engineering hurdles. I think many of us here enjoy the technical side of things, so getting more technical responses is more engaging.

[JacobParticipant]

+1

I encountered this limitation a few weeks ago.

[JacobParticipant]

+1

[JacobParticipant]

+1

[JacobParticipant]

+1, especially in Director (as noted by Brian). It’s so weird to click and drag. On macOS, it has never been super accurate for me.

[JacobParticipant]

+1! Would love to have this in dLive.

[JacobParticipant]

This would be really handy. Assuming it worked well, it would potentially eliminate the “need” for dedicated Waves hardware/software solutions for many users.

[Author]

Posts