v6 beta - Stage mode second screen blanking control

[iv-gha]

For v5 a Stage mode user also projecting can use the additional end section for note/next info as a means to end a song on a blank section. This gives the pedal user the ability to control a move to blank screen during performance - move to the end section using in-use pedal actions for section moves.

This 'feature' requires no song edit, no further allocation of a pedal action, no screen interaction, only use of an end notes/next section. It is intuitive and simple to use during performance.

v6 could consider support for this, ideally also with no device touching or complex pedal actions.

[thebigg73]

Next song info no longer drawn as a section, so not possible using this method.
A few reasons why I removed this:

• This caused issues when connected devices displayed note/next in different ways in v.5 (e.g. a pop up on one device and inline on another - caused crash). This was due to devices having different numbers of sections
• The inline next/note took up valuable song display space, so was switched to overlayed info bar which autohides.

We could look at a 'next/scroll down' action moving to a null section and therefore hiding the display by displaying an empty section? Not sure how this would play with the confirm before moving song option though.

[iv-gha]

Yes, that was fixed for receiving a bad section in v5 presentation (surprised this does not apply for Stage too) - it shows the first section. For other cases too - handling bad sections should be in all section based modes - I suggest v6 displays as an empty section.

[thebigg73]

I've gone for an alternative method. Still to test with image/pdf but working in stage mode with xml songs. Shouldn't send non existent section number to connected device either. This method only implements extra blank display when the user is connected to an external display.

[iv-gha]

A challenge for the v6 next / prev approach is that it covers the song bottom which cannot be scrolled up at the moment. Might need a similar approach to song menu using a pad to allow scroll above the buttons at the bottom.

[iv-gha]

The sender always sends valid sections for them, it is the receiver that handles a section change received which can be invalid for the local version of the song or that devices config choices. So a receiver needs to check. Is this in v6?

[thebigg73]

It doesn't scroll up (and shouldn't) as there is no section below the last one. It simply removes focus beyond the last position (and returns an empty view for the secondary display Pressing the up/previous scroll option returns the last selectable item back to the focus. Adding extra padding to the bottom of the scrollview would confuse the user that an extra section existed (which would be even worse if we actually put an extra section is) as it could make them think there was an issue with their song code and they would be trying to delete the extra space. I might put an option in for this 'show blank screen after last song section' for stage mode second screen as not everyone would want this. Yes, the receiving device should check for valid positions being received before selecting them with this code in the recyclerview adapters:

// Now update the newly selected position'
if (position >= 0 && position < sectionInfos.size()) {
         mainActivityInterface.getSong().setCurrentSection(position);
...

I tried my best to keep your changes from v5 into v6, but as you can see the logic is very different and sometimes v5 code was obsolete and implemented in a different way.

[iv-gha]

No problem. This is a useful v5 quirk.

The comment about next / prev in v6 is about usability. A section change to a bottom section triggers display of these buttons over the section, making it difficult to see (alpha of buttons would be high as they need to be read!). So this is a separate issue.

[thebigg73]

The bottom next/prev buttons can be set to autohide (default), or not be shown if the user chooses so. This is all about trying to maximise the song display size in the available screen height. I'm reluctant to add separate space/padding/empty sections to the bottom of the songs and this will destroy the autoscroll features and calculations and cause user uncertainty about why. Perhaps, we could remove autoscroll functionality from stage mode and add this padding if you feel strongly about it?

[iv-gha]

I understand your point.

To be clear this is usability in stage mode, where section changes are frequent, where the display moves a lot So (at the moment) auto hide features cause display on each section change, where a move to an end section will be overlaid with buttons. This overlay is most severe when using text prev/next - for readability of prev/next button the alpha will need to be high and so will certainly obscure the section. It is difficult to agree that not seeing the section you are playing is good - even knowing auto hide will reveal it in a while. This is a UI conflict for visibility of elements, song and buttons.

In terms of touch, for stage mode, there is UI touch conflict between bottom buttons and click of last sections of a song.

Stage has a distinct user experience... users expect section/song move and, I assert, will understand if the song is padded to support all sections moving up the screen. In stage mode (one man band with projection) a view that includes the current, -1 and +1 section is the best for usability. You can be playing -1 and projecting current, you can be playing/project current and need to understand +1. So obscuring the last section obscures it as +1 and then current.

Please consider.

[thebigg73]

v5 didn't have a -1 and +1 section did it? I can't remember seeing blank sections before and afterwards

On Thu, 18 May 2023 at 19:01, iv-gha @.***> wrote:

I understand your point.

To be clear this usability in stage mode, where section changes are frequent, where the display moves a lot So (at the moment) auto hide features cause display on each section change, where a move to an end section will be overlaid with buttons. This overlay is most severe when using text prev/next - for readability of prev/next button the alpha will need to be high and so will certainly obscure the section. It is difficult to say that nit seeing the section you are playing is good. Albeit auto hide will reveal it in a while.

Stage is different... users know sections/songs move and, I assert, will understand if the song is padded to support all sections moving up the screen. In stage mode (one man band with projection) a view that includes the current, -1 and +1 section is the best usability.

Please consider.

— Reply to this email directly, view it on GitHub https://github.com/thebigg73/OpenSongTablet/issues/234#issuecomment-1553422485, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3X52SAVB4OSCU6NKVBAYDXGZPXVANCNFSM6AAAAAAYCFKVQM . You are receiving this because you commented.Message ID: @.***>

[iv-gha]

By -1 and +1, I mean the section before and after.

It maybe stage mode can simply not use the bottom for song display - a shorter song area? This would give no clashes with bottom buttons - ever!

[iv-gha]

I have remembered that v5 currently overrides notes and prev/next section at top to force it only at the bottom - specifically so it can be used as a host. Display code was adjusted to show the first section for an invalid section. I think this addressed for v5 the crash issues you mentioned related to mis-match of host and client song sections.

So with absolutely no impact to performance mode...

For stage mode we can add prev/next/notes as an end section (only). Stage is, after all, a separate mode and can do things differently (presentation is radically different!).

Should be quite simple. Shall I look at this?

[thebigg73]

Since you know what you're after, it makes sense for you to have a look at the implementation. As long as it doesn't impact performance mode, I'm happy. I worry that putting the prev/next buttons as a separate layout would defeat/stop the overlay ability of performance mode where screen real estate is the big push and responsible for a lot of the changes in v6 along with the updated UI. If you feel the buttons are an issue, it might be sensible then to have a hidden layout at the bottom (GONE for Performance mode and VISIBLE for the Stage mode that overrides the buttons. You could tap into the logic for the DisplayPrevNext.java class and just change when the output goes (ExtendedFABs for Performance Mode or Bottom FrameLayout children for Stage mode?