Even better: I'll take both times (last keypress, last screenchange) into account in the next version.

I'm not sure you understood what I was saying (unless 39 doesn't yet implement it).

What I meant was:

- The screen-scrape method is useless to me as the unit will never ever blank. There is always something on the screen that moves. Even if I put up a plain INFO:TRACK screen, the track timer changes the screen.

- What would be more useful is if it ignored the screen changes and instead paid attention to key presses. That way I could leave it on Now and Next or Info:Track and it would blank after a certain time between input actions from me. If I wanted to look at the screen I could twist the knob or press a volume button on the remote.

The screen-scrape method is useless to me as the unit will never ever blank. There is always something on the screen that moves.

isn't that the point? to prevent burn in? If something's moving it should stay on....

What would be more useful is if it ignored the screen changes and instead paid attention to key presses. That way I could leave it on Now and Next or Info:Track and it would blank after a certain time between input actions from me. If I wanted to look at the screen I could twist the knob or press a volume button on the remote.

That would change the way it works completely. Here's how i see it, and everyone correct me if i'm wrong on this... But it's exactly like a screen saver on a PC, it only kicks in after a certain amount of time if there's no activity on the screen to prevent screen burn in. If you don't want anything on the screen just switch to the blank visual and hold down the visual toggle to see the info you want. I for one like it the way it is... it seems like you're asking for a seperate function all together... so it would have "screen saver" and "screen blanker", the former shutting off the screen after periods of inactivity on the screen, and the latter doing so after periods of inactiviy on the buttons.

Mmmm I dunno what screen saver you use, but mine react to periods of input inactivity, not display inactivity. If the latter were the case, a blinking cursor would be enough to keep the screen saver from kicking in...

I'm with tfabris on the no input = screen blank idea.

Doh, you're definitely correct on that one. I put that very poorly. Hrm... Okay... am i correct in that the blanking function is meant to be a screen saver in the truest sense? If so... then if there are visuals on the screen moving about, or something scrolling, then there is no reason to blank the screen to prevent burn in. If however there is a static image on screen, then there is a need to blank the screen.

I use the current blanking setup and would like it to stay the way it is...

If i put on a playlist and am sitting at my machine, then i want the screen on flashing and scrolling about. . . but if I jump up to go review an animation or something and leave my desk without turning the empeg off and the playlist ends and i don't return for another hour or so, i don't want it sitting there with a static screen. That just makes sense to me. I don't see what the point of the other way is... if you don't want the screen on then set the visual to off.

Am i alone in seeing it that way?

Am i alone in seeing it that way?

No, but you're missing my point...

INFO:TRACK and INFO:NOW AND NEXT are static displays that will burn the screen. But the screen blanker will never blank them becaue the clock timer portion of the screen changes every second.

>But the screen blanker will never blank them becaue the clock timer portion
>of the screen changes every second.

Funny thing is, I originally implemented it to handle such things, basing the blanking decision on a percentage of screen that remained static..

But I figured folks would complain about premature empblankulation if I left it that way, so I changed it. I suppose now I'll have to add an option to make it work either way..

>Funny thing is, I originally implemented it to handle such things, basing the blanking decision on a percentage of screen that
>remained static..

Could you please change the percentage to be less strict? When listening to radio, if the signal strength changes even for a moment it will unblank the screen. not great if you're driving around and the signal is prone to change.

very clever way of implementing it.

rub

>When listening to radio, if the signal strength changes even for a moment it will unblank the screen

Send me your radio module and I'll fix it.

Why not do something really wacky like only blanking parts of the screen that have been inactive for a certain amount of time. With 4096 pixels you can afford to do this down to the individual pixel.

You could even drop the brightness of a pixel based on how long it has remained the same until it just disappears.

Toby.

But couldn't that mean that parts of text/numbers will disappear or darken within the letter or number itself? For example, looking at the elapsed/remaining numbers, the top pixel, one-right from center, is lit for every number that is showed. Using your idea as I see it, that pixel would blank out before those around it.
I totally agree that this logic would be good for the line in info:track, and the various slashes and colons on the different displays, but it would just make the non-moving portions of the text look "wacky".

Yes, but the idea is to blank pixels which remain lit in order to prevent burn in.

The way around this would be to blank (or progressively fade) individual pixels which have remained unchanged for a certain amount of time, and reset their counters when a neighbouring pixel's colour changes.

This way static portions of the screen would be blanked, but pixels which wouldn't necessarily change state when they should would still get re-drawn when a neighbour changes state.

It's a pity the grey-scale isn't evenly spaced (and I do understand the reasons why). If it were, it would be easy to periodically invert the display (every 6 hours, or something). It might work anyway.

Do you actually want a tuner, if so I'm sure it could be arranged...

Yup. That would do it nicely.

Yes, but the idea is to blank pixels which remain lit in order to prevent burn in.

I see what you're saying, Toby, but this would result in worse burn-in in my case.

See, the problem I have isn't the main part of the display with the track names. That changes completely every five minutes and doesn't burn.

The problem is the time-counter section of the screen. This changes constantly, so it would never blank, but it keeps cycling through the same ten digits which stay in the same area of the screen constantly.

My Mark1 has a little (faintly) burned rectangle in that area of the screen from leaving Now and Next up on the screen for a few weeks. This is the very area of the screen that wouldn't blank under your proposed scheme.

I like what he's just done with it. Although I'd like to see available numbers lower than 85% because sometimes it un-blanks when the clock goes from 0:59 to 1:00 in Now and Next mode depending on the track length.

My Mark1 has a little (faintly) burned rectangle in that area of the screen from leaving Now and Next up on the screen for a few weeks. This is the very area of the screen that wouldn't blank under your proposed scheme.

I also have this problem, and I didn't leave now and next up for weeks...

>I'd like to see available numbers lower than 85%

Okay, I'll spend another bit on it, doubling the range available.

>Do you actually want a tuner, if so I'm sure it could be arranged...

If I had one here, I would undoubtedly incorporate some tuner-specifics into my enhancements package. So, yes! Whatcha got in mind?

I thought perhaps I might buy you one to thank you for all your hard work, just wondering what the easiest way to achieve it would be.

I would undoubtedly incorporate some tuner-specifics into my enhancements package.

The only thing I'd like to see is some sort of easier way to switch to the tuner without using the remote. As it stands right now you have to dig into the menu. Perhaps having that be one of the "press" options for the knob... Argh, but I don't want to give up the Info switch... Hmmm.... What to do...

I know, I know...

A new feature that lets you spell out in morse code the feature you want, by repeatedly pressing the knob.

Problem solved !

You think that's funny. But I've actually been thinking of ways to access more features from the front panel and I had a couple of ideas...

1) Double-clicks. Can this be detected from the kernel? Can anyone think of a way this could be implemented gracefully?

2) Chords. Can the front panel's button grid be read from the kernel in such a way that combinations of simultaneous presses can be detected?

Examples of chords:
Hold down knob while turning=jog/shuttle mode or rotary radio tuning.
Press bottom and top button at the same time: Switch source.
Hold bottom button then press FF/REW: next/previous playlist

That sort of thing...

Sounds good to me. I think at the very least "push and twist" on the knob should be used for something useful.

My original (v1) version of the voladj on/off used button chords, so, yes, they're possible.

Double-clicks have also been on my mind, but they don't work well on the knob (too easy to spin it while pressing, and things WILL get confused). But they work just fine on the other four buttons (and those are available on mk1 as well).

But maybe simplier would be to redefine the press'n'hold FF/REW functions (front panel), since they are rarely used in the car (and if needed, the menu is there to reenable them..).

>I'd like to see is some sort of easier way to switch to the tuner without using the remote

How about "press and hold knob" until it switches (beyond the menu..)?

I think I can add that, although it won't be able to "know" whether or not the tuner is active, so it may require a couple of such long presses to get the tuner (I'll have it toggle between tuner and player on alternate presses).

??

How about "press and hold knob" until it switches (beyond the menu..)?

I would like that very much.

It's possible that this might be what they decide to implement for the final 2.0 release anyway, so you could eventually just hijack the long press, then send a long press underneath your menu, and that would solve your mode-detection problem.

I wonder, though, if there isn't a way to detect whether tuner/aux is active from within the kernel. Perhaps by reading from the DSP?

>I wonder, though, if there isn't a way to detect whether tuner/aux is active .. ?

Probably from looking at the hardware regs.

But we don't need it after all here; I'll have have the extra long press emulate the "SOURCE" button from the Rio remote, which automatically cycles among input sources.

Ah, of course. Cool.

No, wait. That won't work. I think source is simply empeg/aux, doesn't go to tuner. You have to press tuner to go to tuner.

I think.

Not sure, I'm at my desk right now.

No, wait. That won't work. I think source is simply empeg/aux, doesn't go to tuner. You have to press tuner to go to tuner.

I think.


That's currently true.

However, there WAS (in 1.03) a SRC button for some of the kenwood remotes that just ran through the choices. It doesn't work in 2.03B, but it WAS there....