[PD] 'synced' number and slider

[Jonathan Wilkes]

--- On Fri, 1/29/10, Simon Wise <simonzwise at gmail.com> wrote:

> From: Simon Wise <simonzwise at gmail.com>
> Subject: Re: [PD] 'synced' number and slider
> To: "IOhannes m zmoelnig" <zmoelnig at iem.at>
> Cc: "Jonathan Wilkes" <jancsika at yahoo.com>, pd-list at iem.at
> Date: Friday, January 29, 2010, 4:50 AM
> IOhannes m zmoelnig wrote:
> > Jonathan Wilkes wrote:
> >> In other words, whether you send a value through
> an inlet to one of the linked iemguis, or use [send] to send
> a value to all the linked iemguis, it should set the value
> on all linked iemguis.
> > 
> > so how do you control a single iemgui then? (without
> side-effects to the
> >  linked friends?)
> 
> I often use linked sliders, to duplicate controls in
> different places, but rarely connect the inlets/outlets and
> only use the send/receive symbols and the mouse. It can save
> quite a bit of messing around controlling the sync manually,
> especially when an external control surface like the BFC2000
> is used. I assumed that the reason the graphical
> representation of these inlets and outlets disappear when
> the send and receive symbols are the same is that they
> become almost useless. When this special behaviour isn't
> what I want I use two different symbols.
> 
> Occasionally I have used the outlets, for special cases
> where slightly different behaviour is required depending on
> which slider was moved, and I guess the inlet is the way it
> is because it behaves internally the same as the receive
> symbol ... anyway it can be useful for some kinds of visual
> feedback, if used carefully.

Hi Simon,
     Thanks for the detailed reply.  It got me wondering a bit about the 
disappearing inlets/outlets on iemguis.

(For the following, "xlet" means inlet and/or outlet)

>From what I can tell, disappearing xlets currently have two different 
meanings in pd (maybe more if there are externals that add some other 
meaning):
1) for gatom: when an xlet disappears it means a) you can no longer 
connect a wire to/from that xlet because b) that functionality has been 
replaced with a hidden nonlocal connection (specified under "Properties" 
by a send/receive symbol).
2) for iemguis: when an xlet disappears it means a) the (now 
invisible) xlet has been _supplemented_ with a hidden, nonlocal connection 
specified by a send/receive symbol, and additionally:
IF the send/receive symbol is the same, the output (other than that 
triggered with the mouse) will be suppressed-- otherwise the output will 
function as it normally does.

On top of this, there's the additional issue of whether the missing 
xlets on an iemgui are functional (passing messages somewhere in the 
patch) or aesthetic (have names like "$0-DUMMY-RCV-TO-MAKE-MY-BNGS-LOOK 
PRETTY").

To me, the aesthetic reason seems like the best justification for 
removing xlets visually on an iemgui: in this case, maybe the suppression 
of xlets (globally) could be associated with GOPs*, or only happen in 
runmode, with a tcl plugin.

I personally prefer iemgui flexibility over gatom's behavior.  But for 
patching clarity i think it would be best if something like the following 
were the behavior:
a) when one send or receive symbol is used (or two with different names) 
the xlet on the iemgui remains visible, and there's some additional visual 
cue (independently for each xlet) that hidden nonlocal connections are in 
play (maybe paint them red?)
b) when an iemgui send/receive pair is given the same symbol, a different 
visual cue is used to identify the suppresion of output (maybe greyed out 
outlet, and turns black when output is triggered with the mouse).

* Or GOP Properties could have checkboxes to set this and other behavior: 
e.g., show or hide xlets, connections, non-GUI objects, msg boxes; allow 
or disallow editing visible objects in the GOP window in editmode, etc.

-Jonathan