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!

Hi, I once tackled this problem but could not manage to solve it either, but your proposed algorithm looks good! I implemented it and it seems to work well:

knob-nbx.pd

I hope this helps, take care,
Gilberto

Interesting! I actually just figured out how to do it right after I posted (it really helped me to think it through once I articulated it here).

nbxandknob.pd

It looks like we did the same thing, I just had everything 'hard wired'.

Hi, thanks for sharing back.

The problem I see with your patch is that your numberbox is quite laggy. Also, if you open the guts on the side to observe the toggles, you will see that when you move the [knob], the left toggle is checked. Now when you move the [nbx], you should get the right toggle checked, but actually you still get the left one! I guess you need some triggers to control the order of the messages.

Take care,
Gilberto

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.