With version 3.7.0, I added a slider that you can drag to change the position of the half page turns. The slider whites out the background a small amount above and below it to make it clear where one page ends and another begins. I have received feedback, and a user has suggested that I still leave the white space above the line, but don't have white space below the line, as the bottom half is the section that still needs to be played, and this makes it easier to position the slider. Does anyone else have any thoughts on this? It would help to hear some opinions on this.
I really like the implementation of the half page slider
It is intuitively usable and works very smooth.
I also like the white space and I think to have it above and below makes the cut more clear.
02-25-2023, 06:15 PM (This post was last modified: 02-25-2023, 06:16 PM by daniel.)
I am really happy to have this feature now. It is very helpful!
As for your question: In my opinion the white space is not necessary. If I drag the line somewhere in between two staves it does not make a difference and sometimes it even looks odd, because I am not able to position the line without "erasing" some small space above and below the line.
If you keep it as it is, I would recommend not using white as color, but the chosen paper color.
Another idea: If the split should be clearer indicated, maybe a custom color or line thickness would a option?
I am updating the code to take into account the page color tone setting, as I did not handle that properly, but trying to use the "paper color" is a little trickier. That would require scanning the page to see what pixel color is used the most and I'm not sure if that's worth the amount of processing that would be required (and it would certainly complicate the code).
In my testing, not having any divider created a lot of situations where I couldn't tell where one half ended and the other began. Yes the slider is clearly telling you that, but it still was unpleasant to see the two halves bleed into each other. You are not always going to have a situation where each half is between two staves. If the majority of people still prefer having no white space above and below the line, it's an easy change to make.
02-25-2023, 06:31 PM (This post was last modified: 02-25-2023, 06:36 PM by daniel.)
(02-25-2023, 06:21 PM)Zubersoft Wrote: I am updating the code to take into account the page color tone setting, as I did not handle that properly, but trying to use the "paper color" is a little trickier.
This is what I meant with "paper color". It was not my intention to use the "real" color of the scanned document. Maybe this is another point for not using some sort of whitespace above and below the line ;-) It would be much easier and more consistent.
Quote:In my testing, not having any divider created a lot of situations where I couldn't tell where one half ended and the other began. Yes the slider is clearly telling you that, but it still was unpleasant to see the two halves bleed into each other. You are not always going to have a situation where each half is between two staves.
I will have to test this with my scores. Until now I had (on my Max Lumi) a thick black line which was clearly visible. The new divider is much lighter, but I think I will get used to it. The fact that is movable is a big plus.
During my tests I found a minor bug: the white space behind the half-page-turn-ruler is misplaced (see attached image). The misplacement only occurs in the "song overlay" mode. If viewed in normal "song display" everything is ok.
I found this in my Android version on my Max Lumi and on my Windows version.
Daniel - I can look at making the line darker (or maybe even just black) in the e-ink version to make it stand out more. I'll look at the logic with the overlay up as well.
Geoff - I'm not sure what you mean by an XOR'd line. With bit arithmatic, an XOR is obviously 1 only when the two bits are different. I'm not sure how that applies to drawing a line. Are you just saying make the line transparent? If so, I played around with that early on and similar to what I said earlier, it made it really hard to visually see where one half ended and another half began. So I don't want to go down that path.
To XOR, you need to know the original colour for each pixel on the line..
Assuming 8 bit (unsigned), for a colour value x, the replacement colour for each pixel is 255-x (this toggles each "bit")
You might have to have a line 3 or 4 pixels wide to make it obvious
For the white background, I'm just drawing a rectangle over the width of the page. Having to process each pixel individually seems like far more trouble than it is worth and would be much worse in terms of performance (although it probably would be insignificant).
Stick your code in a routine (rather than embedding it); this will allow you to easily experiment with different solutions.
I forgot to say that, when moving a visible XOred line, you just XOR it again to restore the original line. Then perform an XOR at the new position.
This means there is no need to "remember what is under the line"
Putting it in a routine means that your code is still simple to read as it will just be one call.
The overhead should be minimal as you are probably only going to be accessing about 1000 pixels per pixel row (2 accesses per pixel - one read, one write)
On windows there are techniques for accessing pixels on a raster basis (this is faster) but as you need a generic mechanism for different platforms, I suggest you access the pixels individually
This is only a possible suggestion - you know your code and any limitations due to the different drawing mechanisms.
Great idea, making the line movable. I didn't expect it, but it will be much appreciated.
However, with its colour (blue-ish), sometimes I miss it, I'd rather it were black, or thicker or, even better if it's not a lot of trouble, configurable.
(02-26-2023, 04:27 AM)Zubersoft Wrote: Daniel - I can look at making the line darker (or maybe even just black) in the e-ink version to make it stand out more.
This is done in 3.7.2. It is much better now. Thank you for your work!
