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:
- 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:
- 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")
- 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@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.
-
Matteo Sisti Sette