Hi folks!

I was creating a metronome GUI today and gave myself a bit of a conceptual problem that I am struggling with. In my patch I have a knob that controls tempo, and a number box that displays BPM. Both the [knob] and the [nbx] send the tempo data to my metro patch (in case I want to select tempo with the knob or just type it in).

My problem: what if I want the changes made in one to be reflected in the other? To make my changes from the [knob] reflect in the [nbx], I just connect the outlet of the [knob] to the [nbx] inlet (DUH!). But what if I also want any changes made in the [nbx] to be reflected in the [knob] as well? Connecting the outlet of [nbx] to [knob] just produces a stack overflow.

I suspect I need some kind of mechanism to output a bang only when the [nbx] changes, connected to a [spigot] so that when the [nbx] changes, it updates the [knob] but the knob's output is momentarily silenced, and vice versa. So far I'm stumped!

Hmm, I just realized mine is doing pretty much the same thing...

Wow you're right! My number box isn't laggy, but those toggles should be switching. It might be a visual glitch because before I put everything in the suppatch it worked as expected. I will check it out later tonight. Thanks for the feedback.

It is not a visual glitch, I actually figure it out: they switch, but extremely quickly! But quick enough to just let one message through, thus avoiding the stack overflow. The fact that always the same toggle stays on is due to the way the connections were made, it could have easily been the other way around. If you'd connect toggles to my code, the result would be identical!

Woah that's crazy! Thanks for the help.

Hi all.
I think I know how to solve the problem.
Use [set $1(.

Download the patch:
mutual update.pd
You can avoid including the first [set $1( , if you want. Simply connect the output of the knob to the input of the number box. I only included the first [set $1( for the sake of completion! I mean, you can solve the problem with only one [set $1(.

I hope I have understood the problem instead of producing some communicational noise.

The explanation: [set $1( establishes the content of another object but doesn't force it to pass that info to the next step. It just "sets" the other object...and that's it...no overflow, no exploding cpus, no galaxy-swallowing black hole...

@LandonPD , this is simply fantastic!! So simple and elegant, I wish I could upvote your post more than once!

I was also not aware that we could use [set <something>( to anything other than messages!

@LandonPD Well I'm pretty sure you just discovered the simplest way! I too was under the assumption that [set( only applied to messages.

OK, glad you find it useful! Whenever you find sthg that overflows, try using [set $1( to avoid info from circulating.