Jonathan Wilkes wrote: >> >> they don't. >> there is no simple way to distinguish between "received" >> messages and >> those that come in through an "inlet". (there are ways, >> involving proxy >> objects; but this opens up another can of worms) > > They do currently cause different behavior (see what I wrote above). If > this is still unclear I can make an example patch later.
no they don't. there are three ways to change the value of an iemgui: #1 "send" it something #2 send something through the "inlet" #3 do GUI interaction (drag the slider) the iemguis cannot distinguish between #1 and #2. so they behave identically. however, they now when #3 happens, so they expose a different behaviour. > > It's just that the incoming value doesn't get sent to the outlet because > the slider has the same send/receive names. When I originally sent my > suggestions to Hans I didn't notice this, and I still don't understand > how it would cause a feedback loop if the value _did_ come out the > outlet of the slider which is connected to the inlet. anyhow, the canonical way is to use send/receive throughout if you share the same send/receive name for iemguis. >> >> >> and it is really no "magic". > > I think it's magic, in the sense that there's no way to implement > this behavior manually in pd. For an iemgui, you (currently) can't > specify separate instructions for dataflow depending on whether the you can just fine: don't use any send/receive names with the iemguis and do the logic on the patch level. the iemgui's "magic" is implemented in C, but it is not so low-level that you cannot implement it in Pd. fmasdr IOhannes
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list