i know Ardour doesn’t have full latency compensation, but i thought LC on tracks works. So i was surprised to experience the following issue.
To do a Bus-treatment without latency, i did a stem-export of my drumbus. To check for latency i played both and switched phase of the stem. Since no sound was played, i suggested that they are perfectly in phase.
So i switched phase back to normal and loaded Carla-Rack into the stem to get some drumbus-compression. When i now play both (stem, as well as the originial bus) i expected to get the transients of the original bus with the fatness of the compressed stem.
What i got was some serious phasing.
So Carla seems to cause some latency even on tracks.
Is this an Issue caused by Carla or is the latency compensation in Ardour not “sample-perfect”?
Ardour has full latency compensation for tracks. If you use busses, and they have additional latency caused by plugins, that latency will not be compensated for.
That’s what i expected. Maybe my explanation was not good.
I have tracks routed to a bus (in this case drum bus). There is no plugin on the bus.
I did a stem-export of the drumbus and loaded the stemfile into a new track. (no plugin on masterbus while exporting)
i checked phase by playing both and switching phase on the stemtrack -> no sound = phase perfect. so far so good.
i switched phase back to normal and put Carla-Rack as plugin on the stem (which is on a track, so there should be compensation)
expected behavior: since both stemtrack and bus were phase-perfect and track has latency compensation, i should be able to use parallel compression by putting plugins to the stemtrack -> louder / fatter signal
experienced behavior: strong phasing.
Could be that my workflow of parallel processing is wrong in itself but from my knowledge there should be no phasing with this method?!
update: sorry for not having this idea earlier, but i tried Calf Compressor as Stemcompressor instead of Carla. With Calf there are no phase issues. So it seems the Carla Plugin has an internal latency that is not included in its LV2 latency information.
Anyway: thx for the great work and fast community-handling. But while i’m at it … full latency compensation and i’m fully happy.
Then click the link below and navigate to “sponsor issue” on the page, put in a sum and click “sponsor”. You only need to pay the sum after the feature gets implemented. When the sum gets big enough the feature might get implemented. With this we users can “vote with our money” for the features we want.
Wow, total sponsorship just 240$!? Are so few in need for this or is just noone aware, that this is essential for modern producing?
@paul: I’m thinking of buying Pro Tools JUST for the sake of having not to worry about latency ever again. That is quite an amount of money that i want rather to spend you, but the donations date back to 2012. So is there a possible solution so that sponsoring would help to get this feature within a few weeks/months?
Just so we’re clear: Ardour had latency compensation for tracks BEFORE protools did. Nevertheless, people used protools for nearly a decade without any latency compensation. Yes, they complained about it too. But they produced many fine albums with protools without latency compensation.
Adding latency support for busses is complex. An incredibly talented programmer (not me!) has already tried and found all kinds of complications (often caused by ardour’s anywhere-to-anywhere routing). I also tried. It isn’t easy. Tracks were trivial to do.
The work involved in doing this right represents thousands of dollars at typical first world programmer tates.
In no case this was meant to be a complaint. And you indeed have a point (as usual) that it worked for others before.
By having just a glimpse of the complexity and therefore the effort to get this done, i was surprised by the little amount of money that was spent to help you working on this feature. I was asking because i really would bite my $%& of, if i’ll go for Pro Tools and short time after you come up with the full compensation. As i said, i’d rather spend you.
@jrigg: good, simple idea! is there a way to readout the exact latency that a plugin (or whole bus) has, or what would be a simple way to measure the delay between two buses with different plugin sets? (I struggle measuring the exact delay between different buses because different effects alter the waveform in a way that makes them kinda hard to compare…)
Am I correct that parallel processing via sidechain inputs for the “dry” signal (that are only passed on to the output without actually going into the effect plugin) doesn’t work either? Something like this:
(Or it doesn’t even have to be sidechains, it could be a four-channel bus with the effect on channels 1/2 and the “dry” signal directly passed through 3/4…?)
.
Another thing I want to add: If it is only for parallel compression, Calf compressor has a built in Mix-knob already…
And I also sponsored the feature request, maybe it helps…
Anyways thanks a lot for Ardour, great application already!
