Well I see a ton of links for Alpha 3 version 3 and version 5 so how long till version 3 beta or a version 3 full release.

The usual answer to questions like this is: "when it's finished".

chop chop then

chop chop then

Nothing to do with me, Guv.

Ah yes, good point.

Sorry - forgot about that.

Days, weeks, months, years, decades, centuries?

Still asking the wrong person, guv...

I'd guess months, but as I say, you're asking the wrong person, guv.

Note: this is not directed at you personally, so don't take offence.

See, it's like this: The empeg and Rio Car are discontinued. The End of Life announcement was in September 2001. Official customer support ended in May 2003.

v2.00-final was the last official release for the car player.

Anything we're given from this point is just gravy.

The car player doesn't generate any revenue for Rio, so there's no reason whatsoever to expect another software release. The guys in Cambridge are doing this for two reasons:

1) Out of the goodness of their hearts.
2) Because it's useful testing for the code that's gone into the Karma.

However, the Karma code is all but finished. Further testing on the empeg wouldn't be useful.

So, we're left with one motivation: because they want to.

I happen to know that Rio are very good at keeping the guys busy -- I'm not sure what they're working on at the moment, but the last time I went up to Cambridge (a couple of weeks ago), everybody was working their socks off. On something that generates revenue.

So, my advice: stop asking. I can't speak for the guys still in Cambridge, but I used to find it irritating -- I wanted to get another v3.0 out, but there was nothing I could do about it. There's nothing that they can do about it (even Rob's hands are tied by schedules).

You'll get the next version of v3.0 just as quickly: when it's ready.

However, the Karma code is all but finished. Further testing on the empeg wouldn't be useful.

Hmm, this makes me curious... Now that the Karma code has evolved so much, about how similar would you say the empeg player code and the Karma code is? If the main code trunk continues to advance without back-ports to the empeg, doesn't opening up at least portions of the player source code to hungry empeg developers become a legitimate topic?

Maybe my reasoning is a little convoluted, but it seems to me that the less the empeg platform resembles current products, the more it takes on an "abandonware" status that DNNA suits could feel comfortable about releasing portions of (with no warranties expressed or implied, of course.) One of the major reasons (as I understood it) behind keeping the player source closed is to protect trade secrets and intellectual property inside the code. Well, at some point, doesn't a lot of that stuff get rewritten to take advantage of the new platforms, or to add in newer functionality?

The way I see it, the Cambridge folks have always bent over backwards to address this community's concerns and wishes, and the community has done a lot in terms of providing feedback, alpha/beta testing, and unofficial support for Rio-branded products. It's been a good symbiotic relationship, and it'd be nice if that could eventually lead to an arrangement where the community could take some part in the development process of a fully functional empeg player app, even if some of the guts (visuals, WMA engine, anything that's licensed and/or contractually protected) are distributed as binary-only. I'm not saying your former employer owes us anything, but if there's any way it could be done, I think it could potentially benefit both parties. We could be free to make improvements to the player app, and DNNA would be free (with the right licensing in place) to use our improvements in future products.

This sort of thing has been talked about a lot in the past, and the response was always that the empeg too closely resembled current products for it to be feasible. Do you think this is this still the case?

I know you don't speak for empeg, DNNA, or anyone else now, so this question is also open to Rob, Peter, and anyone else who cares to comment...

how similar would you say the empeg player code and the Karma code is?

I thought you were going one way and you went the other, so I'll add the alternate course.

If the empeg is used as a proving ground for Karma features, wouldn't it be positive for DNNA to keep the empeg up with the latest builds so that it can continue to be used that way?

If the empeg is used as a proving ground for Karma features

Well, the line I quoted from Roger's post specifically states (the way I'm interpeting it, at least) that the "proving ground" thing doesn't have much traction anymore because Karma development is "all but finished." Right?

Yeah, but you then go on to say

the less the empeg platform resembles current products, the more it takes on an "abandonware" status

from which I inferred further development. And surely they will continue the development of other devices, if not improving the Karma software itself. If not, DNNA has little reason to continue their employment at all. And I feel that they won't all-of-a-sudden have them developing tax-preparation software.

because Karma development is "all but finished."

What I mean is this:

Karma is released. Arguably, it's finished (bar bug fixes etc.). There's no point in having the empeg users as guinea pigs for it. There will be no new features added to Karma until Karma 2 (assuming that there will be one). Therefore, no need for empeg owners to test them -- Karma owners can.

This does not mean that the code base has been abandoned. Far from it.

Think of it like this (I'm not saying that this is what happened; it's just a thought experiment):

1) Rob wants to continue development on the car player, because he loves us so much.
2) He knows that he'll never get permission to do this.
3) He tells the powers-that-be that, since there's no Karma hardware available for beta testing yet, that he can get the code tested by releasing it to the empeg community -- where he knows that there's a ready pool of smart people who write good bug reports -- as an alpha release.
4) The v3.0-alpha3 comes out.
5) It gets hammered on.
6) Karma hardware becomes available.
7) Rob rewards the empeg community for testing -alpha3 by releasing -alpha5 when the team get a breather between Karma bugfixes.

Now the Karma hardware is available, persuading the powers-that-be to allow another empeg release out the door is much much harder.

It's not that the code is stale -- it's that fixing the code up to work on the car player is a day or two of work, plus a couple of evenings of bug fixing, plus an afternoon cooking the release.

All of this is hard to justify when the car player no longer generates tangible revenue.

Arguably, it's finished (bar bug fixes etc.). There's no point in having the empeg users as guinea pigs for it. There will be no new features added to Karma...

Heh, we're talking about the Cambridge gang here. You really think they'll just stop adding features?

Case in point: Toby already talked about ReplayGain over on Riovolution...

And one the team pointed that there was still a bunch of functionality there waiting for some UI to access it (presumably hierachical playlists and the like).

It's been a good symbiotic relationship, and it'd be nice if that could eventually lead to an arrangement where the community could take some part in the development process of a fully functional empeg player app...

Is there anything (other than some sort of motivation) keeping this from happening without any of DNNA's source?

I myself am probably not representative of the majority of empeg owners;

- I don't need GPS functionality.
- I can't take advantage of a lyrics-viewer (because I'm not retagging >170GB of music)
- I don't need complicated button re-maps, etc.
- etc.

What I need is a deck that holds as much of my music collection as possible, plays the music, and allows me to organize it as I like. And that's what I have in the empeg.

What would I add/change?

- Add (at least limited) Japanese tag support, which would save me retagging about 1/3 of my collection.
- Make it simple to add custom INFO modes. XML simple. As in "/drive0/var/infomodes/my_mode_1.xml"
- Add in color support. So if someone ever managed to hack on a new screen.... <drool>
- Etc.

I suppose not having visuals could be a problem for some, but for me, not so important.

I by NO MEANS have the programming skills to tackle something like this, but it's always seemed like plenty of the people on this board do. Hell, I'll offer up as much of my own time as possible to do anything to help (ie. learn more programming, etc., order pizza) if people were interested in really starting something on this.

Lest I be misunderstood; I love the empeg. Other than seeing mojibake when I play 1/3 of my MP3s it's perfect. And there are no words to express how much I appreciate the work (and time and blood and sweat and X-Mas eves) Hugo and Rob and everyone have put into it. It's an amazing product. But sadly, it's also a product they don't have full control of. Not to mention it sounds like they have their hands full at their regular jobs.

I hope this doesn't offend anyone, and that it's taken in the spirit that it's intended.

Well, first off, there *is* at least one alternative player for the empeg that's shown some promise. It's called Squash, and it's pretty darn good for what's basically one guy's hobby. Do a BBS search for some info. It's still got some UI work to go, and the overall design is definitely a departure from what the empeg has (it's more geared towards intelligent shuffle playback than any kind of ability to select specific songs, though the author's told me he plans on adding that in the future.) Installing squash is definitely not for the faint of heart, be warned.

However, the reason many people (including myself) lust after the empeg player app's source is that, for many of us, it's *almost* perfect, but we'd like to add stuff. If we start from scratch, or even just string together a bunch of 3rd party libraries and a cheesy UI, we've got a long way to before we get to something as rock-solid and featured as the empeg player app.

So what would we do with it? Well, that's hard to say, but there's a pile of often-requested features over in the Wish List forum that, more than likely, won't ever get a chance to see the light of day. The guys at Cambridge are too busy, you know, providing for themselves and their families. They like the empeg community, but it's not hard to understand why they want to work on things that keep themselves employed.

But if we had the ability to code in our own extensions, plugins, etc. into the player app, I think it'd open up a whole new world. As evidenced by the Hijack kernel, along with a few of the apps people have written, it's possible to add neat functionality to the empeg without having the player source code available. But there are a lot of things that we just can't get at.

As for the XML-based custom info modes, my thinking behind using config.ini was that it's already available, and easily edited from emplode. I'm not totally ruling out XML for a future release (as long as I can find a lean, efficient, and free XML parser written in C) but for the next release (hopefully in a week or two) it'll still be a matter of adding lines to config.ini. But I'll add XML support to my wish list.

You really think they'll just stop adding features?

Not at all. But one of the points I'm trying to make is that releasing a car player with those features is harder to justify when there's usable Karma hardware.

I guess the Empeg community just needs to step up to the plate and begin their IV drip of Thai food and beer until our demands are met

Well said!

I've read a bit, as it's posted, about squash; I just don't want to start messing until he's released what he considers to be "V1". I'm not too faint of heart, but not quite ready for that.

I completely agree with you; the player app is *almost* perfect. As I said, if you add japanese tag display, it would be perfect (for me).

I hope I wasn't misunderstood. I tried to make clear that I know that the most important thing here is that Rob and Co. put food on the table, not crossfading on the empeg. As much as I like it, it's not worth having it at the expense of someone else's security/stability.

You put very clearly what I tried to get at: It's the ability to code extensions, plugins, etc. THAT is what we need. Imagine: I could learn more coding, and make a plugin to display JIS tags, saving me having to whine about it here and there . Someone else does a plugin for a new visualization. And so on.... Problem could be solved by allowing "hooks" (?) directly into the player app.

<shrug>

Either way. I'm thrilled just to have my empeg. Anything else is just wasabi.

Problem could be solved by allowing "hooks" (?) directly into the player app.

You underestimate just how hard this actually is. Trust me. Sure, it's not insurmountably hard, but it's work that there's not time for -- unless it can be justified for another project.

You underestimate just how hard this actually is.

Not to come off as snide, but I'm unable to find anywhere I implied it was an easy task. Granted, I may have not specifically stated "Although a Sysiphian task, it would solve the problem." If anything I said was interpreted as me hinting that it was easy, then people read me totally wrong. I have no idea how hard it would be. It simply seems to me that the "problem could be solved by allowing 'hooks' (?) directly into the player app." I didn't intend to imply anything beyond that.

I didn't intend to imply anything beyond that.

Fair enough. On re-reading your post, this is obvious.

One reason that I may have seemed short is this: people often say things like: "Oh, just add some hooks", "Oh, just make it multithreaded", "Oh, just do X", without any clear understanding of just how much work that entails.

I'm sure we've all worked for a PHB that's said this at one point or another.

Now, I don't mean to imply that you meant it in this vein, but I just wanted to point out (to other people) that it ain't that easy.

Hmm, this makes me curious... Now that the Karma code has evolved so much, about how similar would you say the empeg player code and the Karma code is? If the main code trunk continues to advance without back-ports to the empeg, doesn't opening up at least portions of the player source code to hungry empeg developers become a legitimate topic?

The v3 alphas are released from the main trunk -- that's why they're so wonky in places! I'd guess they share more than 90% of the code with Karma. And probably 70-80% with v2 final still.

Peter

I'm sure we've all worked for a PHB that's said this at one point or another.

More than I would care to say. Management says "It's just a database and a website....tomorrow sound good?"

No harm done Roger.

Dave, I'm kinda like you, with the exception of the built-in web server, I use my empeg mainly for music. And now that crossfading has been added, a release that would allow database rebuilds would probably meet all my wishes.

Other "audio" wishes would be to have the left/right time alignment, VolAdjust and Bass/Treble functions in HiJack moved to the player. Unless using a car-kit, I don't see left/right adjustment being of much use on a Karma, but the others would probably be handly.

Cambridge, you guys have really put together a great peice of gear here! No significant hardware changes in years and this thing is still the king of in-car mp3 players and is only an NTSC/PAL output away from ruling the home players! If only that MiniDisk player I bought was as useful...

Hey, just incase you missed this little gem that Rob tossed our way, check out this thread here. No promises, but it looks like they are working on a beta.