delayable sends to mixbus 9-12

[arthie]

So here it is my wish-request for any future update: a possibility to dial in a constant delay-time for the bus sends 9-12 so that you can emulate different predelay timings on your effect sends on each track individually. That would make up a great addition to mixbus 32c.

[Ben@Harrison]

I think this is a great idea. It has been on our ToDo list for a few years.

It can be a fairly expensive (DSP-wise) operation so we have chosen not to implement this. But with computers continuing to get faster ... perhaps it is time to revisit this.

-Ben

[arthie]

Did not think that this is a lot of DSP load, but you are the expert. Is it really so heavy dsp to just send the signals to any bus later? I mean I am not thinking of feedback controls or anything like that, just a delay time as simple as possible

Looking forward for the the stuff you guys come up with. I think the concept of mixbus is really great, much enjoy mixing with it

[Ben@Harrison]

@arthie,

The "summing engine" is the heaviest user of cpu in Mixbus.  Any processing in the summing engine is replicated N tracks by M buses.  Even if you only do the final 4 mixbuses, you're still looking at N*4  delay lines.

The problem is this:  if you want to advance one track by a little bit, compared to the other tracks, then this means you must add a delay to all other tracks sending to that bus.  And delay lines aren't as simple as you think: you probably don't want to hear glitches while you turn the delay knob, and that's tricky.  So it quickly gets to be a lot of math.

Furthermore,  while there's plenty of memory in modern computers to handle all those little delays, there is a cpu cost associated with these small delay lines, because paging that memory into & out-of the cpu's cache is a non-trivial amount of time.  It's not a lot of work, but each little memory request take some time for the memory system to deliver the data you asked for,  and that hurts your realtime performance.

NOW, all that said, does it matter?  I don't know for sure until we try it.  But I do know that Mixbus already uses a lot more CPU than most other DAWs, because we spend so much effort in the mixing& summing engine to make things sound better.  As computers get faster, we can continue to do more&more of this kind of thing.  But until now, my gut feeling has been that this would add a lot of work to our  already-busy summing engine.

-Ben

[arthie]

Thank you for the explanation. In this case.. dump my request and focus on stability as this is actually the most annoying part (at least for me)

[Andy76]

you can emulate different predelay timings on your effect sends on each track individually.

Whats the use case for this? To have different predelays from different instruments which are sent to one reverb?

[arthie]

andy76 yep exactly, so you can simulate the whole band is playing in one room. The further back instruments then will have less predelay and the more in front ones will have a longer predelay and the reverb simulates just the room. I found this technique quite handy, but if it is really such a big DSP thing I don't think this should be added. Perhaps to have the option sessionwhise activating it on one bus could be nice to have feature.

[dspasic]

andy76 yep exactly, so you can simulate the whole band is playing in one room. The further back instruments then will have less predelay and the more in front ones will have a longer predelay and the reverb simulates just the room. I found this technique quite handy, but if it is really such a big DSP thing I don't think this should be added. Perhaps to have the option sessionwhise activating it on one bus could be nice to have feature.

this sounds very good, combine EQ, reverb/room simulators and you've got whole ambient thing going on.. 
Bitwig has effect which can delay track in forward or backward in time.. Is there similar thing in Mixbus/Ardour? (if per-track would be too heavy on the resources)
   

[Lars]

Is there similar thing in Mixbus/Ardour? (if per-track would be too heavy on the resources)

unfortunately not, would be great though!! (and make it samples, ms or distance in meters for easy alignment of multi-mic sources)