[PD] 'synced' number and slider

[Matteo Sisti Sette]

Hi,

I haven't read the pd-list for a few days so I reply to this a bit late. 
Hope not too much.

Usually, not only I want a number and a slider (and maybe more) to 
remain always "synced", but also to "respond" to any variation of the 
value they control when it is changed from other sources. I know this is 
not very clear so I will illustrate it with an example.

Say for example you want to control the volume (meaning the gain) of 
something. We have:
- a slider for controlling that volume
- a number box controlling the same volume
- the same volume can be controlled via midi
- some object in the patch modifies that volume automatically (for 
example it changes adaptively relative to the volume of something else).

So, first of all we assign this volume a name, e.g. "st-volume" 
(something's volume).

Somewhere there will be a [r st-volume] whose outlet will trigger the 
piece of patch that implements the volume thing (i.e. modulate the 
amplitude of some signal with the received value).

We want:
1) That when you move either the number box or the slider by hand, a 
message is sent to "st-volume" with the value output by the gui element 
you're moving
2) That all the gui elements associated with this volume move together
3) To be able to create an abstraction or subpatch or whatever, that 
receives midi data and "forwards" it to "st-volume". When you do this, 
you don't want to worry about the existence of the numberbox and sliders 
to keep them synced. You just use a [s st-volume] or [; st-volume ...(
4) To do the same to create any piece of patch that changes that volume. 
Indeed the midi thing is just an example and points 3 and 4 are the same 
thing


Basically our number box and slider (ther may be even more that one 
number box and more than one sliders, e.g. in different windows/places, 
of different sizes etc, all linked) must work both as controllers and as 
monitors. But this MUSTN'T be a source of headaches when designing the 
whole patch (to ensure the syncing, and to avoid loops).


So, "my" solution is an abstraction and a convention.

The abstraction, I call it [control_element], is like this:

-------- control_element abstraction ----------------

[r $1-ifsend]
  |
[s $1]

[r $1]
  |
[list prepend set]
  |
[list trim]
  |
[s $1-ifreceive]

------------------------------------------------------


And the convention is that:

1) all numberboxes or sliders (or whatever interface elements, e.g. 
toggles or radio's) that have to be 'linked' to a control named 
<controlname> will have their send- and receive-symbols set to:
   <controlname>-ifsend
   <controlname>-ifreceive

("if" stands for "interface", not conditional "if")

2) While I can place as many such interface elements as I want, for a 
given control there must be one and only one
[control_element <controlname>]


So in our example, we put somewhere a:
[control_element st-volume]

and we configure our slider(s) and number box(es) to send to
   st-volume-ifsend
and receive from
   st-volume-ifreceive


Et voilà.

Note that the same abstraction works for symbols as well as numbers.

You may even use it for lists if you implement some gop-abstraction that 
is capable of receiving a message
"set cis boom bash"
and displaying the "cis boom bash" list somewhere (e.g. by joining the 
symbols with blank spaces and using a canvas' label)


When using the gui to control manually the value, the first half of the 
abstraction "forwards" the messages coming from the gui elements to the 
destination.
The second half does the opposite: when the value is changed with a 
message sent to the target, it catches it and set the gui elements to 
show that.
Note that in the case of using one of the gui objects to change the 
value, the objects receives a redundant, useless "set" messages that 
tell it to update to the value that it has just generated. However, this 
is harmless and doesn't create an infinite loop.


Let me know if my explanation is not clear or you need an example patch.

Bye
m.


--- On Sat, 1/16/10, IOhannes zm?lnig <zmoelnig at iem.at> wrote:

 > > From: IOhannes zm?lnig <zmoelnig at iem.at>
 > > Subject: Re: [PD] 'synced' number and slider
 > > To: "Lorenzo" <lsutton at libero.it>
 > > Cc: pd-list at 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.




-- 
Matteo Sisti Sette
matteosistisette at gmail.com
http://www.matteosistisette.com