--- On Thu, 1/28/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at Subject: Re: [PD] 'synced' number and slider To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Thursday, January 28, 2010, 9:54 AM 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) ?
Sorry, I said, "If, however, one of these iemguis receives" when I should have said, "If, however, all the linked iemguis receive..."
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.
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.
But why is it necessary to suppress the output from the linked iemgui that's receiving a message at its inlet? I don't see how that would cause a feedback loop.
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)
They do currently cause different behavior (see what I wrote above). If this is still unclear I can make an example patch later.
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?
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.
-Jonathan
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".
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
incoming message came from the mouse or an inlet. (You can for data
structures, though.)
-Jonathan
fgmasdr IOhannes