A while back there was discussion about a "grass roots" development project to write player software from scratch. Many people including myself thought the idea was crazy because we had such a close connection (via this BBS) to the developers that it was relatively easy to get new features included

Well, with the Empeg reaching EOL status, I would submit to the Empeg community that it's time for us to seriously consider the possibility of developing player software in an open-source arena. It's likely 2.0 and future point releases will address some of our immediate needs, but as has been stated in the other threads, there will be an as yet undetermined future date at which the player software will be "feature frozen" and unsupported.

The Wish List forum has hundreds of feature suggestions of varying degrees of usefulness, feasability, and broad user appeal. Many of them won't get implemented by EOL. I suspect Ogg Vorbis support won't make it in, for instance, and you can never have enough new visualizations. :)

An open source player project would certainly be ambitious, but we are geeks, aren't we? Empeg is the perfect geek platform, and when the player software freezes, I know there will be features that geeks want in there. Since the "real" player software isn't going to become open-sourced, a start from scratch may be a good idea.

So what does everyone think? I'm a decent Unix/C programmer and would definitely offer my skills to such an adventure if there were others on board, it would obviously have to be a team effort. Right now I'd just like to open the discussion of such a project, and see what people think.

-Tony
MkII #554

I like the idea, I only wish my development skills were good enough to help out more than doing basic testing, and stuff.

key things to get a project going:

development environment:
a simple, easy to download linux build environment, with a simple set of scripts to allow compiles and such.

Modularity:
making the code base not one big project, but a group of smaller projects will allways help get other people involved.

the bigest difficulty is coming up with a good structure for the whole system.. but then again, this is all stuff that the empeg guys have allready done :)



12gig red mk2 -- 080000125

In reply to:

---

but then again, this is all stuff that the empeg guys have allready done :)

---

Yeah, I'm sure if this were to get going we'd all realize that we are re-inventing the wheel. But the flip side of that is that we'd have a perfect model to immitate... And immitation is the sincerest form of flattery.

It's extremely ambitious and we'd have to have the right mix of skills to make it work.

-Tony
MkII #554

I guess I'll learn with along with the rest of ya ... count me in.

I am a programmer with decent C/Unix skills. Count me in too.

~Yogi.

I think there may be a sourceforge site up for this purpose.

Sean

I think a major problem for developing add on apps is, that
there is no API for basic display/graphic functions etc.
I think if we start developing such a library, the development
of other application will be much faster!

just a thought....

bobo

Well, with the Empeg reaching EOL status, I would submit to the Empeg community that it's time for us to seriously consider the possibility of developing player software in an open-source arena.

Far be it from me to get between a geek and his cross-compiler, but I don't think that that time will really come until support and development of car-player software from Sonic Blue has come to an end: that has certainly not happened yet, and I hope just as much as any customer does that it won't happen soon.

Peter

What, you've bought a carplayer peter? ;)

...and I thought you just put your head over my cube wall every time you ran out of diskspace for your huge (and very good) music collection...

Hugo

What, you've bought a carplayer peter? ;)

No, or I would have said "any other customer" ;)

Peter

[re: Terminator]
There is a sourceforge project set up called "all things empeg" but this hypothetical effort would be more player-specific.

[re: bobo]
I agree that a low-level API set is the first step towards such a goal. I know such API's for VFD graphics, sound, etc. have been discussed but until now there's been no real reason to attack the problem.

[re: peter]
True, Sonic Blue has not ended support, and it seems logical that they won't do so until a year from when the last player is sold due to warranty concerns. But once that day comes, there will be no way to get new features implemented. Whether it's a new audio format, a new serial I/O interface, or just some frivolous new visualizations. I guess I just see the few thousand Empegs in the world surviving for a lot longer than Sonic Blue's official support. WIth that in mind, I was thinking of how there are people writing software for other "powerful, yet commercially unsuccessful" platforms such as the Amiga (okay I'm sure there are better examples.)

I myself am not 100% sure if this is a worthwhile cause, I was just throwing it out here to see if we can anticipate a need for our own player software that can replace the Empeg player after it's features are forever frozen in time. Getting started on it now would increase the chances that there is a worthwhile result when the player software goes "final." If we're all happy with the 2.xx releases and can't see any reason we'd ever need another audio player on our Empeg, then maybe our development energies would be better focused elsewhere (like, for instance, the GPS projects that have been kicked around.

-Tony
MkII #554

Count me in... I haven't done low level C since my device drivers class in college, but I've been itching to get back into it.

-Jeremy

Mk2/40GB/Blue

Speaking of frivolous visualizations. What becomes of the planned plug in architecture with the EOL?

Calvin

Yeah, that just became #1 on my wishlist. If the empeg crew can manage to sneak in any sort of plugin interface before the software is EOL'd it would give us a much better chance of updating the empeg to meet our needs after software development ends.

-Mike

If you need some assistance, you can count on me also...
I already did some experiments with writing my own player app. I you download the perl archive from my site, there is a player.pl script which act as an interface to the xaudio command-line player. It uses the empeg's font, so it looks a little like the original software. There isn't a real database in there, at this moment I just scan all FID-files. I think I have found a way to read the database from the empeg itself though.


Frank van Gestel

Frank, you are a mad man. =]


|| loren.cox ||

That's the kind of thing I'd like to see too. The guys@empeg have already done so much hard work that it would be nice to be able to hang onto it and concentrate on improvements, new visuals, new decoders/music formats, a top notch file transfer/backup program, and the one I'd really like to see - a Nav system.

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 26GB blue)

As we've noted before, the player software isn't going EOL; we have *one* source base for all products (car1, car2, rio receiver, plus secret projects...) which means that adding support to one project for a feature tends to add it as a side effect to other projects.

We hope to be able to use this to keep our personal carplayers up to date... and release new software to customers when we can.

Hugo

A year or so ago I was messing around with developing a player program. For the GUI, I made a output target for the GD library to write to the empeg memory mapped display buffer. It works pretty well, and has all of the basic (shapes, text, fonts, etc) features one might want for writing to a 128x32 display.

I can dig up the source file and diffs against GD in a couple of days if anyone is interested.

Ultimately I wanted to make a window server, then all my apps (player, CPU meter, stock ticker, whatever) would build their window images and send them to the server which would composite them as appropriate. I never actually got that far though ;)

Sorry, should not have said EOL. My point was that we can't count on there being any software releases after 2.0. SonicBlue may decide it is not worth it to support us, or the code may change to the point that it does not work on the empegs anymore. Worst case scenario SB may decide to get out of linux based mp3 players entirely. If any of that happens it would be great to be able to extend the existing software rather than try to start from scratch.

-Mike

SB may decide it's not worth it to support us, but we also have to remember that the guys at empeg still use this as THEIR car player as well. I think they will be adding features for quite a while, even if it's "on their own time."

Just my $0.02...

-Trevor

-----
Mk 2, Green 12GB, Tuner 080000349

In reply to:

---

I think they will be adding features for quite a while, even if it's "on their own time."

---

But will SB allow them to release the software to the rest of us?

Geoff
---- -------
Got one of the first Mark 2 empegs...

Both the CEO and CTO use this product, and I believe there are a whole bunch of other VP's and managers who also do so. Just thought I'd mention it.

Rob

All of this "count me in" stuff is well and good, but where would we start?

I mean, back in the days of Lambda-Moo, I passed the "I can program myself out of a paper bag" test, and went on to fail out of school because of it, but where does this lead us?

I've always been the type of programmer who takes something that's broken or incomplete and fixes it, but starting something from scratch has never been my strong point.

Also, I believe the UK guys that they'll continue to support us because it's in their own best interest to do that, but I also think that if we have an Open Source project, everyone will benefit (UK guys included). Not to say there would be competition, but they would be "different but similar".

Sometimes the answer to getting what you want is doing it yourself. I like the sound of opensource-empeg-kernel on sourceforge.net ...

I bet if there's enough interest, and a ring-leader who can get us started, that we'll all have fun and get something out of it.

g

--
Rio Car (40Gig) Blue/Red/Green/Amber Face (Looking for 2.0!)
'01 Audi A4 2.8 Quattro

Here are my thoughts and plans concerning software I am aiming to develop on my empeg... Feel free to comment as you see fit... and I will also note that how far I get with all this is a completely different matter (*grin*)

I have been waiting for my tuner module to arrive before I installed the empeg in the car as I have only one DIN slot... but I have had it for a while and have been pondering how I would like to use it/what else it needs...

I would like a Nav system in it... my thoughts on how to develop it go as follows. I have aquired a gpsTripmate from delorme for US$50 which plugs into a serial port and has NMEA ascii output. I have got it working with gpsd on a laptop and am planning to try and build gpsd for the empeg.

The idea would be to take Kit's overlay hack and generalise it to allow overlays of data coming in via an entry in /dev... first step

Step 2 get gpsd working on the empeg and outputting to the overlay simple lat/lon (/speed?)

Step 3 - allow for a simple database of waypoints to be uploaded to the empeg that would be matched against current position and a label added to the overlay when the current position "matches"

Step 4 - provide a simple directional arrow graphic via the overlay pointing to the next waypoint

Step 5 - work out how to mix audio to allow audio instructions on reaching waypoints

Step 6 - work out how to intercept IR signals and try and grab one for switching to and from nav mode (ie turning the overlay on and off)

Step 7 - try and do this with other stuff... eg: voice recorder for taking notes... simple web/wap access...?

The idea (if you can see through my rambling) is that I want to keep the current software intact... by using the overlay technique with the ability to overlay the entire display software modules can be developed in parallel with the current player... eventually if you wanted to rewrite the player itself it just becomes another thing that uses the overlay or is overlaid...

Anyway, let me know what you think... for my own purposes I have tried to make sure the steps are each small achievable steps that let me move further each time... adding functionality each time and thereby hopefully keeping a good chance I won't become disillusioned (sp?) with the whole thing...

Cheers

Kim

Hmmm I like this idea even more than the open-sourced player because it adds functionality that we've all been talking about (GPS) and that the player obviously doesn't give us.

I'm not familiar with the TripMate unit but I did a search for GPSD and found the software, downloaded it, and compiled it in maybe five minutes.

I'll have to do some reading about this thing and maybe scratch my programming itch with some of the ideas you mentioned... The DeLorme site is terribly slow right now though.

empeg:/tmp# ./gpsd -h

usage:  gpsd [options] 

  options include: 

  -D integer   [ set debug level ] 

  -L longitude [ set longitude ] 

  -S integer   [ set port for daemon ] 

  -T e         [ earthmate flag ] 

  -h           [ help message ] 

  -l latitude  [ set latitude ] 

  -p string    [ set gps device name ] 

  -s baud_rate [ set baud rate on gps device ] 

  -c           [ use dgps service for corrections ] 

  -d host      [ set dgps server ] 

  -r port      [ set dgps rtcm-sc104 port ] 

empeg:/tmp#

-Tony
MkII #554

The TripMate is a very old unit that DeLorme produced... predecessor to the EarthMate... the TripMate is a little more open with its output as far as I can tell and was cheaper to buy... DeLorme are selling "refurbished" units of the TripMate and EarthMate via the web for US$50 and US$89.95 (as far as I remember)

I can't say that the TripMate is likely to be an especially accurate GPS but it was a nice cheap entry level item that had everything I needed... if I get it working and want something better it shouldn't be too hard to replace it at a later date with a better quality GPS...

Refurbished Tripmate
Refurbished EarthMate

and a link for a hack for the tripmate:
http://wes.johnston.net/aprs/tripmate.htm

Though I am not intending to use the self start hack as I can get around the 'ASTRAL' keyword problem via the gpsd software itself... But have built myself the power adaptor and aim to wire that into the empeg so the unit will get powered when the empeg turns on...

Cheers

Kim

some of my other thoughts with gpsd that I have mentioned in another thread are the possibility of extracting DGPS info from the RDS data stream and trying to pump it into gpsd... but that is for much later... and I have doubts the TripMate itself can be used with the dgps feature of gpsd...

Further to my original Step by Step plans are adding the functionality of being able to "mark" a waypoint via the empeg itself while in "nav mode" so that you can mark out a trip once while travelling it and then use it later... add to this the functionality of recording the audio instructions at the same time and you end up with the ability to record directions for a trip in the car while travelling it for later reuse... then you take that and build some software for use at home to do the same thing when planning a trip ahead of time with a geo-referenced map... ie click on a point to get the lat-lon and record an instruction... These instruction sets could be uploaded as units to the empeg and made selectable by a menu (the bitmenu (?) Frank has) and even exchanged with other empeg users...

More sophisticated waypoint matching would also match the direction you are heading...

Then you can add things like the flagging of speed traps... locations of Fast food joints... cheap fuel locations...

Cheers

Kim

As for a GPS in car navigation, I'd get one that is very precise and does good motion calculations as otherwise you will probably not be able to test the system trying to do street based routing / navigation.

I do see the monetary point though. :)

However, I assume that at the moment the GPS system is not precise enough anyway - the US military will most likely have turned on the artificial inaccuracy at the moment.

Till

Hmmm. I agree with tigloo that a more accurate GPS would be ideal. In my brief web search last night I l found both a hardware and software method to translate the output of an Earthmate to the NMEA "language." I don't know enough about GPS to understand if this translation is complete, or if there are things missing from it...

software translator
hardware translator

It's my understanding that the Earthmate is more accurate... Does anyone know how much more accurate it is? Are there any better more precise units in the ~$100 price range that we could think about using?

-Tony
MkII #554

*nod*

My view with buying the tripmate was it was a cheap entry level product that had the features I required to "get going". I can't see it being so inaccurate as to be unusable, especially considering the approach I am intending on taking... Sure once the system is running and I can see myself with more than a few waypoints, or wanting to do more interesting things requiring more accurate location data, that will be the time for me to get a better GPS...

If you are looking to buy a GPS now and are looking for something more accurate, it would be an interesting exercise to see how whatever system gets built handles the different qualities of data..

As for conversion of GPS data for the Earthmate...gpsd can talk to the unit so I don't see the binary format as being a problem... at least from the point of view of getting basic date, lat, lon and speed info out of it... But maybe you can think of more information we might want access to... I am new to GPS's myself... :)

Cheers

Kim

As my dad is a passionate sailor, he has a few GPS units that I will most likely be able to borrow.

I'll probably be able to get my hands on his Garmin GPS-12, already a dated unit but it is able to output NMEA.

If somebody wants me to test an interface or develop an interface for it (software-wise), I'd be willing to help.

Unfortunately I do not have any experience with map-based routing, however.

Till

Well the date/lat/long stuff would seem to be the easy part. Any sort of routing would open up an entire new can of worms as the other navigation/GPS threads in the Projects board have suggested. There are all sorts of different map formats, and doing routing based on this data doesn't seem to be an easy programming task.. I doubt any of us have expertise in this, and I don't know of any freely available software for parsing out these vector formats for routing purposes, but then again I haven't looked very closely yet.

But the journey of a thousand miles begins with a single step, so lat/long would be a nice first goal.

-Tony
MkII #554

This is my thought exactly...

I have some experience with GIS... and could probably write some code to do routing, given the information was in a format I could deal with... but from my point of view that is much further down the track... I suppose that also comes from the fact that out here in Perth routing is less of a problem... The city itself is pretty easy to get around... and when you get out of the city... well there aren't exactly many options to get you lost... *grin*

I suppose for the moment my interest in Nav is more from an informational point of view... I want the empeg to be able to tell me when I am near to cheap petrol... or how far I have travelled this trip... or maybe allow me to profile a couple of different routes to and from work to compare them...

Cheers

Kim

Almost all in-car nav systems supplement the GPS data with gyros and speed sensors. That said, I used to use a Garmin GPS12 with a laptop and it was pretty good (but you had to read the map yourself, it didn't do automatic recalculation of routes).

Rob