[PD] 'synced' number and slider

Jonathan Wilkes jancsika at yahoo.com
Thu Jan 28 18:06:43 CET 2010



--- On Thu, 1/28/10, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:

> From: IOhannes m zmoelnig <zmoelnig at iem.at>
> Subject: Re: [PD] 'synced' number and slider
> To: "Jonathan Wilkes" <jancsika at yahoo.com>
> Cc: pd-list at iem.at
> Date: Thursday, January 28, 2010, 9:54 AM
> Jonathan Wilkes wrote:
> > 
> > --- On Tue, 1/19/10, IOhannes m zmoelnig <zmoelnig at 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
> 
> 
> 


      





More information about the Pd-list mailing list