Ok folks, there has been an idea of a dynamic / transient crossover. But I actually found this is extremely simple to create in MXXX. Here's the way:

1) Use Dynamics on line 1 and make it a gate with whatever parameters (just don't use look-ahead, filtering, or input/output gains, it needs to be linear).
2) Use Math in line 2 in mode "Subtract", set its input to 2 and sidechain to 1, and set the "Maximum" parameter to the maximum to avoid clipping. That's all.

How does it work: Dynamics performs a gate, so if something is too silent, it doesn't go through, if it is loud, it does. Math simply subtracts the gated signal from input (that's why the input is 2, so that it goes "around" the gate). The gate is "linear", which means it only applies some gain, therefore if you subtract the results from the input, you get "what's missing in the gated signal", and hence when the line 1 is mixed with line 2 afterwards, you have the original signal.
So in line 1 you have the loud signal and in line 2 you have what's missing .

This is an example, where only loud parts get the reverb .



Great thing about this is that it is extremely versatile... And for example you can do the same trick with "Transient", just use that processor instead, and set attack to minimum and potentially even sustain to maximum (it will work kind of the opposite way).

That looks very useful and clever! One question I would have, though, is would it be possible to achieve the same while still using look-ahead? For example if I want to build an effect where the quiet sounds are run through more reverb (thus appearing to be further away), it would be useful to have look-ahead, so that sudden transients don't leak into the reverb (without using super-short attack times). Could it be solved by adding a delay of exactly the same length as the look-ahead into the other signal path? How does the look-ahead work anyway, does it just delay the dynamics-module by the look-ahead amount? Shouldn't it instead incur the look-ahead latency to the whole plugin, in order to avoid phase/sync issues in other situations also?

Well, you could definitely solve it using "Utility" and the same delay. Just be careful to set the exact same delay in milliseconds (samples are dependent on sampling rate). Look-ahead is a simple thing indeed - it just delays the actual signal being processed, but doesn't delay the signal for level measurement.

Not related directly to the topic at hand - but doesn't that way of handling the look-ahead cause all kinds of phase and sync issues in many situations? I mean, if you for example divide the signal into 4 frequency-bands and use the Dynamics module with look-ahead on one of them, you then need to use the same delay with the Utility module on all the other frequency-bands to get them all in sync again. Wouldn't it be more convenient if the plugin handled that automatically, i.e. if a look-ahead or similar feature was used on one of the signal strands, the others would automatically be delayed too, keeping the overall signal always phase-aligned when not absolutely necessary to not do so?

Yes, you are right, it's more like a technical complication. Also look ahead is not used that often, more like in limiters, and if, you can just use the same value in all bands and that's it.

Sorry for the late reply. Do I gather correctly from here and from what you said in the "Logic 9.1.7 and delay compensation" -thread that delay caused by look-ahead is not reported to the host? If so, doesn't it make the whole feature entirely unusable? Also, I disagree that look-ahead is not used that often - I use it a lot. I think in a plugin as versatile as this and which is very much geared into realizing things you can't do elsewhere, I think it would be best to minimize assumptions of what is used often by the user and what is not...

Yes, it is not reported. Right now, nothing is reported by MXXX, I thought about some internal latency compensation, but it seems genuinly extremely complex, will see.
With look-ahead - it doesn't make it unusable as in most cases. In MDynamics it is reported upon startup, but not when you change look-ahead on the fly, as most hosts cannot change compensation anyway. And in most cases the look-ahead times are quite small, say <5ms (at least I do that, with higher times it becomes a problem), so it actually make you play better, because most people play "ahead"

Personally I do use longer look-ahead times as well, and even with small values, you'll end up with phase-problems, right? Say, if I have two tracks with the same soundfile in sync and put a MXXX as an insert on one of them with Dynamics with a non-zero look-ahead value - will the soundfiles still be in sync? If not, I do think it makes it unusable in most cases, or at least very problematic, as you'll end up with all kinds of phase problems. (Say for example that you want to use Dynamics with look-ahead just on the overheads of a drum kit recording but not on the rest...)

That could be the case, but think about it -
1) This is a normal situation, most hosts do not provide variable latency compensation, and those who do are in a great risk.
2) Many processors cause different phase shifts - if you use an eq, you are in trouble as well.

So generally I don't think it is such a big deal. Anyway in MXXX there will be the flags for latency and phase shift (I hope you read the file!!! ), so users could avoid these presets if necessary.

I don't understand your first point - what do you mean by "variable latency compensation"? The only thing that would be needed to get rid of the problem would be just normal delay compensation, as used by most plugins that incur latency (and also, if I understood correctly, by MDynamics).

As for the second point - well yeah, I suppose to an extent that's true, but the phase shifts caused by an EQ are nothing compared to the full-blown comb-filtering when one signal is, say, 5ms out of sync to another. And, again, speaking of phase only applies to very low look-ahead values, with longer values there would be actually genuine out-of-syncness, which is obviously not ok.

And I think using longer look-ahead values is a viable possibility, and if you really think it's not, why do you even offer the possibility?

As for your comment on preset flags - sure, that'll warn the noobs, but it won't get rid of the issue. And I think it makes more sense to look at this effect as the power-user heaven that it is, than to strangely target it to a preset-driven average users, who already have masses of much more appropriate effects aimed at them...

You don't understand the problem. The latency simply cannot be compensated without producing a default latency of maximal lookahead... Simply put, hosts CAN NOT fix the latency if it changes. The plugin reports it once and that's it. Next time you change look-ahead, you usually have to reload the project and that should help if the plugin reports the latency AFTER the settings are loaded (which MDynamics does).

I assume these plugins will mostly be used without look-ahead, so realtime. Look-ahead can NOT be used realtime for obvious reasons (unless the look-ahead is small enough in which case we have nothing to talk about except for the phase shifts). So the idea of reporting a maximal lookahead as latency is out of the question.

In MXXX it would need a full latency compensation algorithm, which I'm not sure could be done now as it is really complex here, and it will still produce latency - you would need to reload the project everytime you change the look-ahead.

Given the fact that high look-ahead or phase issues with multitracking will be quite rare, this makes me mark this problem as low-priority.