Jonathan Wilkes wrote:
--- On Tue, 1/19/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
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.
hmm, probably we should consult the documentation on [send]/[receive].
what happens if you have one [send foo] object and multiple [receive foo] objects?. who will set the value in d) ?
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?
everything. it's the reason why it is like it is.
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 don't see what is difficult here. you specify the same send/receive name and you don't get feedbacks.
if you want to build the logic manually, then you can do so. if you don't want the automatic feedback suppression, then create iemgui objects with the same send/receive name. (that's also the reason why the ordinary gatom boxes do not allow you to have the same send/receive name). using "set" is not a real option, as the idea also extends to non-settable objects like [bng].
explicitly local). I'm just assuming the iemgui can detect the difference between inlet vs. nonlocal since they currently have different behaviors.
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)
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.
is this the object referenced in [1]?. you seem to imply that it "doesn't work", but i don't know anything about this (and i read this list a lot). does it crash Pd, or how does the "not working" manifest itself?
if it's not doing anything, than this is mainly a problem of the implementation of [output~], not of the underlying iemguis. (one could argue that the behaviour is badly documented; i have not written the code, but i have talked a lot about it with the original author (and afaik it is still pretty much untouched - which is _a good thing_ if you don't want to break a lot of patches) whom i happen to share an office with...
anyhow, attached is a slightly modified version of the [output~] found in [1] which seems to "work" (though i wouldn't release the object as such with all the kludges for logarithmic and scales and the like. there is a good reason why mixing is usually done on a dB scale; the object with an enabled rightmost inlet is probably the way to blow your PA)
and it is really no "magic".
fgmasdr IOhannes
[1] http://lists.puredata.info/pipermail/pd-list/2009-03/068966.html
#N canvas 146 25 548 407 10; #X obj 13 108 hsl 67 18 0.01 1 1 0 $0-v $0-v volume 20 10 1 9 -228856 -123526 -1 0 1; #X obj 82 90 tgl 18 0 THIS_IS_HERE_TO_GET_RID_OF_THE_OUTLET $0-dsp-toggle dsp 2 9 1 9 -24198 -24198 -33289 1 1; #N canvas 366 514 482 356 dsp 0; #X obj 11 7 inlet; #X obj 92 226 select 0 1; #X msg 125 248 76; #X obj 92 57 route dsp; #X obj 92 36 receive pd; #X obj 206 138 loadbang; #X msg 11 220 dsp $1; #X obj 11 245 send pd; #X msg 206 278 set $1; #X obj 206 174 value GLOBAL_PDDP_DSP; #X msg 109 278 color $1 $1 12; #X obj 180 309 send $0-dsp-toggle; #X msg 92 248 6; #X obj 92 115 change; #X connect 0 0 6 0; #X connect 0 0 13 0; #X connect 1 0 12 0; #X connect 1 1 2 0; #X connect 2 0 10 0; #X connect 3 0 13 0; #X connect 4 0 3 0; #X connect 5 0 9 0; #X connect 6 0 7 0; #X connect 8 0 11 0; #X connect 9 0 8 0; #X connect 9 0 1 0; #X connect 10 0 11 0; #X connect 12 0 10 0; #X connect 13 0 8 0; #X connect 13 0 1 0; #X connect 13 0 9 0; #X restore 112 118 pd dsp logic; #X obj 375 2 inlet; #X obj 82 108 bng 18 1000 50 0 THIS_IS_HERE_TO_GET_RID_OF_THE_OUTLET GLOBAL_PDDP_MUTE_TOGGLE empty 0 9 2 8 -261234 -258113 -1; #X obj 191 2 inlet~; #X obj 85 293 line~; #X obj 176 353 *~; #X obj 196 383 dac~; #X text 216 22 audio in; #X obj 254 2 inlet~; #X obj 238 352 *~; #X obj 191 293 hip~ 3; #X obj 253 293 hip~ 3; #X obj 12 308 send pd; #X msg 12 287 dsp 1; #X obj 238 382 outlet~; #X obj 138 382 outlet~; #X obj 299 389 outlet; #N canvas 191 578 450 300 mute 0; #X obj 41 14 inlet; #X obj 173 20 inlet; #X obj 172 234 float; #X obj 215 131 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 172 162 spigot; #X obj 172 41 trigger bang bang; #X obj 200 272 outlet; #X msg 224 218 0; #X obj 224 163 select 0; #X msg 117 75 set 1; #X obj 41 39 t b f; #X connect 0 0 10 0; #X connect 1 0 5 0; #X connect 2 0 6 0; #X connect 3 0 4 1; #X connect 3 0 8 0; #X connect 4 0 2 0; #X connect 5 0 4 0; #X connect 5 1 3 0; #X connect 7 0 6 0; #X connect 8 0 7 0; #X connect 9 0 3 0; #X connect 10 0 9 0; #X connect 10 1 2 1; #X restore 85 176 pd mute; #X obj 85 266 pack 0 50; #X text 152 265 <-- make a ramp to avoid clicks or zipper noise; #X obj 85 204 - 0.01; #X obj 375 67 s $0-v; #X obj 10 131 r $0-v; #X obj 10 153 t f b f f; #X obj 375 46 + 0.01; #X obj 85 226 max 0; #X obj 375 24 abs; #X connect 1 0 2 0; #X connect 3 0 28 0; #X connect 4 0 19 1; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 7 0 17 0; #X connect 10 0 13 0; #X connect 11 0 8 1; #X connect 11 0 16 0; #X connect 12 0 7 1; #X connect 13 0 11 1; #X connect 15 0 14 0; #X connect 19 0 0 0; #X connect 19 0 22 0; #X connect 20 0 6 0; #X connect 22 0 27 0; #X connect 24 0 25 0; #X connect 25 0 18 0; #X connect 25 1 15 0; #X connect 25 2 19 0; #X connect 25 3 22 0; #X connect 26 0 23 0; #X connect 27 0 20 0; #X connect 28 0 26 0; #X coords 0 0 1 1 90 39 1 10 90;