Support and General Use > Recording

Recording Screen conversion to ViewPorts

(1/4) > >>

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... :D

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:

--- Quote from: JdGordon on July 24, 2008, 08:26:42 PM ---1) arnt you one of those purists... :D

--- End quote ---
Which is why I wrote that :P


--- Quote from: JdGordon on July 24, 2008, 08:26:42 PM ---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...?

--- End quote ---
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...

Navigation

[0] Message Index

[#] Next page