Recording Screen conversion to ViewPorts

[petur]

There is a fully functional converted recscreen in the tracker here (FS #9208), and I wouldn't mind if it would get some testing on various targets before it goes in.

Also let me know what you think of it. At this moment it will revert to sysfont if the whole screen doesn fit anymore, but this could be done incrementally (ie first change the list to sysfont)

The purists will be happy to hear this patch shaves 1760 bytes off the binary for h300

[JdGordon]

1) arnt you one of those purists...

2) (i havnt looked at the patch yet..) bassically the whole point of viewports was in the hope that screens wouldnt need to revert to the sysfont (which also causes the problem where LANG_SYSFONT_* is still needed).

OK, I've just had a quick look at the code and I have some suggestions.
The peakmeter should go in a seperate viewport and use the whole thing so its the easiest thing to resize.
The list needs a minimum of one line so the whole screen then needs min 5 (3+1+1). and if that still is too many, have some fun with the top 3 lines... only show one line, but alternate the text every HZ/2 or something...?

[petur]

1) arnt you one of those purists...

Which is why I wrote that

2) (i havnt looked at the patch yet..) bassically the whole point of viewports was in the hope that screens wouldnt need to revert to the sysfont (which also causes the problem where LANG_SYSFONT_* is still needed).

OK, I've just had a quick look at the code and I have some suggestions.
The peakmeter should go in a seperate viewport and use the whole thing so its the easiest thing to resize.
The list needs a minimum of one line so the whole screen then needs min 5 (3+1+1). and if that still is too many, have some fun with the top 3 lines... only show one line, but alternate the text every HZ/2 or something...?

The problem is, the user is able to pick a font that hardly fits two lines on the display. What then?
I agree that things can be tweaked a bit more, but fallback to sysfont seemed like a nice 'emergency' remedy.
I hate cludges like alternating text. The changing behavior is hard to explain ('my display suddenly looks different') and document because it depends on the font size.

Anyways, I first want to commit this as it stands now, and then start tweaking how the top part is drawn. Too much change in one go is dangerous. And it almost looks the same now as it was before.

[z-man]

The idea of having kind of a "master" gain is an improvement. But I have my concerns about the usability of the current implementation. Let's say, I'm doing a live recording, but for some reason there's a need to have more gain on the LEFT channel. No problem to get it done with the left/right faders. Okay. What will happen next: The band becomes louder than expected. That is: with both channels still unbalanced, I have to fade down the master gain. And currently, there's a good chance to change the left/right balance and fade the LEFT channel by mistake when the RIGHT channel is already at 0.
So, with 3 gains I would prefer to have a master gain, that has no impact on the left/right balance. Or even more straightforeward: Just one master gain, and kind of a "recording balance" slider with  0 dB (=balanced) in the middle.

[petur]

z-man: regarding your findings:
- the X5 compile error is fixed in my latest patch
-  CLIP counter does work

there seems to be something odd with changing gain though, investigating that...

[petur]

New patch is up, all known issues fixed. Left to do are LANG conversio and maybe fancy peakmeters

[LurkAzusa]

Thank you, Petur.  It is very readable on the H120 and H340.  It's great to have the ability to choose a very large font and still scroll to the information.  Appears to work well. 
Will the screen design be the same as wps or will there be a specific wpr function?

[JdGordon]

Will the screen design be the same as wps or will there be a specific wpr function?

the screen is hardcoded, at least for the time being there isnt going to be any wps-like ability for the rec screen

[LurkAzusa]

Will there be the ability to add a large icon representing the current status of recording, pause, stopped?

Or changing the field identifier to a shorter abbreviation, such as file, instead of filename or PR or PreRec instead of Pre-Recording?  This would allow larger fonts without cutting off information.

[Llorean]

Changing text should be as simple as editing your language file.

[petur]

The plan is to first get this change in, and then we can start tweaking it and in the future even have an WRS gui system.

Things I'd like to tweak:
- get the listbox to scroll the selected line, to show more of the filename
- fancy peakmeters (now that the have become that big)
- clear recording state indication, maybe software drawn and thus scaleable.

[LurkAzusa]

I've tried it on the Ipod 4G Greyscale and Ipod 5G 60. 
Seems to be good.

 The volume and gain settings go negative with a right press, which seems counter intuitive, but that is also in the original.

[petur]

The peakmeter should go in a seperate viewport and use the whole thing so its the easiest thing to resize.

I have given this some thought...

Are suggesting this in the light of a future WRS implementation? If not, I do not see any advantage in giving it a separate VP.

For the moment, keeping it like I have gives the possibility to add some stuff to left and right of the peakmeter. I would also like to implement a vertical PM so it can be put on the right of the screen and give us another extra line. But in its own VP? Nah...

[JdGordon]

well, if its in its own vp the drawing funciotn for it is dead simple, (x,y,width,height) is just (0,0,vp->width, vp->height)
I have no other reason for that thoguh

[petur]

well, if its in its own vp the drawing funciotn for it is dead simple, (x,y,width,height) is just (0,0,vp->width, vp->height)
I have no other reason for that thoguh

I'd rather have code that can position the PM anywhere I like... the PM still needs to get x and y because it is also used elsewhere.