audio analysis interferes with control surface interaction?

[Angstrom]

OK, forgive the daft title.

I have a headsup display I use for performing live, it's a full screen patcher with a bunch of info about the set in vast font size, some VU meters, etc.
It interfaces with some of my hardware controls in various ways - it watches for button presses on my Launchpad to see if the ring has moved, and it repopulates various bits of text on its UI when that happens.

All works well, not to heavy on the CPU.

until - I take an audio stream and feed it into the pcontrol which houses the Heads-up and then feed the audio on into a (tabbed) bpatcher which contains a spectrogram.

When I connect this audio stream -> spectrogram the launchpad loses it's mind!
The launchpad behaves as if it's being polled at audio rate. But it shouldn't be having any connection with that simple Spectrogram chain which I've established. The spectrogram is set to update at "50". So, nothing too outlandish. But even if it were faster - why would it interfere with the controller?

So, is there something about running an audio stream through a patcher which might cause this which you can think of?

Is there any way I can make this question more vague and nebulous?
thanks

[[jur]]

But it shouldn't be having any connection with that simple Spectrogram chain which I've established.

Exact.
Unless you've made something wrong in your patch I can't think of any reason for this to happen... except for a daft bug.

[Angstrom]

But it shouldn't be having any connection with that simple Spectrogram chain which I've established.

Exact.
Unless you've made something wrong in your patch I can't think of any reason for this to happen... except for a daft bug.

Guess which one it was.

I'm not sure what I did different today, but it seems to work fine now.
I can only assume I got my inlets tangled, But I'm not sure how.