I attached a modified version of your patch to show what I mean. On the right, you can look at the patch and figure out the behavior before you scroll the gatom box (important if you want to make sure you're avoiding a buffer overflow).
On the left, you have to read the source code for those GUI objects to figure out what's going to happen. Judging from your original patch, I think you assumed that sending a float straight to the [nbx] would update the value in the slider (so did I). This turns out not to be the case: the two GUIs are only bound together if you change the values on one of them using the mouse.
If someone who reads and understands c better than me can explain why the iemgui magic works as it does, I'll be happy to document it.
-Jonathan
--- On Sat, 1/16/10, Rich E rich.eakin@gmail.com wrote:
From: Rich E rich.eakin@gmail.com Subject: Re: [PD] 'synced' number and slider To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Lorenzo" lsutton@libero.it, "IOhannes zmölnig" zmoelnig@iem.at, pd-list@iem.at Date: Saturday, January 16, 2010, 8:38 PM You can still send the set message directly to the inlet of the numberbox2 or slider and it won't effect the other. See patch.
2010/1/16 Jonathan Wilkes jancsika@yahoo.com
--- On Sat, 1/16/10, IOhannes zmölnig zmoelnig@iem.at wrote:
From: IOhannes zmölnig zmoelnig@iem.at
Subject: Re: [PD] 'synced'
number and slider
To: "Lorenzo" lsutton@libero.it
Cc: pd-list@iem.at
Date: Saturday, January 16, 2010, 11:36 AM
Lorenzo wrote:
This seems trivial but I've never managed to
figure
out how to do it in
a non-trivial way:
Have a number (atom) and a slider (be it
horizontal or
vertical) which
are 'synced', that is if one changes the
number the
slider changes and
vice-versa.
if you use numberbox2 as the numberbox, you can give
both
the nbx and
the slider the same send/receive names
(that is:
numberbox2.sendname=numberbox2.receivename=slider.sendname=slider.receivename)
and they will be magically linked to each other.
to use the value in the patch add another receiver
[r <samereceivename>]
Except if you need to send a value to the inlet of the numbox2 or the slider. Then this method magically doesn't work, whereas the [set $1(
idiom does.
gfmadr
IOhannes
-----Inline Attachment Follows-----
Pd-list@iem.at
mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Quoting "Jonathan Wilkes" jancsika@yahoo.com:
I attached a modified version of your patch to show what I mean. On the right, you can look at the patch and figure out the behavior before you scroll the gatom box (important if you want to make sure you're avoiding a buffer overflow).
On the left, you have to read the source code for those GUI objects to figure out what's going to happen. Judging from your original patch, I think you assumed that sending a float straight to the [nbx] would update the value in the slider (so did I). This turns out not to be the case: the two GUIs are only bound together if you change the values on one of them using the mouse.
that's by intention. if you want to set the values from outside, use [s <samereceivename>]
mfddg IOhannes
This message was sent using IMP, the Internet Messaging Program.
--- On Sun, 1/17/10, zmoelnig@iem.at zmoelnig@iem.at wrote:
From: zmoelnig@iem.at zmoelnig@iem.at Subject: Re: [PD] 'synced' number and slider To: pd-list@iem.at Date: Sunday, January 17, 2010, 7:17 PM Quoting "Jonathan Wilkes" jancsika@yahoo.com:
I attached a modified version of your patch to show
what I mean. On the
right, you can look at the patch and figure out the
behavior before you
scroll the gatom box (important if you want to make
sure you're avoiding
a buffer overflow).
On the left, you have to read the source code for
those GUI objects to
figure out what's going to happen. Judging from
your original patch,
I think you assumed that sending a float straight to
the [nbx] would
update the value in the slider (so did I). This
turns out not to be the
case: the two GUIs are only bound together if you
change the values on one
of them using the mouse.
that's by intention. if you want to set the values from outside, use [s <samereceivename>]
If I just set the same receive-symbol for both GUIs and use a single [s same-receive-symbol] coming from the [nbx], I get a bunch of console messages:
error: stack overflow
-Jonathan
mfddg IOhannes
This message was sent using IMP, the Internet Messaging Program.
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Quoting "Jonathan Wilkes" jancsika@yahoo.com:
If I just set the same receive-symbol for both GUIs and use a single [s same-receive-symbol] coming from the [nbx], I get a bunch of console messages:
error: stack overflow
then you produce a loop in your patch.
the iemguis do their best to prevent such loops (that's what all the
magic is about)
see attached patch
gfmsdr IOhannes
This message was sent using IMP, the Internet Messaging Program.
Ah that is nice, you just don't need the set messages. :)
I always looked at the iem gui objects as more sophisticated and better for GUI front ends, not meant for writing a self-documenting patch. They save time and look/act better, but everyone I have met using pd for educational purposes uses the more simple numberbox.
rich
On Sun, Jan 17, 2010 at 12:23 AM, Jonathan Wilkes jancsika@yahoo.comwrote:
I attached a modified version of your patch to show what I mean. On the right, you can look at the patch and figure out the behavior before you scroll the gatom box (important if you want to make sure you're avoiding a buffer overflow).
On the left, you have to read the source code for those GUI objects to figure out what's going to happen. Judging from your original patch, I think you assumed that sending a float straight to the [nbx] would update the value in the slider (so did I). This turns out not to be the case: the two GUIs are only bound together if you change the values on one of them using the mouse.
If someone who reads and understands c better than me can explain why the iemgui magic works as it does, I'll be happy to document it.
-Jonathan
--- On Sat, 1/16/10, Rich E rich.eakin@gmail.com wrote:
From: Rich E rich.eakin@gmail.com Subject: Re: [PD] 'synced' number and slider To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Lorenzo" lsutton@libero.it, "IOhannes zmölnig" zmoelnig@iem.at,
pd-list@iem.at
Date: Saturday, January 16, 2010, 8:38 PM You can still send the set message directly to the inlet of the numberbox2 or slider and it won't effect the other. See patch.
2010/1/16 Jonathan Wilkes jancsika@yahoo.com
--- On Sat, 1/16/10, IOhannes zmölnig zmoelnig@iem.at wrote:
From: IOhannes zmölnig zmoelnig@iem.at
Subject: Re: [PD] 'synced'
number and slider
To: "Lorenzo" lsutton@libero.it
Cc: pd-list@iem.at
Date: Saturday, January 16, 2010, 11:36 AM
Lorenzo wrote:
This seems trivial but I've never managed to
figure
out how to do it in
a non-trivial way:
Have a number (atom) and a slider (be it
horizontal or
vertical) which
are 'synced', that is if one changes the
number the
slider changes and
vice-versa.
if you use numberbox2 as the numberbox, you can give
both
the nbx and
the slider the same send/receive names
(that is:
numberbox2.sendname=numberbox2.receivename=slider.sendname=slider.receivename)
and they will be magically linked to each other.
to use the value in the patch add another receiver
[r <samereceivename>]
Except if you need to send a value to the inlet of the numbox2 or the slider. Then this method magically doesn't work, whereas the [set $1(
idiom does.
gfmadr
IOhannes
-----Inline Attachment Follows-----
Pd-list@iem.at
mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
--- On Sun, 1/17/10, Rich E rich.eakin@gmail.com wrote:
From: Rich E rich.eakin@gmail.com Subject: Re: [PD] 'synced' number and slider To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Lorenzo" lsutton@libero.it, "IOhannes zmölnig" zmoelnig@iem.at, pd-list@iem.at Date: Sunday, January 17, 2010, 7:31 PM Ah that is nice, you just don't need the set messages. :) I always looked at the iem gui objects as more sophisticated and better for GUI front ends, not meant for writing a self-documenting patch. They save time and look/act better, but everyone I have met using pd for educational purposes uses the more simple numberbox.
I don't think writing a self-documenting patch and the use of iem gui objects are mutually exclusive; after all, I use iem guis in the example patch you are referring to.
It's just that for the particular behavior of linking two iem guis, I wouldn't rely on whatever it is that happens when you make all the send/receive names the same. Instead, I would use something like the "explicitly patched" version and shove it all in a gop. Then if you decide after many months that you want to send a value to one of the iem guis, for example, and have all the linked iem guis update their values, it will work (and you can easily check for bugs by opening the gop window). If you try the same thing with the send/receive name trick, it will fail, and if you're like me and have a hard time reading the source code, then there's (currently) no quick way to figure out why it doesn't work because it's not documented in the help patches for the iem guis.
-Jonathan
rich
On Sun, Jan 17, 2010 at 12:23 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
I attached a modified version of your patch to show what I mean. On the
right, you can look at the patch and figure out the behavior before you
scroll the gatom box (important if you want to make sure you're avoiding
a buffer overflow).
On the left, you have to read the source code for those GUI objects to
figure out what's going to happen. Judging from your original patch,
I think you assumed that sending a float straight to the [nbx] would
update the value in the slider (so did I). This turns out not to be the
case: the two GUIs are only bound together if you change the values on one
of them using the mouse.
If someone who reads and understands c better than me can explain why
the iemgui magic works as it does, I'll be happy to document it.
-Jonathan
--- On Sat, 1/16/10, Rich E rich.eakin@gmail.com wrote:
From: Rich E rich.eakin@gmail.com
Subject: Re: [PD] 'synced'
number and slider
To: "Jonathan Wilkes" jancsika@yahoo.com
Cc: "Lorenzo" lsutton@libero.it,
"IOhannes zmölnig" zmoelnig@iem.at, pd-list@iem.at
Date: Saturday, January 16, 2010, 8:38 PM
You can still send the
set message directly
to the inlet of the numberbox2 or slider and it
won't
effect the other. See patch.
2010/1/16 Jonathan Wilkes jancsika@yahoo.com
--- On Sat, 1/16/10, IOhannes zmölnig zmoelnig@iem.at
wrote:
From: IOhannes zmölnig zmoelnig@iem.at
Subject: Re: [PD] 'synced'
number and slider
To: "Lorenzo" lsutton@libero.it
Cc: pd-list@iem.at
Date: Saturday, January 16, 2010, 11:36 AM
Lorenzo wrote:
This seems trivial but I've never
managed to
figure
out how to do it in
a non-trivial way:
Have a number (atom) and a slider (be it
horizontal or
vertical) which
are 'synced', that is if one changes
the
number the
slider changes and
vice-versa.
if you use numberbox2 as the numberbox, you can
give
both
the nbx and
the slider the same send/receive names
(that is:
numberbox2.sendname=numberbox2.receivename=slider.sendname=slider.receivename)
and they will be magically linked to each other.
to use the value in the patch add another
receiver
[r <samereceivename>]
Except if you need to send a value to the inlet
of the numbox2 or the slider. Then this method
magically
doesn't work, whereas the [set $1(
idiom does.
gfmadr
IOhannes
-----Inline Attachment Follows-----
Pd-list@iem.at
mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at
mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Quoting "Jonathan Wilkes" jancsika@yahoo.com:
I don't think writing a self-documenting patch and the use of iem gui objects are mutually exclusive; after all, I use iem guis in the example patch you are referring to.
It's just that for the particular behavior of linking two iem guis, I wouldn't rely on whatever it is that happens when you make all the send/receive names the same. Instead, I would use something like the "explicitly patched" version and shove it all in a gop. Then if you decide after many months that you want to send a value to one of the iem guis, for example, and have all the linked iem guis update their values, it will work (and you can easily check for bugs by opening the gop window). If you try the same thing with the send/receive name trick, it will fail, and if you're like me and have a hard time reading the source code, then there's (currently) no quick way to figure out why it doesn't work because it's not documented in the help patches for the iem guis.
the send/receive "magic" in the iemguis are explicitely designed to
allow the same send/receive names in order to sync several different
objects.
of course you can do this explicitely. iemguis just help to make this simpler.
mfgasdr IOhannes
This message was sent using IMP, the Internet Messaging Program.
--- On Sun, 1/17/10, zmoelnig@iem.at zmoelnig@iem.at wrote:
From: zmoelnig@iem.at zmoelnig@iem.at Subject: Re: [PD] 'synced' number and slider To: pd-list@iem.at Date: Sunday, January 17, 2010, 8:20 PM Quoting "Jonathan Wilkes" jancsika@yahoo.com:
I don't think writing a self-documenting patch and the
use of iem gui
objects are mutually exclusive; after all, I use iem
guis in the example
patch you are referring to.
It's just that for the particular behavior of linking
two iem guis, I
wouldn't rely on whatever it is that happens when you
make all the
send/receive names the same. Instead, I would
use something like the
"explicitly patched" version and shove it all in a
gop. Then if you
decide after many months that you want to send a value
to one of the iem
guis, for example, and have all the linked iem guis
update their values,
it will work (and you can easily check for bugs by
opening the gop
window). If you try the same thing with the
send/receive name trick,
it will fail, and if you're like me and have a hard
time reading the
source code, then there's (currently) no quick way to
figure out why it
doesn't work because it's not documented in the help
patches for the
iem guis.
the send/receive "magic" in the iemguis are explicitely designed to allow the same send/receive names in order to sync several different objects.
So is it a bug that sending input to the inlet of one GUI doesn't set the value for all other GUI's with the same send/receive name?
-Jonathan
of course you can do this explicitely. iemguis just help to make this simpler..
mfgasdr IOhannes
This message was sent using IMP, the Internet Messaging Program.
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Jonathan Wilkes wrote:
--- On Sun, 1/17/10, zmoelnig@iem.at zmoelnig@iem.at wrote:
the send/receive "magic" in the iemguis are explicitely designed to allow the same send/receive names in order to sync several different objects.
So is it a bug that sending input to the inlet of one GUI doesn't set the value for all other GUI's with the same send/receive name?
no. it's a "side effect" (if you are nasty, you could also call it a "bug" with "won't fix" status :-)).
the rule is simple: if (and only if) a iemgui object has the same send- & receive-name, then it will not pass (be it via send or via it's outlet) any messages it gets (be it via receive, or via it's inlet).
this rule effectively prevents feedback loops when sharing send/receive names, while still allowing to update controllers individually.
mfgasdr IOhannes
--- On Tue, 1/19/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: Tuesday, January 19, 2010, 9:04 AM Jonathan Wilkes wrote:
--- On Sun, 1/17/10, zmoelnig@iem.at
zmoelnig@iem.at wrote:
the send/receive "magic" in the iemguis are
explicitely
designed to allow the same send/receive names in
order to
sync several different objects.
So is it a bug that sending input to the inlet of one
GUI doesn't
set the value for all other GUI's with the same
send/receive name?
no. it's a "side effect" (if you are nasty, you could also call it a "bug" with "won't fix" status :-)).
the rule is simple: if (and only if) a iemgui object has the same send- & receive-name, then it will not pass (be it via send or via it's outlet) any messages it gets (be it via receive, or via it's inlet).
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.
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? 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 originally thought the magic to be:
- automatically set all values when moving one linked iemgui with mouse
- automatically set all values when sending message through inlet or
nonlocal send
3) change the value for only one iemgui when sending a "set" message
to its inlet.
4) only trigger output on one iemgui when moving it with mouse OR when
sending a message to its inlet (since the wire connection is
explicitly local). I'm just assuming the iemgui can detect the difference
between inlet vs. nonlocal since they currently have different behaviors.
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.
-Jonathan
mfgasdr IOhannes
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;
--- 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
Jonathan Wilkes wrote:
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.
so how do you control a single iemgui then? (without side-effects to the linked friends?)
fmgasdr IOhannes
IOhannes m zmoelnig wrote:
Jonathan Wilkes wrote:
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.
so how do you control a single iemgui then? (without side-effects to the linked friends?)
I often use linked sliders, to duplicate controls in different places, but rarely connect the inlets/outlets and only use the send/receive symbols and the mouse. It can save quite a bit of messing around controlling the sync manually, especially when an external control surface like the BFC2000 is used. I assumed that the reason the graphical representation of these inlets and outlets disappear when the send and receive symbols are the same is that they become almost useless. When this special behaviour isn't what I want I use two different symbols.
Occasionally I have used the outlets, for special cases where slightly different behaviour is required depending on which slider was moved, and I guess the inlet is the way it is because it behaves internally the same as the receive symbol ... anyway it can be useful for some kinds of visual feedback, if used carefully.
But ... controlling a single GUI using its inlet is deceptive - the position on the slider changes but this value is not output in any way, does not alter the linked sliders and does not reflect the last value of the s/r symbol ... the position of the GUI may or may not have been sent to the [r] depending on whether it was moved by the mouse or by the inlet.
If I then bang the input, or move the slider a little, or click on the GUI, so that this new value is sent then all the GUIs are moved to this position, the [r] gets the new value and the local outlet gets the value but the other outlets don't - matching the behaviour when I move a single GUI.
Simon
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
--- 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, 6:34 PM 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.
Ok, I've got it now. There is disparate behavior, but it is due to the difference in behavior between a single wire connection vs. the [send] object. So I think this is just a documentation issue which can be solved by putting the "simple rule" you mentioned in the help patches for iemgui objects.
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.
Yes. Disregard this.
fmasdr IOhannes
First of all, thanks for all the input, didn't think such a trivial question would arise such a fruitful discussion :)
the send/receive "magic" in the iemguis are explicitely designed to allow the same send/receive names in order to sync several different objects. of course you can do this explicitely. iemguis just help to make this simpler.
Nice. It was a point about the iem gui objects I was missing/overlooking.
Bests, Lorenzo.
-
IOhannes m zmoelnig -
Jonathan Wilkes -
Lorenzo -
Rich E -
Simon Wise -
zmoelnig＠iem.at