I don't know about anyone else, but I have the blue model and when I am driving at night the display is distractingly bright.

Would there be any chance of the next rev. of the firmware having a menu option to drop the display to dim mode for night time driving?

I think this is something of a safety concern, as with the unit mounted in the centre console on a Landrover Discovery the display is very visible to the driver.

If I understand the display correctly I understand that each pixel has four brightness options: off, dim, normal, and bright. I'd like to add a toggle that prevents the normal and bright values from being set. I understand that I'd loose contrasting shades but the dim alone (without the others) might be perfect option for driving at night without the display turned off.

Cheers,

=-C

_______________________________
List 351, empeg 00045, 10gb, Amber

Wouldn't it be a better (techie) solution to map the pixel brightness values one down the scale in dimmed mode, ie. Bright->Normal, Normal->Dim? This means you'd not loose too much contrast, only low illumination definition on the pixels illuminated as Dim.

This (I would have thought) could be done reasonably easily in the s/w.

To be honest, at night I want the driver behind to see the graphics properly...

{8^)

I'd like a dimmer for night driving and a brightener for day driving in the convertible with the top down. As it is,
I'm selecting playlists randomly because I can't see anything on the screen.

In that vein I'd like to be able to select next playlist with a single click on the remote.

yours, Dean

Hmm... I'm not really familiar with the empeg's menu yet (reg# ~3100), but it would make sense to make an option called 'Display Brightness', with the values 'Normal', 'Dim', 'Dimmer', and 'Off'. The 'Off' mode would (amazingly) turn off the display, and it would light up only when you push a button (on whatever brightness ('Normal', 'Dim', 'Dimmer') you had it before), then off again after a few secs of not presing the buttons. The delay should of course be individually changeable. Just my 0.25 DKR (~0.02£)

Greetings

Yonzie

-> agreeing 100 % and laughing his ass off due to the 0,25 DKR :)

Nils, Flensborg :)

Or, I suppose a low-tech solution involving colored cellophane and a bit of tape might suffice.... ;-)

tanstaafl.

"There Ain't No Such Thing As A Free Lunch"

You said....
> In that vein I'd like to be able to select next playlist with a
> single click on the remote.

This is what I've been calling "skip to next inner playlist", and I think is already on the todo list. It would be nice to be able to do it without the remote too.

Every time I mention it though Hugo nearly hits me and tells me that the Empeg isn't just a large CD player. :)

Cheers,

Mark.

>Every time I mention it though Hugo nearly hits me and tells me that the Empeg isn't just a large CD player.

This is a problem I've noticed with the development team - they're idea of what the empeg is, is slightly out of step with what the consumers expect the unit to be.

As a consumer, this is *exactly* what I expect the empeg to be - a large CD player. The whole point is to avoid a changer and the associated CDs, but have it *act* like a changer and treat playlist like CDs. If it isn't a big CD player, then what the hell is it?

They might think it's cool to listen to music by year, but I don't, and I think most others don't care either. Just another example of out-of-step thinking.

This is what the market wants. Hugo et al would be well advised to keep that thinking in mind during the development process.

If you want it to act like a large CD autochanger then you clearly haven't tried to locate tracks on a 50 disc changer :-)

Rob

I don't try to locate tracks on my CD changers. 99% of the time I just let them play through each track of each CD, looping around the set of 12 CDs for weeks on end until my wife suggests that maybe it's time to change the CDs. Every now and then I might skip over a track or album that I'm not in the mood for, or less often over an album that my wife doesn't like if she's in the car with me. I don't particularly care about being able to choose which track to listen to next as I only uploaded the stuff that I like to listen to in the car. As an example (and as I mentioned in another thread) we just got back from a 1300ish mile week long driving holiday and were both very impressed with the Empeg as it gave us high quality non repeating non intervention music all week. Well almost non intervention, we did skip over one album as it was a bit too loud for the beautiful scenery we were driving through at the time, and that one album skip which would have taken one button press on even a very basic CD changer took about a dozen presses on the Empeg with a pause between each one to see whether we'd moved onto the next album yet.

I don't have any problem with the extra bells and whistles as I think the product will do very well if it can do things that CD changers can't. However, I think that most consumers (rather than gadget lovers) will treat the Empeg as a large CD changer. It would be nice to have the basics, as I see CD changer like functions, higher up the priority list than what I consider to be frills. Having said that, I appreciate that the software is still very young and as long as the "basic" features are there before you call it version 1 then I'll be happy.

Cheers,

Mark.

Personally, I think it's a bit harsh to accuse us of having out-of-step thinking: skipping a playlist in one has been thought of and is in the to-do list - but implementation order (especially as we're in beta) is up to us. The UI for things like this is hard - particularly seeing as we're limited with the remote (like some buttons don't autorepeat which means we can't tell when we get a push & hold).

The reason play-by-year is in there and skip playlist isn't is that play-by-year was easy to implement, and I love it - and I know a lot of others who do too. It does depend on how wide ranging your music collection is, and how well ID3 tagged your files are :)

Everyone who has bought an empeg has been advised that the software isn't finished yet. Banging on the table and screaming about new features doesn't help us get them done quicker - our priorities are primarily stability and robustness, with features being added when the proper infrastructure is there to support them. Yes, we could add them quicker with a hack here and a hack there, but that isn't the way to give you stability or maintainable code.

You're right that we don't see the empeg as a large CD player. There are lots of things which consumers expect CD players to do which aren't out of their choice (if they actually sat down and thought about it) but are just because that's what they're used to (and what the hardware is capable of), and a comfortable paradigm for them to understand. We're pushing the envelope of music organisation and we intend to offer both visions - the old and the new: but until the software is released, please don't judge the feature set.

Hugo

> our priorities are primarily stability and robustness, with features being
> added when the proper infrastructure is there to support them.

I can't help feeling that the sooner you make either an API to the player
or source code available, the sooner the features could be added...

Have you considered embedding tcl into the player? Tcl is ideal for this
type of project, though it may not be to your taste. Then you could put
a default tcl script to control the player as it is now, and people could
add extra C libraries or just manipulate the existing script. i.e.

#!/usr/bin/tclsh
load player.so
load visuals.so
load dsp.so
...
create menus...
bind front panel butttons to procedures...
bind remote control buttons...
bind serial port inputs...
load playlists...
while {1} {
...get next track info
play($track,$length,$visual,$eqsettings...)
}

or python, or whatever...

Paul

We have had python running the show in the past in the player: however, it has problems with being used in a multithreaded app - ie, it's really not thread-safe. After untold hassles, we backed out of python until there's a thread-safe variant (allegedly 2.0 will be thread safe).

Originally we looked at TCL and Python, but came down on the side of Python as it fitted better with our OO design methods.

We've not gone back and looked at TCL again, but unless it's thread-safe (we use multithreading a *lot* to make everything work smoothly) it's a non-starter. Obviously, when a thread-safe python appears we'll compile in the python interpreter again and see what happens :)

Hugo

> We've not gone back and looked at TCL again, but unless it's thread-safe
> (we use multithreading a *lot* to make everything work smoothly) it's a
> non-starter.

Well, maybe it's time to take another look...

http://www.scriptics.com/products/tcltk/whatsnew.tml#thread

:-)

Paul

This is no different to Python - in python you can have multiple threads. The problems ocurred with interactions between C threads and the interpreter (ISTR). Being totally honest, I don't think we'll have time to get either an interpreter in there or document the APIs to a linkable player library until after the first release. It is on the wishlist, though, so that people could replace the UI but still keep our underlying handling of audio data.

Hugo