Oh yeah... such a drastic improvement over the lack of possible additional "control" like more fine tuned volume, possible additional EQ, etc. Though I do understand the latency issues (*cough* ProTools *cough*).egbert wrote:And if any latency is introduced by the plugin, the direct signal path can compensate for this within the plugin.do_androids_dream wrote:Because it's very handy? Because it means you don't have to fiddle around with parallel compression routing?Compyfox wrote:Just as I don't get why every compressor these days needs a mix dial.
Still, it's overhyped (IMO). Every plugin does have to have this. And if it doesn't have this, it's automatically an inferior or "broken" product?
With one difference here - most mix consoles are "mono" or rather "stereo" consoles.Gamma-UT wrote:Yeah. Why would anyone want distortion from a distortion plugin? Especially the kind of distortion people pay for in mixing-desk emulation plugins.Compyfox wrote: Have fun with crosstalk in a M/S circuit.
If you force SDRR into M/S with a pre/post matrix tool (example: bx_control), you still have the crosstalk effect (some even call this "channel bleed"). Now crosstalk has a correlation with the signal strength. The stronger the input signal, the stronger the bleeding into the other channel.
Now imagine a stereo mix, and you want to run it through SDRR. But you only want to treat the side signal. Let us assume that you don't use a modular subhost to just treat the "sides", but you run M/S tool -> SDRR -> M/S tool. What happens now is that the L signal (now the M) is stronger than the R signal (now the S). And this influences the crosstalk. You will hear the mid signal loud in the side signal. And this in turn can introduce a lot of phase problems... not to mention that your "widen effect" would fall apart.
Then there is another point that was not addressed yet (but I got reminded of this as part of a beta test discussion at another company I currently work for): M/S implementation would complicate the plugin in several ways.
a) the internal circuit would change
b) you need more controls on the GUI
c) new beta testing needed
I agree with bungle here:
Add to that, that this plugin concept is based on "hardware preamps", and their limited circuits. So the workload for such a tool has to be taken into consideration.bungle wrote:If Tony sees value in it, he will add it, if he doesn't, he won't, he is a very pragmatic developer, and to be perfectly fair, up to now has pretty much nailed it in terms of features vs cost.
If you can still pull of what you want through other means - does it mean it has to be "implemented" just because it's "more convenient this way"? We have so many tools at our disposal, that limitations or simpler tools are not allowed? Does every tool have to be a sandbox design?
Are there guitarists among us in this thread? What's your opinion on an "all-in-one solution" pedal board compared to a "mix and match" type one with individual/specialized/better sounding modules? Isn't that the same principle?