This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9208 - Recording screen converted to viewports
Attached to Project:
Rockbox
Opened by Peter D'Hoye (petur) - Monday, 21 July 2008, 15:33 GMT+2
Last edited by Peter D'Hoye (petur) - Wednesday, 06 August 2008, 22:26 GMT+2
Opened by Peter D'Hoye (petur) - Monday, 21 July 2008, 15:33 GMT+2
Last edited by Peter D'Hoye (petur) - Wednesday, 06 August 2008, 22:26 GMT+2
|
DetailsRecording screen converted to viewports, no longer using sysfonts
To do - clean up the code (not committable yet) - convert LANG strings from SYSFONT to normal - make the peakmeters nicer now that they can become big - test on more targets feedback welcome ;-) example screenshot: http://users.telenet.be/petur/recscreen.png |
This task blocks these from closing
FS#5675 - Recording screen can't be localized with character not present i
TO DO:
- nicer peakmeters (if large)
- change SYSFONT lang-strings into proper strings
- test on several targets
- clip counter increments don't show up
- USB plug symbol incomplete except for the first 2 (?!) pixel lines
NOTE: CLIP counter does work here, make sure it really clips (ie clip bar at the end of the peakmeter is drawn)
NOTE2: filename is shown and updated correctly (when starting new recording)
TO DO:
- USB symbol not drawn
- filename not shown on some targets (instead, it shows volume again)
- peakmeter fancyness
- LANG changes
- filename not shown on some targets
- USB logo not shown
USB logo working now
clip counter:
1.) even with a lot of clip bars at the peakmeter's end the counter seems to be updated only randomly. actually, the corresponding file viewed in a wave editor shows up a lot more clipping points than the counter. all in all I think, there's a problem with computing the "sensitivity" of the clip counter in general, since I got the same results without this patch applied. But perhaps here's a good chance to fix it. Like
2.) clip counter start: To me, it makes sense if the clip counter starts in pre-recording mode already, because that's the time when I want the gain to be adjusted correctly. Currently the counter seems to count only while recording?!?
3.) clip counter reset: Any change to the gain should reset the counter to zero. Especially in pre-recording mode this would easily help me find the right gain where no more new clipping events occur.
However: the clipcounter is supposed to only count +1 when the clip bars become visible, any clipping happening while they are visible is not counted.
The other things you mention are nice to know but do not belong here... forum feature request maybe?
Commit candidate :) - needs more testing on targets
Looks great! Glad to finally be able to read the font. The only thing I noticed is that I have the status bar turned off so when in the recording screen I have no feedback about the recording state (rec/pause) or filetype, as that info currently resides in the bar. Perhaps it should be switched on automatically on entry to the screen and turned off on exit like the FM Radio, at least for now.
1) The displayed filesize is way way off (starting with some 1xx MB and increases, sometimes jumps back down a bit) and I also get a "disk is full" message on the first line of the screen which is probably related.
2) Returning from the recording menu to the recording screen will freeze my Ondio with a blank screen and needs a hard reset. Recording still seems to be enabled as I can hear it in my headphones. This always happens, no matter what I did in the menu even when just entering from the recording screen and leaving again. I didn't find any problems in using that menu (well a button action problem in the trigger screen but this is present in SVN too).
3) When triggered recording is enabled, the trigger bar is not displayed in the recording screen though the peak meter is smaller then and makes room for it.
Not a problem but I really think that a one line peak meter is enough on the 64 pixel high screens (two lines are already ok on the 80 pixels high c200 screen to me). With the nedore-9 font I use there is only room for two lines of the other information in the list some of which is important too in my opinion. But I'm not a taper and hopefully someone with an Iriver remote could comment on that too... (maybe I'm a bit biased because it has always been that way - and on the Archos screens it really looks weird. These LCDs have rectangular pixels with the width only being 80% of the pixels height, making the two lines look even taller).
Last but not least, a small problem which could probably be fixed later: the selected item in the list does not scroll and so I can't read the filename completely.
(1) I expect this to be fixed.
(2) Still have to check on coming out of the menu, so that will probably still be broken.
(3) I looked at the trigger bar drawing and can't figure out why it is invisible. It is probably not handling viewports correctly and thus shown 8 pixels higher, under the peakmeters... to be investigated.
And yes, I also wonder why selected list items do not scroll. Probably a property of the list at creation. To be checked.
Hmm... I now stopped a recording at displayed "114 GB" and properties told me that the file is actually 1183 kB... During the recording I could see right before the displayed filesize switched to "GB", that it showed four digits shortly ("1000" -> "1023", I think).
The other things also didn't change, as you expected. I'll also take the chance to point at MarcGuay's reply before mine in case that short one got lost... ;)
I also saw that on my Ondio with the v13 patch.
- have another go at the archos issues
- trigger bar should now be visible
- forced statusbar on
for the archos issue, I now tried to make the whole init sequence be as close to the original source as possible, I hope this helps. If not, I'll need to scratch my head a bit longer ;)
fixes/changes
- selected list entry scrolls
- filename is shown completely (scrolls if selected)
I'm still not a fan of the filename being in the list part and imo it should only be there if there is <3 lines available for the list...
anyway, code comments (repeating the ones i mentioned in irc )
- the viewports can probably be local vars instead of globals.
- there is a few lines of // commented out code
- line 1620 of recording.c you have a clear_viewport() but doesn't look like the viewport is set before hand?... hmm... nope, its set at line 1242, fine but either add a comment somewhere or move this down to where the drawing actually happens.. also it looks like the lcd on code wont actually work correctly (line 1398, also.. what the heck is that block for anyway?)
other than that.. looks good
one issue nobody noticed remains: when recording stops, filename stays displayed. To be fixed...
will commit in a few hours unless remarks come