[PD] 'synced' number and slider

Jonathan Wilkes jancsika at yahoo.com
Thu Jan 28 05:01:07 CET 2010



--- On Tue, 1/19/10, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:

> From: IOhannes m zmoelnig <zmoelnig at iem.at>
> Subject: Re: [PD] 'synced' number and slider
> To: "Jonathan Wilkes" <jancsika at yahoo.com>
> Cc: pd-list at iem.at
> Date: Tuesday, January 19, 2010, 9:04 AM
> Jonathan Wilkes wrote:
> > 
> > --- On Sun, 1/17/10, zmoelnig at iem.at
> <zmoelnig at 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:
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
> 


      





More information about the Pd-list mailing list