@kellydv: Thanks, tried it out but I don’t think that gives the same result as my crossfader scheme? Can you achieve a 100 % wet signal on the Stereo bus only by adjusting the Effects fader? When it’s set to 0, the Stereo bus gets 50 % dry and 50 % wet signal right? Because the Stereo bus is only adding dry + wet signal, and you can’t turn the dry signal down without affecting the Effect bus. I suppose you can solve this by routing to another Dry bus between Main Track and the Stereo Bus, but then you have to automate both the Dry bus fader and the Effects bus fader for getting a 100 % wet signal.
1 Like
@farbro: you’re right, it’s not the same, but I’ve got an idea.
Main Track L -> Mono Bus With Effects -> Stereo Bus
Main Track R -> Mono Bus -> Stereo Bus
The stereo outputs from Mono Bus and Mono Bus WE should just go to the matching inputs on Stereo Bus. Then the pan of Main Track will do what you want (L=Wet, R=Dry), and the fader of Stereo Bus will control the overall level 
(Mono Bus isn’t really necessary, but then again you could have different effects over there)
a more important question here is: how is it that so many fine recordings have been mixed on mixing consoles that do not have the “crossfade” solution that Farbro wants? You simply can’t do it on any mixing console that I know of, and yet that didn’t impede the production of Kind of Blue, Thriller or Autobahn (to cite just 3 notably different musical forms). From reading this thread it would appear that wet/dry crossfade is an essential and obvious feature when working with plugins, and nobody working with consoles + FX gear did things in this way. I’ll need some convincing that adding wet/dry to every plugin is really an improvement given this history. Right now though, the argument is going in Farbro’s direction until someone can explain to him why a wet/dry mix of most plugins is not what you want. I’ve already noted that its crazy to do it for dynamics processors and that most delays and reverbs have their own. So that leaves things like flangers, phasers and EQ. Can anyone do justice to my basic point?
@Paul: There are a very few cases where it might be necessary, but for those, I would suggest it’s probably better to use ardour’s existing buss structure anyway. The use cases that come immediately to mind would be some forms of ‘upward’ or parallel compression’ - where it may be necessary to mix some of the un-effected signal with the output from a compressor, but for ‘normal’ dynamics / compression this is exactly what you don’t want to do. Similarly, for filters / EQ, it’s not normally necessary to mix clean / effected signals, and if you do there can be all kinds of phase issues to contend with (which is not something the host could or should try to compensate for).
The only ‘common’ case would be reverb, for which either the effect itself will have a wet / dry crossfade or a buss could be used (and is probably the preferable solution). In terms of analogue consoles, its almost unheard of to have insert or patch points with dedicated crossfaders, not least because anything you might want to do that would require it, can be done more easily or with more flexibility by using aux sends / return busses or just a spare / duplicate channel etc. I think ardour already provides a means to cover these (rare) use cases, possibly in a more flexible way than would be possible by adding the extra complication / DSP overhead of crossfaders for plugins.
Quite the opposite Paul, it ISN’T crazy to do with dynamics processors, in fact it is a common thing when dealing with Parallel Compression for instance.
The thing is, that I know live engineers(Myself included depending on the show) that set up their console processing and subgroups on larger VCA consoles, etc. specifically for this. They will use the Pan or the VCAs to mix as LinuxDSP described to get exactly this effect. So my feeling is the better question here is, “Why wouldn’t we make it easier?” Obviously LinuxDSP and I disagree on this a bit, but my feeling is just because we can do it, doesn’t mean it can’t be improved.
Now that being said, for normal compression etc. LinuxDSP is absolutely correct, most people don’t want this. Just I can see it being a useful feature if implemented correctly.
Seablade@seablade: I think we agree about the parallel / upwards compression being a valid use case, but I just can’t help thinking that adding a plugin crossfader is the wrong way to go about it (I can’t describe exactly why I think that is the case, it just ‘feels’ wrong).
For cases such as that it almost seems as if it is something that should be in the plugin itself (compressor, dynamics processor etc) where there could be better integration with the other aspects of the plugin (note that not all dynamics processors will work in parallel configurations, especially some multiband compressors due to the phasing of the filters etc) - however I realize I’m probably biased in favour of the ‘in the plugin’ approach, being a plugin developer
@paul: I agree with your point. Farbro had a creative idea that he wanted to realize using Ardour, and I think I explained a simple way to do it with the existing tools. Whether he likes the result is another question. I had fun thinking about his problem.
@seablade: “I can see it being a useful feature if implemented correctly.”
So what’s the correct way? As linuxdsp said, it can be done in a more flexible way with busses. One of the things I like most about Ardour is that it has been very fast and easy to learn because of its simplicity. I have found Logic, for example, to be a pain to learn because it’s got so many features. The learning hump in logic has kept me away, whereas Ardour’s unobtrusive UI has been a lot easier to step into as an amateur. Though it’s simple, it is flexible enough to do what Farbro wanted. So my main point is this: if you can do it with busses, why add an extra function?
Am I correct in understanding that the use of a bus for parallel compression won’t currently work completely correctly, because buses in Ardour don’t (yet) do latency compensation?
Not necessarily going to disagree with anything you said there;) Fun thing about sound, there can be many ‘right’ ways to do something.
It isn’t a question on whether it can be done, but rather whether it can be made easier. After all isn’t that what most DAWs these days do, make something easier and faster for the user? Otherwise why have beat splicing or silence detection when you can always do it by hand for example?
@DLC11 you are correct, There is no latency compensation on busses which means that unless you manually insert latency somehow you will be dealing with phasing, how significant however depends on the plugins in question. That would be one large advantage to a wet/dry mix control in the track is to allow for latency compensation easier.
Seablade@kellydv: Good idea about the panner, but as far as I can see this will only give a mono signal in the end. Perhaps you could use a 4 ch panner but I don’t know how that is for automating.
Regarding the necessity of this feature, I’m quite into electronic and experimental music and with Ardour3 and MIDI support I think you will gain more users operating in these genres. I would use a wet/dry feature for creating more “DJ-ish” songs, with lots of automation for dynamically changing the sounds of the synths and wav audio, creating flanging-like sounds but automated how you want them to apply. With this feature it would be easy to make effects “sweep” back and forth in the song and you can make them fade in or out, which for example may sound cool in a pre-chorus for building up energy before a transition.
Using buses for doing this is achievable of course but if you have a multiple of tracks you want to use this with you will end up with a lot of buses and you will get kind of a mess. And by this I agree with seablade, even if it’s already doable it is not that simple to set up, and I think that making things a lot easier is a fully acceptable reason for implementing new features.
Ok, I’m becoming more convinced of your need. Now I have a practical question (which was the sub-conscious source of my irritation at the possibility of this feature):
How should the wet/dry parameters of a track’s active plugins be treated?
Should it be like: Global Dry 100% = all plugins dry 100%, Global Wet 100% = all plugins realize wet/dry setting ?
That makes the most sense to me, but I can think of other possibilities too. If this feature were to be implemented, a choice would have to be made.
It wouldn’t be per track, it would be per plugin;)
SeabladeHa! I did misunderstand. In that case, I concede that this could be a useful feature Shouldn’t it be the job of the plugin developer to add it though? And my question still applies to a single plugin.
Not sure i understood your question for two posts back. To answer your question about the most recent, yes it could be, but many developers develop their plugins with a specific use in mind and don’t think about the possibility of someone using it different, this is a global control that COULD apply across any plugin really depending on who is using it, so it could be implemented at the DAW level, unlike most.
Seablade
It still is an important feature as ardour isnt only used to simulate the mixing style of old consoles, but adds up on this. Of course you couldn’t easiliy select the type of metering, chop up regions, change speed or pitch and so many more features that ardour offers, with these analog mixing consoles. Having a dry/wet knob, like in carla, is often times the better alternative than to always create a new bus for it. Otherwise, why would plugins include this feature at all? It does make sense to make it available system wide, as to allow a more free and creative workflow. For this simple feature, that a lot of daws offer, in ardour you have to get out of your way to achieve this. Does it really make sense to stay focused on that one very specific way of using ardour? Like a ‘best practice’ enforced on all creative workflows. Of course, this daw can be used in so many different ways.
Imagine, none of the plugins offer a dry/wet. Creating a send bus every time you only want a slight hint of a plugin is a massive overkill.
It doesnt really feel that it would be hard to implement or that a tiny knob in the top left corner on a plugin would make UI look bloated. There is some space between latency compensation and pin connections. It is a reasonable feature which’s existence is justified. So if there are some people that prefer doing it that way. What does really speak against it? other than its not the way you’d normally do it analog style.
Would it do any bad? My answer would be no, if you dont use it just ignore it (maybe im missing smthng though)
Would it be good? For some people (me included, obviously) it feels like a useful feature
Hoping I could add to the discussion with my comment
There are only a few cases where a cross-fade is correct for a given DSP. There are also cases where it fails completely. Plugins with latency are an example (the dry paths will have to be delayed accordingly).
If it makes sense to have a dry/wet control it should be provided by the plugin.
In any case you can do this in Ardour on a per-plugin basis using Pin Connections, using an A/B cross-fade plugin:
The bypassed signal (dashed lines) are also delay compensated in case the plugin introduces latency.
And in addition to this, since the cross-fade is done by a plugin, it can also be automated or remote-controlled.
Thanks for pointing this out! It seems like a much more flexible fix, than creation of a bus. And it does make sense to include an extra step of work to do things that one shouldn’t do without being absolutely sure (like in rust, when you want a null)
1 Like
For good measure, we’ve just bundled two plugins A-B Switch and a Cross Fade to make this easier. Available since Ardour 6.2-20.
4 Likes
Awesome! Thanks so much 
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.