[PD] flashing a bng without making it send?

Luke Iannini (pd) lukexipd at gmail.com
Tue Mar 18 12:18:51 CET 2008


Hi Matteo,
I wanted the same once, here's what I came up with.

Cheers
Luke

On Tue, Mar 18, 2008 at 3:53 AM, matteo sisti sette
<matteosistisette at gmail.com> wrote:
> Hi,
>
>  Is there a way to make a [bng] visually "flash" (the same it does when
>  you click it or send it a bang) WITHOUT making it output/send a bang?
>
>  I think there isn't, but maybe I just haven't found it.
>
>  I often use gui objects as both control and display elements. For
>  example, when I have a slider that controls a volume, you can touch
>  the slider to manually change the volume, but if the volume is changed
>  from some other "source", the slider moves to reflect this change.
>  Same with numbers, radios, symbols, toggles, etc. This can be easily
>  achieved by using [set ...( messages, that change the displayed value
>  of the gui object without triggering its output.
>
>  So it would be great to be able to do the same with a [bng], but I
>  miss a "set" (or analoguous) message for this object.
>
>  It's not that I can't figure out a way to achieve a bang that can be
>  used as a control and display at the same time (you click it: it does
>  the action; the action is triggered by something else: the bang
>  flashes), but it would be much more "tricky" and doesn't lend itself
>  (as far as I can figure out) to elegant and general solutions as it
>  happens with other gui objects. Or perhaps it's just a matter of
>  writing a more complex abstraction than the one I use for other
>  controls.....
>
>  Now, just in case it may be useful to anybody, I thought I would share
>  the solution I use for non-bng controls. I'm sure most of you already
>  use something similar.
>  Here's how it works.
>
>  First of all, every control (a volume, a pitch, a speed, anything) has
>  a name, that is the name everybody sends values to when they want to
>  change that parameter. This means that somewhere there is a [r <name>]
>  that actually does something with those values.
>  So, I create an abstraction called [control_element], which in its
>  most simplified form is like this:
>
>  --------------------control_element.pd------------------
>  [r $1-if-send]
>  |
>  [s $1]
>
>  [r $1]
>  |
>  [set $1(
>  |
>  [s $1-if-receive]
>  -------------------------------------------------------------------
>
>  its creation argument $1 is the name of the control.
>
>  So, for any control called "xxx" that needs to have a control/display
>  gui element, you place one (and only one) instance of [control_element
>  xxx].
>
>  Now, any gui object (slider, number box, symbol box, toggle, etc) that
>  is meant to work as a control/display for control xxx, simply needs to
>  have its send and receive symbols set to "xxx-if-send" and
>  "xxx-if-receive" respectively.
>
>  Note that you can place multiple interface elements for the same
>  control. For example, you can place a number box and a slider
>  associated to xxx. When you move the slider, the number moves; when
>  you move the number, the slider moves: and when anybody else in the
>  patch sends a value to xxx (and he doesn't need to know anything about
>  the existence of control_element and gui objects), both the number and
>  the slider are updated.
>
>  The same abstraction works for both numbers and symbols.
>
>  There is a redundant loop (not an infinite loop) when you manually
>  move the gui element: the gui element sends out the value and
>  immediately receives a [set( message that sets it to the same value;
>  but that's harmless afaics.
>
>  It would be fine to do something similar that could work with bangs...
>
>  --
>  Matteo Sisti Sette
>  matteosistisette at gmail.com
>  http://www.matteosistisette.com
>
>  _______________________________________________
>  PD-list at iem.at mailing list
>  UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SettableBang.pd
Type: application/octet-stream
Size: 756 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080318/2395d4de/attachment.obj>


More information about the Pd-list mailing list