1

I am getting unexpected results from [spigot], for example:

Piping 4.9 to spigot guarding for above 5, but output is 4.9

Here, I would never expect an output below (or equal to) 5. However, sometimes it does happen, demonstrated in the above screenshot.

Could someone please explain,

  • Why this happens?
    • Is there a delay introduced in the [> 5] branch?
    • Is this because of "wiring order"?
  • Whether it's possible to fix it, and how?
Max N
  • 1,134
  • 11
  • 23
P Varga
  • 19,174
  • 12
  • 70
  • 108

1 Answers1

2

This happens because of message order. If you connect one atom with two patch cords, the first connected will transmit first. Your patch is not explicit, as I can't see in the resulting patch which was connected first. To avoid this, always use the trigger object. In your case add a [trigger float float] (or [t f f] for a shorthand) after the numberbox.

how to set a minimum float value to pass

Max N
  • 1,134
  • 11
  • 23
  • So `trigger` makes the message order explicit. It's still possible to wire things the wrong way around, but it becomes more apparent if that's the case. However this behaviour, objects remembering their last inputs is somewhat surprising, coming from other prog. langs. Is there a way to enforce that an object should only "recompute" when all its inputs have new values? Maybe it's better to pass a "pair" in my case? (If so, how do I construct one though?) – P Varga Jan 26 '22 at 11:45
  • Ok I realized `[pack f f]` (or `f i`?) is what I need! – P Varga Jan 26 '22 at 11:51
  • Pure Data doesn't know an integer format. All numbers are floats. – Max N Jan 26 '22 at 11:59
  • 1
    Objects remembering their last input in one of the cold inlets is one of the basic principles in Pd, so not surprising at all. – Max N Jan 26 '22 at 16:10