I see Istvan's point.

With button type 1, I always click with a mouse (haven't even tried the
keyboard). At any rate, my conception is that of a trigger - much like the
"triggering i" option currently implemented. This button, for me, is
concerned *only* with event beginnings, not endings (or, rather, only one
and not the other).

Since there is a synchronization issue, I'd suggest a small, set number of
"samples" at 1, auto-returning to 0. As Andres is asking, enough 1's to make
sure there is at least a single 1 during a Csound control cycle.

For triggering purposes (i.e., use with the trigger opcode), one *or more*
1's work. The important element is to be back at 0 again before the user
issues another click - which in the case of repetitive mouse clicks can be
fairly fast.

I'd certainly be happy to come up with a test example, to try with
repetitive mouse clicks. BTW, does the FLTK thread "run at the same speed on
all machines - that is, can you depend on the speed of its data?

Art Hunkins

----- Original Message ----- 
From: "Andres Cabrera" 
To: 
Sent: Wednesday, May 31, 2006 8:18 AM
Subject: Re: [Csnd] Should FLbutton behave like this?


I would really like this behavior. It would be a bit unexpected, but I
think it would be better than the one we have now if it is well
documented.

Could it happen that if you press the button with the mouse for a very
short time with high ksmps, that the event is missed?

Cheers,
Andrés

On Wed, 2006-05-31 at 12:25 +0200, Istvan Varga wrote:
> On Tuesday 30 May 2006 16:24, Art Hunkins wrote:
>
> > Indeed, it has always bothered me that button type 1 didn't put out a
simple
> > trigger - a single 1 when the button is pressed, otherwise zero. And,
yes,
> > I'm making this as a possible feature request.
>
> Having a single "1" output for one control period is not easy to
implement,
> because the button does not run at k-rate, but is rather called
> asynchronously from a callback. So, it is possible to have the output
> set to the "ion" value when the button is pushed (i.e. the orchestra is
> responsible for clearing it to "ioff" later), or maybe "ion" while the
> button is held in the "down" position and "ioff" otherwise - but this
> would only work when the button is clicked with the mouse, and not when
> used with the keyboard.
> Is the first solution (only setting to "ion" when activated) acceptable ?

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Hi Istvan,
I think this behavior is sufficient, I'll document it. This behavior
does not apply to FLbutbank, right?

Thanks,
Andrés

On Wed, 2006-05-31 at 17:09 +0200, Istvan Varga wrote:
> On Wednesday 31 May 2006 17:53, Art Hunkins wrote:
> 
> > Since there is a synchronization issue, I'd suggest a small, set number of
> > "samples" at 1, auto-returning to 0. As Andres is asking, enough 1's to make
> > sure there is at least a single 1 during a Csound control cycle.
> 
> As I already explained, this is more difficult to implement. There are
> already changes so the button type 1 sets the "ion" value when clicked,
> but the orchestra is responsible for resetting the output variable once
> the state change has been detected. Alternatively, the output could
> alternate between the "on" and "off" states, although this is less
> intuitive. Outputting "ion" while the button is down, and "ioff"
> otherwise is also possible, but would limit the use of the button to
> the mouse only.

Thanks, fixed.

Cheers,
Andrés
On Thu, 2006-06-01 at 12:10 +0200, Istvan Varga wrote:
> Note that FLbutton sets the output to the values specified
> with "ion" and "ioff", and not 1 and 0 as described in the
> manual.
> 
> On Wednesday 31 May 2006 18:25, Andres Cabrera wrote:
> 
> > I think this behavior is sufficient, I'll document it.