Slider Bar Events - Best Practice?

[billko]

I guess the problem is that this isn't the way a slider is supposed to work.  Think of a volume slider on an audio mixer panel.  It constantly adjusts the gain on that track as you move the slider; it doesn't wait until you let go.

Maybe the easiest solution is to make a button that "locks in" the value of the slider.  The slider has no events, but when the "lock" button is pressed, it reads whatever value the slider is set at.

[DailyDose]

---

@altenbach wrote:

---

@DailyDose wrote:
I was able to scroll from 0 to 70 in 2 seconds and triggered 150 events.  Includes time it took me to mouse from play and to click stop.

---

Yes, if the event case is basically empty and can be repeated in nanoseconds. As soon as the event does some actual work, many intermediary changes will be discarded and only the last one kept.

---

In this case, I'm just sending a message to an asynchronous driver and I'm still finding that I'm loading up the Queue with about 70-100 messages.  Normally not a problem except for this instrument doesn't like to be spoken to so frequently.  

[DailyDose]

---

@billko wrote:

I guess the problem is that this isn't the way a slider is supposed to work.  Think of a volume slider on an audio mixer panel.  It constantly adjusts the gain on that track as you move the slider; it doesn't wait until you let go.

Maybe the easiest solution is to make a button that "locks in" the value of the slider.  The slider has no events, but when the "lock" button is pressed, it reads whatever value the slider is set at.

---

Considering the instrument itself uses a slider on its display to adjust the attenuation, to me sounds like a very fitting reason to use a slider.  Feel like changing attenuation is very similar to adjusting audio on a mixer.  However, the instrument appears to use the "mouse up" methodology instead of immediate change.

[altenbach]

---

@DailyDose wrote:

---

@altenbach wrote:

---

@DailyDose wrote:
I was able to scroll from 0 to 70 in 2 seconds and triggered 150 events.  Includes time it took me to mouse from play and to click stop.

---

Yes, if the event case is basically empty and can be repeated in nanoseconds. As soon as the event does some actual work, many intermediary changes will be discarded and only the last one kept.

---

In this case, I'm just sending a message to an asynchronous driver and I'm still finding that I'm loading up the Queue with about 70-100 messages.  Normally not a problem except for this instrument doesn't like to be spoken to so frequently.  

---

Without additional information on your overall architecture, you could place a wrapper around the driver that manages sending the new values it receives and discards anything that's too fast. How exactly does the event communicate with the asynchronous driver?

[DailyDose]

I've decided the best way to address this is to use two controls.  The slider will be a "mouse up" event with an additional control that acts like the slider's Digital Display.  Then they just update each other whenever the other is triggered.  However, to properly act like the Digital Display, a third event is required that updates the Digital Display control in RT as the slider is adjusted.  Feel free to criticize this. 😅

Appreciate everyone's input!  Kudos all around!

[DailyDose]

---

@altenbach wrote:

---

@DailyDose wrote:

---

@altenbach wrote:

---

@DailyDose wrote:
I was able to scroll from 0 to 70 in 2 seconds and triggered 150 events.  Includes time it took me to mouse from play and to click stop.

---

Yes, if the event case is basically empty and can be repeated in nanoseconds. As soon as the event does some actual work, many intermediary changes will be discarded and only the last one kept.

---

In this case, I'm just sending a message to an asynchronous driver and I'm still finding that I'm loading up the Queue with about 70-100 messages.  Normally not a problem except for this instrument doesn't like to be spoken to so frequently.  

---

Without additional information on your overall architecture, you could place a wrapper around the driver that manages sending the new values it receives and discards anything that's too fast. How exactly does the event communicate with the asynchronous driver?

---

They talk via Queues, refs, and Data Value refs

[billko]

---

@DailyDose wrote:

---

@billko wrote:

I guess the problem is that this isn't the way a slider is supposed to work.  Think of a volume slider on an audio mixer panel.  It constantly adjusts the gain on that track as you move the slider; it doesn't wait until you let go.

Maybe the easiest solution is to make a button that "locks in" the value of the slider.  The slider has no events, but when the "lock" button is pressed, it reads whatever value the slider is set at.

---

Considering the instrument itself uses a slider on its display to adjust the attenuation, to me sounds like a very fitting reason to use a slider.  Feel like changing attenuation is very similar to adjusting audio on a mixer.  However, the instrument appears to use the "mouse up" methodology instead of immediate change.

---

I didn't know that - thanks for the explanation.  I now see that your task is to mimic the behavior of the physical front panel, which is difficult because the LabVIEW slider control was designed to mimic an analog slider and not a digital selector.

I know I'm not offering any help with this post, and I apologize for that.

[altenbach]

---

@DailyDose wrote:
They talk via Queues, refs, and Data Value refs

---

That's way too vague, but for a queue you could e.g. limit the queue size to 1 and use lossy enqueue. 

[Kevin_Price]

I don't really love this idea, but here goes anyway.

Make a separate "slider manager" loop.  It's going to be the go-between that waits for the flurry of event activity to cease, then send one message to the device with the most recent slider value.

The main event structure just enqueues values (or sends notifications).  The slider manager loop just dequeues (or waits on notification) and pushes data into a shift register (or feedback node).  When there's a timeout (meaning the flurry of activity has ceased), send the shift register value to the device.

   Thinking about it as I type, you probably need something like the Boolean Crossing function as well so you only send a message once when the timeout value *transitions* from False to True.

   You may also need to program up some kind of sentinel value (maybe NaN?) to end this loop.

Not loving it, but it seems like it oughta work.

-Kevin P

[WNM]

I'm coming to this discussion a bit late but the attached VI is how I handle this here.  It is used within a "Value Change" user event case that serves a slider (or knob) and connects to the event's left-side "Event Data Node" to get both the "CtlRef" and "OldVal"  values for the slider.  The event is configured to allow a max number of queued instances of "1" and no front-panel lock.  The subVI watches for the user to release the mouse button, which would signify the end of moving the slider, before returning control to the event case and the final value of the slider at the time of release is returned.  It works for me.