How to find what is causing a particular unwanted control change?

#1

I have a project that I unfortunately cannot share, and creating a successful minimal repro could take anywhere up to weeks of trial, error and despair, so I will just go ahead and describe the problem and maybe it will be familiar to someone.

The problem is that SOMETHING is sending an unwanted pan control change MIDI message that resets the pan controller to 64 on channel 1 at a particular timestamp.

  • I have inspected every MIDI region containing that timestamp and none of them contain this control change message.

  • I have two MIDI tracks sending to that channel. The Pan automation mode is set to “Off” on both tracks.

  • Interestingly, if I manually adjust the Pan control on both tracks (which doesn’t even make a lot of sense because the values would conflict anyway) and play the song, then only on one of those tracks does the Pan slider jump to 64. On the other it remains how I set it (which, again, makes little sense because it’s the same channel).

  • Possibly relevant: one of these tracks was created by duplicating the other in “new playlist” mode. The new track is the one where the slider stays, while the original track is the one where the slider jumps.

  • Finally, this is a PC-only, Ardour-only setup; there is nothing else in the system that could possibly hold that message - no hardware instruments, no sequencers, nothing.

I’m out of ideas as to where else I can hunt for that pesky control change. Help please?

#2

Just for clarity – are you examining the content of the region, or are you also considering any active automation lanes for those tracks? If the panner got mapped to an automatable CC channel, that could explain the unwanted change. I apologize if you’ve already chased that down.

#3

There is no audio “panner” involved at all. We are talking strictly MIDI. Yes, there are automation lanes for the pan CC, but both are in the “Off” mode (“Wył.” in the screenshot, that’s “Off” in Polish), which I understand to be the same as your notion of “inactive”.

image
image755Ă—767 69.5 KB

#4

If this does not happen at session start, but sometime later during playback it should come from a MIDI region.

Switch to layered mode, perhaps there is a region behind, which has CC events?

Also I suggest to add the “ACE MIDI Monitor” plugin (comes with Ardour) to both tracks. That should help to pinpoint when the CC event is sent.

#5

Solved by “Automation → Show existing…” (menu items backtranslated from Polish). This revealed the offending CC recorded on channel 2, but forced to channel 1 by the track settings.

However I discovered a potential bug: the message was still sent if the track was muted, and only muting the region itself with Alt+1 successfully muted the message. Perhaps the track mute logic matches the original channel # in the MIDI messages and only filters out those that match the track’s channel? I think this is wrong, mute should mean mute, i.e. disable completely as if the track did not exist at all.

#6

I’m glad you found that.

That would be “deactivate” (available from the track context menu) and not “mute”.

Note that mute can be automated, so the track(s) needs to be processed and produce a signal. Mute then affects the signal as it leaves the track, and there are various mute-points (right-click on the mute button), as commonly found on mixing desks (muting audio also does a short fade to avoid zipper noise).

Still, by default the main out is muted. MIDI events sent that way to a bus are dropped. Same for post-fader sends.

1 Like