[PD] 'synced' number and slider

[IOhannes m zmoelnig]

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) ?

> 
>> 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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: output~.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100128/e4961612/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100128/e4961612/attachment.bin>