--- On Tue, 1/19/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at Subject: Re: [PD] 'synced' number and slider To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Tuesday, January 19, 2010, 9:04 AM Jonathan Wilkes wrote:
--- On Sun, 1/17/10, zmoelnig@iem.at
zmoelnig@iem.at wrote:
the send/receive "magic" in the iemguis are
explicitely
designed to allow the same send/receive names in
order to
sync several different objects.
So is it a bug that sending input to the inlet of one
GUI doesn't
set the value for all other GUI's with the same
send/receive name?
no. it's a "side effect" (if you are nasty, you could also call it a "bug" with "won't fix" status :-)).
the rule is simple: if (and only if) a iemgui object has the same send- & receive-name, then it will not pass (be it via send or via it's outlet) any messages it gets (be it via receive, or via it's inlet).
The rule is a little more complicated: if (and only if) an iemgui object has the same send/receive name, then: a) it will not pass any messages it gets via its inlet to the outlet and b) it will not set value of the other iemguis that share the same send/receive name.
If, however, one of these iemguis receives a message from a [send], msg box, or an iemgui that shares only the same send name: c) it will not pass any messages to the outlet but d) it _will_ set the value on all iemguis that share the same send/receive name.
I see no good reason why b) and d) shouldn't be exactly the same if neither the inlet nor the nonlocal send is going to trigger output.
this rule effectively prevents feedback loops when sharing send/receive names, while still allowing to update controllers individually.
What does preventing feedback loops have to do with it? It's trivial to prevent them using [set $1( and [send]/[receive] in a pd patch (see my example earlier in this thread), so why is it any more difficult with the iemgui magic? I don't program well in c so I'm curious about this.
I originally thought the magic to be:
- automatically set all values when moving one linked iemgui with mouse
- automatically set all values when sending message through inlet or
nonlocal send
3) change the value for only one iemgui when sending a "set" message
to its inlet.
4) only trigger output on one iemgui when moving it with mouse OR when
sending a message to its inlet (since the wire connection is
explicitly local). I'm just assuming the iemgui can detect the difference
between inlet vs. nonlocal since they currently have different behaviors.
If the magic worked this way, it would be as if the receive names for all the linked iemguis have an invisible [set $1( in front of them. I don't think I'm the only one who thought it behaves this way-- for example, see the rightmost inlet of Hans' [output~] object, which would work if the iemgui magic were as I described above.
-Jonathan
mfgasdr IOhannes