--- On Tue, 1/19/10, IOhannes m zmoelnig <[email protected]> wrote:
> From: IOhannes m zmoelnig <[email protected]> > Subject: Re: [PD] 'synced' number and slider > To: "Jonathan Wilkes" <[email protected]> > Cc: [email protected] > Date: Tuesday, January 19, 2010, 9:04 AM > Jonathan Wilkes wrote: > > > > --- On Sun, 1/17/10, [email protected] > <[email protected]> > 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: 1) automatically set all values when moving one linked iemgui with mouse 2) 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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
