Montage Track Monitoring

For some reason, I can no longer monitor the input of a track. Been doing this for a long time with WL11. And when upgraded to WL12 still worked as expected. But a week ago it just stopped working. Routing looks correct. If I open the record window there is signal. But when I click the input monitor of a montage track, I get nothing. Any ideas?

Did you try to toggle this?


For what ever reason, the track monitoring is behaving as it should. I don’t know what I changed or didn’t change, but it was probably operator error.

All good now. I’ll report back if I experience again.

Actually, I have another question about Track Input Monitoring:

Let’s say I have a track with a preexisting file in place and I play it while simultaneous playing an external source. In WL11 I could toggle the Monitor button on the track to go between the external source and the file in the track for comparisons. When Monitor is off I hear the file playback. When Monitor is on the file is muted and the input stream is heard. Perfect.

But in WL12 if I hit the Monitor button then I hear BOTH the input source and the track file. I get the sum so cannot make comparisons. Not so helpful for me.

Also, If you have a track with Monitor on but then solo a different track, you still hear the input of the first track even though that track is muted. This is true in both WL11 and WL12. I would prefer that input monitoring follow the track’s mute condition.

Maybe there is a preference that I am overlooking?

Solo track #1 and #2, as on the following picture.

In your picture Tk 2 is solo’d which automatically mutes Tk 1… Even though the [M] button is indicated yellow, I can still hear Tk 1 input stream. Both WL11 and WL12

However, If I manually click Tk1. mute button (no solo) then the input stream is muted properly. Both WL11 and WL12.

WL12 always gives me the sum of input and playback. Mutes don’t silence the monitor input stream.

If “Direct Monitoring” is OFF, then what I propose in my picture works. Please try it.

Confirming that Direct Monitoring was OFF.

Soloing does not silence other tracks with Monitor engaged .

If you hear your input in the following config, this should mean your audio goes to your speaker via another route than WaveLab.


I don’t see how the signal can get to my speakers other than WaveLab. But let’s leave the speakers out of it and just look within WaveLab itself. Here is a picture of what I am experiencing.

First, engage Monitoring (Direct Off) on Tk1.
Next hit Solo on Tk2. This should trigger a mute of Tk1. We can see Tk1 Mute button is engaged yet the input signal of Tk1 is still routing through the montage as proven by the meters at the bottom.

I have only channels 1/2 of my RME card set up in the Audio Connections for Playback and Record. No External Effects routings. So I don’t see how that might confuse the routing.

Indeed. I admit I have no clue why this is happening.
Are you really using WaveLab 12.0.10 ? (and not WaveLab 12.0.0, which had a bug in this area).

Strange indeed, have you checked TotalMix as well In and Out routing?

regards S-EH

Hi S-EHansson,

Not a bad suggestion but I think I have established the issue is within WL.

Thanks anyway :slight_smile:

WaveLab Pro 12.0.10 (build 556). Windows 11 Pro 22H2.

Where you able to replicate this behavior or is it just me?

And a reminder about the related track Monitoring problem mentioned earlier:
Playing a file in a montage track with the Monitor on (direct off) sums the input and file playback together, instead of alternating from input to output as done properly in WL11. This prevents the ability to make “live” comparisons.

Please upload this montage, so that I test it.

Here you go. Thanks for looking into this.

Track Monitor leaking signal (1.6 KB)

I see now. When the monitored track is muted because another track is soloed, then I get what you describe. If the monitored track is muted because mute was explicitly activated on that track, then there is no sound.
I see if this can be fixed for the next update.

Update: I mentioned that the bug was already fixed in WaveLab 12.0.10, but this was incorrect. The bug has indeed been fixed, but in the upcoming WaveLab 12.0.20. Apologies for the confusion.