Start a new topic

Slider as virtual fader


I try to build a virtual mixing console with vertical Slider objects, that looks very good.

For a better emulation it would be cool, if you can activate a special Option, that the slider is only changing ist value when you touch the knob and moves it. Touches outside the area of the knob are ignored.

Best regards

Soeren Hellwig

Is this a feature request? or a question on How to Do it ?  (maybe placed in Free Chat?)

Up to now I found no way to realize this behaviour with user code in the event routines of the slider.

In the Touch Press Event the value has already been set to the new position. I can store the old position in a variable, but conditions after if did not allow complex operations like (va0.val-h0.val>10) so it is difficult to define the valid area. At last I found no command to cancel the touch event inside the Touch Press Event.

If you have an idea how to realize this Problem inside the actual Nextion Editor, I would be glad to hear about it.

Best regards,

Soeren Hellwig 

Hi Soeren,

Are those individual slider pics with one background? Can you share? I'm doing an engine sim and it would look great.


Hi Jim,

yes, the fader knob is a picture and the lines are in the background picture. The project is for the 7.0" Nextion touch Display. Attached you will find the project.

If you find a solution for the problem mentioned above, I would be glad to hear from you.



Um ... yeah, so like if the Nextion does not allow for such complex operations like (va0.val-h0.val>10), you will have to perhaps consider simple operations.  It is a pain, but you can have several Variable components in which to store and transfer values as and when needed and nest your operation







Now, even Windows sliders don't have a pre-touch press event.  So the resulting effect is that the slider will move to press location, evaluate, and jump back to original position because the user is being penalized for not pressing the knob and dragging it.  The illusion in windows is accomplished with a sprite where the object itself can be dragged to its new location checking x,y on the move and as long as x is half the distance from its rail center, adjust the knob to the new y location.  While the sprite could literally be moved anywhere, the illusion is accomplished with nanosecond calculation and recalculations and a powerhouse graphics card.

The illusion could also be created with 128 hotspots for each resolution point in the slider (your range was 0..127). These hotspots are in the foreground of the slider so they actually intercept the actual touch event and then they set the h0.val position of the slider, Might not be as smooth as the slider, but wouldn't move if touched outside of the current knob position.  Keep in mind all hotspots have to be created after the slider so on refresh they hold the foreground position so they can make the intercepts, and all hotspots have to be initialized to not move the slider if the knob isn't underneath of them.  Again this is probably more than the 3584 Bytes of RAM, so, probably not right?

What I would question in the design is the actual need for 128 position resolution in the slider, almost 3 px resolution per position.   In a system like 4D, their process takes a snapshot of what the dash board would look like at each position and then when that position is reached, swap the new image in.  But does the end user really actually distinguish between a 123 and a 125 or 121?  Creating the slider with a range of 0 to 63 (6 px per slider resolution) and calculating a new display value to give the illusion the slider is at 123 cuts the complexity of your program in 1/2 for that slider, x 6 sliders that is down to 1/64 or about 1.4%.  If you really could have had 0 to 31 (12 px per slider resolution) that is half again, x 6 sliders is 1/4096 the complexity or 0.0245%.

And just because computing is base 2, most users really aren't.

So, maybe I personally wouldn't penalize the user - they are trying to accomplish a task faster.

1 person likes this

Just as an after thought, your 7" display has an active area of ~86mm of which your slider occupies ~70mm vertically.  The knob covers 20 pixels on each end, so the slider is using 350. (for higher accuracy, the slider rail in the background picture should be 350 pixels in length so the knob is pressed against each end, only bringing that up as the calculations are already on my screen). The knob cover itself has 15 slider positions beneath it. 

The 128 slider positions at ~2.7344px vertically 0.49 mm or 1/200 inches per slider resolution.  

In keeping the slider the same size  but reducing the resolution range

- 64 slider positions at ~5.5px vertically ~1.0mm or 1/100 inches

- 32 slider positions at ~11px vertically ~2.2mm or 1/50 inches

Now, I don't have fat fingers, but I wonder if a user is looking to get 73 on all 6 sliders how many times they over shoot and under shoot before actually getting their desired value.  Also does this over and under shooting have a side effect you don't want - as in too much voltage/ blaring volumes etc.  But more so in my original point - do their senses actually distinguish the differences between a 24 and a 25.

Again, only mentioning it as per looking at reducing complexity to achieve your stated goal.

Still thinking,

It is a shame the background image needed for cropping, alone, chews up 3/4 MB of flash on the 7"

Hi Patrick,

thank you for your answers. The screen design is still in progress an I must adimit, that the number of faders has to be reduced to increase the size of the knob Image. Five faders will be enough (1x Mic, 2x Playlist, 2x Jingle).

The final background image will contain something like a scale for each fader, so its size is not the problem, because I use the Enhanced model with 32 MB Flash.

At the moment we are doing the mechanical part (designing the case and additional pcb), because every fader should have a Hardware button for the On/Off function.

When the prototype is finished I would ask radio DJs to test it. Maybe they like the possibility to move the fader fast to the desired end position.  

I am now reviewing all of the Feature Requests, this will take some time, patience please.

Although this wasn't a real feature request, it is now marked as reviewed.

Login or Signup to post a comment