While Recording Screen - User Interface Discussion - including remotes

[Mmmm]

Update to this shunned patch:

Due to the new encoder options
Now the filetype and bitrate are displayed in place of the Volume icon which was pointless anyway.
Patch on the tracker and included in the REP.

[Davide-NYC]

OK, here is my latest idea and I think this one will even pass muster with the devs.  

Since scrolling is with us on the iRiver remotes no matter what I suggest we simply implement a scrollbar at the bottom part of the left hand side of the screen. This is 'generalizable' to all targets and all remotes.

I've included the scrollbar in instances where it wouldn't be needed (not enough items in the list to fill the main screen) for illustration purposes only. The scrollbar should appear and dissappear as necessary.

I also suggest that we 'right justify' the values and leave the labels left justified (as they are now)
If the labels are too long in certain languages they should be hidden behind the values. Ugly, but rare.

I also think that the status and scrollbars should turn on/off in the WRS as they do in the File Browser and Menu. Others may disagree.  

Check out the bitmaps:

[attachment deleted by admin, too old]

[Davide-NYC]

Another idea:   If the encoding type/quality cannot be changed *while recording* then I think it should be displayed above the peakmeter with the other stuff that cannot be adjusted "on-the-fly".

Keeping the design consistent:   Interactive stuff (while recording) goes below the Peakmeters, passive information above.

And yet another idea: This idea is to alleviate the 'crowded remote' problem that started this thread in the first place.
    Is it possible to have a momentary "joystick up" button press on the remote show this information by overwriting the peakmeters, and once the button is released the peakmeters return? That would rule!!!

[Mmmm]

Another idea:   If the encoding type/quality cannot be changed *while recording* then I think it should be displayed above the peakmeter with the other stuff that cannot be adjusted "on-the-fly".

Keeping the design consistent:   Interactive stuff (while recording) goes below the Peakmeters, passive information above.

The problem with this is anything moved from the bottom to the top pushes all the other info down and so we end up with a bigger problem than we started with!

And yet another idea: This idea is to alleviate the 'crowded remote' problem that started this thread in the first place.
 Â   Is it possible to have a momentary "joystick up" button press on the remote show this information by overwriting the peakmeters, and once the button is released the peakmeters return? That would rule!!!

Hmmm that's not a bad idea you know...but maybe it'd be better if it overwote the top two lines instead of the peakmeter, You wouldn't want to miss that clip while you were looking at your samplerate now would you?

Oh, and looking at your screenshots above, I noticed a bug for the AGC players where samplerate was getting overwritten with filetype... Should be fixed now though.
The scrolling you suggest is a given...I think that is definitely on the cards already.

[Davide-NYC]

The problem with this is anything moved from the bottom to the top pushes all the other info down and so we end up with a bigger problem than we started with!

 

Not if you combine this design paradigm:

Interactive stuff (while recording) goes below the Peakmeters, passive information above.

with this:

have a momentary "joystick up" button press on the remote show this information by overwriting the peakmeters

 and this:

it'd be better if it overwote the top two lines instead of the peakmeter,

You end up with something useable and cool!

Here is the current refinement:

On the main unit display everything gets pushed down a line because of the encoding line being moved above the peakmeters.

But on the remote you only show the Time and Size lines above the PMs unless a 'joystick up' is pressed (while at the Volume line) and then they get replaced by filename and encoding lines.

The main unit screen is static (or consistent) and the remote unit does the display switching only because it's necessitated by RLCD size limitation.

Wadayatink? Discuss...

Hey Mmmm: What above the 'Right Justified Values' idea? Can this be done? It would clean up the look a bit, the lines wouldn't 'jump around' and (I assume) it should be be easy to implement.

[Davide-NYC]

Mmmm, if you give me exact sizes for everything I will generate icon code for you with nice readable icons even on teeny targets like the Recorder.

I know that the statusbar is 8 pixels high, with the bottom pixel being generally blank. (The "Q" being an exception, poking down to the eigth pixel.) Just tell me how wide everything should be on the Recorder screen.

• Battery
• Volume (Now Ecoding Type and Bitrate)
• Stop/Play/Pause/Rec/FM
• Repeat (Now Samplerate)
• ? (Now Stereo/Mono icon with room to spare?)
• RTC

Questions:

What is displayed between the stereo/mono icon and the RTC in the statusbar?
If nothing then we can afford slightly better stereo/mono icons and maybe a tiny bit of breathing room.

I'm hoping with a tiny bit of refinement we can get the RSB (recording status bar) looking really slick. See gifs below:



[attachment deleted by admin, too old]

[Mmmm]

What is displayed between the stereo/mono icon and the RTC in the statusbar?
If nothing then we can afford slightly better stereo/mono icons and maybe a tiny bit of breathing room.

I'm afraid that all the space is used up, the bit of space you refer to is used for the hold icons, and the space after the battery icon is used for the charging icon...I was initially excited about these too, but they are used!

If you look in statusbar.c you can see all the sizes near the top in the #define lines.

What do you feel is unclear at the moment? I thought MQ3 might look better as Mq3 instead... I have actually used the system font for the sample rate and Q value. We're only using icons now for bitrate on SWcodec targets, as the font wouldn't fit and channels.

[Davide-NYC]

I think that bitmaps in the statusbar are the way to go from an esthetic perspective.
They give a nicer more even look and tell the user that they are not modifyable while recording.

Harder to read true, so maybe a bit less functional, but less 'crowded' looking. I would use them for the HWCODEC targets too, since they have the teeny screen.

My 2 cents. As usualy I come bearing gifs -->

[attachment deleted by admin, too old]

[Davide-NYC]

After playing around in some image editing software I have changed my mind about the Archos targets.: The system font works better.  

I guess it's the non-symmetry on either side of the play/pause/stop/rec/fm icon that bothers me... so I still think that the samplerates on the SWCODEC platforms should be displayed with a bitmap of the same height.

Any body else agree? Am I nit-picking?

Mmmm, I made a couple of changes to your patch...
Huge thanks and respect to the devs in IRC.

PATCH -->>  Check it out.

I used a blocky font becuse at that tiny size it's easier to read.

[attachment deleted by admin, too old]

[Mmmm]

Ok...brace yourself..here goes....

Why have you changed main.c?
I'm confused as you seem to have added a setting to settings.c which should already be there... I'm surprised it compiles.
in statusbar.c you seem to have re-enabled the volume display for non swcodec targets.

It appears that you have merged one of my old patches with your changes...is that right?
all you should need to change are statusbar.c for the display of bitmaps for swcodec tasrgets (the stuff near the bottom) and icons.[c,h] for the new icons.

Well done on making your first patch though... maybe I'll commit it if you get it fixed up...

[Davide-NYC]

Thanks!

This (crap) hack job of a patch took a dolt (me) four hours to get functioning without error.

I have very little understanding of the logic. I'm going to pick up a C book and try to read some over the weekend (if I find time). Only by the extreme helpfulness of the devs in IRC was I able to get this done.  I actually understand next to nothing of what's going on.

It works in the SIM for FMRec, H120 and H320. (that's what I tested) and on an actual H120 target (what I have).

Anyways, jdGordon says that all the recording statusbar stuff might break when he commits the new recording menu stuff. At that point, if you feel the need to fix the RSB-encoder/bitrate/samplerate display maybe you could just 'roll-in' the 'SWCODEC gets icons', 'HWCODEC gets sysfont' feature. I plead!  

[Davide-NYC]

OK, I think I fixed it.  

PATCH --> See Here.

Please scrutinize carefully and let me know what you think. If it passes muster please commit it.

If I made any whitespace error please let me know.

[Mmmm]

Ahh...much better than before...

I'm just going to point out what each "hunk" of your patch does just so you can tell me if it was intentional or not
statusbar.c:
Hunk#1: adds an extra pixel gap between play state and sample rate
Hunk#2: enables the volume display in non swcodec players
Hunk#3: char buffer[4] should be indented 4 spaces,
Hunk#4: quite a few blank lines deleted and re-added
Hunk#5: get width & height indentation right
Hunk#6: display->setfont(FONT_UI) indentation needs fixing

Icons.[c/h]
Looking good!

Some tiny things
look in the patch at lines like this
-    }
+   }
and think to yourself why is it replacing this line with itself? Is this necessary, can I stop that?

Mostly just presentation now...good work...

Do you want to make one more tidyup before I actually test it and maybe commit?

[Mmmm]

Also, have you tested this on an actual build (ie not the simulator)?

 I didn't think so...It won't compile for SPDIF targets AKA H1xx!!  

You are using an array that you #ifdef'd out. Also you have an unused char which is a waste of memory, "buffer" isn't used in swcodec targets any more!

and you change the font to sysfont but don't change it back to uifont... not disastrous, but sloppy! You don't need to change to sysfont at all for swcodec targets anymore as you aren't printing any characters.

But these are all tiny things (apart from it not compiling )... Nice fonts by the way!

[Davide-NYC]

Clearly I am getting ahead of myself.  I have purchased a book but have read nothing yet (no time)

Please do me the honors of dismantling this disaster and re-implementing this thing in a way that makes some kind of sense.  All this is supposed to do is use the bitmaps I specified and implement the following conditional switch:

IF target=HWCODEC use sysfont to display encoder/bitrate and samplerate in the Recording Statusbar
ELSEIF target=SWCODEC use bitmaps to display encoder/bitrate and samplerate in the Recording Statusbar.

That's it. Please, and thank you.


Before you commit could you post a stand-alone patch so that I may peruse it and maybe learn something from it. Thanks.