--- On Fri, 1/29/10, Simon Wise simonzwise@gmail.com wrote:
From: Simon Wise simonzwise@gmail.com Subject: Re: [PD] 'synced' number and slider To: "IOhannes m zmoelnig" zmoelnig@iem.at Cc: "Jonathan Wilkes" jancsika@yahoo.com, pd-list@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):
- 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
-
Jonathan Wilkes