Sorry Jon, I meant to type UI, not GUI. If you replicate the empeg UI on a display, it makes very much sense to me to make it touch. Of course, if you're not planning to include any GUI at all then I misunderstood your project in this regard.



Sorry, I did not mean anything bad. Linux on VM could be interesting as well. I, personally, use a lot of Windows machines for various reasons, and I'd love to use a tablet in car as a stereo controller, in the office docked as my main PC, on the couch, and elsewhere for other stuff. But that's just me. I'm notoriously eccentric in many ways


Yes, it seems to me I partly misunderstood the purpose of the project (what you intend to do on a PC, in particular), but I too find your logic fuzzy (regardless of my job :)): if you are in fact conceiving this software for a PC as well, then how is it going to work, in that specific case, without a GUI? I think the PC part misled me.
But, not problem, a cool project nonetheless. There's a lot of great stuff there pc or not!


As far as I am concerned, you may call my idea "Crazy Taym's Contraption" if you wish, it is just a matter of definitions and I'd not be offended in any way Having said that, I am sure the Empeg is comprised of software and hardware (I am pretty sure I've been pushing buttons on it in the last 10 years ), so since you said you're creating a new software part to be used on current hardware and PC, I assumed that "current hardware" could include touch screens, and PC referred to in-car PC (and all that implies).
Of course, this is your project and you may design it as you wish. In any case, great project, and thanks a lot for keeping the Empeg community alive also with such projects, cool indeed.

I'm prepared to admit its confusing. The player software has a UI - it generates an "image", the image being 128x32 dots of 2 bits per pixel. It is a graphic, so it could be argued either way but by most definitions it is not a GUI as it does not interact with anything. i.e. its fixed size, no "real" menus in a GUI sense, no Z ordering, no interaction with a desktop etc.

You may have missed the earlier parts of this thread, this image is a desktop (X11) application for viewing and controlling the player.
http://www.jonshouse.co.uk/display_on_x11.jpg

If you follow the youtube links you see examples of the player running on MK1 and MK2 empeg hardware, a Raspberry Pi board driving an LCD display and a Raspberry Pi board driving an LED display.

The player itself sends its graphics via UDP (networking) - it is the job of the display (in the case above a program called 'display_on_x11') to render the image so the user can see it. The player itself is not aware of the front end, it just accepts button pushes (or text commands) and does "stuff" with them :-)

Another way to think of the is that Centro player is a server, the program rendering the front end is the client.




Well yes and no. As microsoft have discovered its a different way of working to drive something with a touch screen, the empeg is a button driven interface. You could emulate the buttons with a touch screen by pushing an up/down/left/right button (as in the graphic above) but the sofware itself remains button driven.

The software can be extended (its open source after all), its possible to hack into whatever interface you would like. The software runs on real empeg hardware, linux PCs and Pi boards (confusingly with or without a front end !)

In "master/slave" mode the player can have multiple front ends at the same time - think two or more displays and buttons but one player.

Even I think understanding it is tricky, I will write some proper documentation for it one day :-)

Hope that helps.

Jon

Jon, one more clarification on my part that I see is needed: by Empeg UI I actually meant the Empeg User Interface: buttons & rotary knob.

I assumed that by bringing the player >> on the PC << you intended to also create a software version of the Empeg UI (turning it from a hardware UI into a GUI). I see that's not what you intended and probably I read too much in your reference to PC.

All the rest (On Empeg hardware, or on Pi) is clear and I actually saw the interesting videos.

Thanks,

I'm not sure I fully understand the question, I think the answer is "yes".

The screen capture shows a front end X11 display process and a button process talking to a Centro player process.

Does the video clarify it, this is all on the PC. In this instance, the Centro player process and the two front end processes running on Debian desktop linux (that is 3 programs). You can split and have the player on a Pi board and front end on the PC, or swap them round, or have mulitiple front ends - I did say it was confusing....

http://youtu.be/S3ixxMDCcG4

You are aware PC is not the same as "Windows" ?

I don't think it's that confusing.

Centro doesn't have a "UI", it has an "I" that works by listening for specific messages on the network, and spitting out a stream of images to the network (that corresponds to the display).

Anyone can write a custom "UI" for the player, by mapping user actions (pressing an analog button, pressing a touchscreen in a specific location, using the mouse to press a GDK or Qt widget in a desktop app) to generate those network messages, and rendering the stream of images pulled from the network.

Because the player is "UI" agnostic, it can have whatever "UI" you can dream up. On the Pi or a desktop that has an attached microphone, you could have a voice-recognition control app, for example.

So far, you've provided a few reference applications.

Well, if I am completely honest the whole thing is a bit "hacky". I wrote an X11 front end to speed up development, that way I get to compile entirely on the PC without the effort of cross compiling. I'm not sure any of the code is clean enough to be called a "reference application".

What I must do sometime is document the thing. The player has a (limited but functional) command interpreter, it will accept more than just button presses - but without digging into the source nobody would know. I used UDP so that the front end also works with the LED sign code (broadcastfb_proc), not sure that is going to everyones cup of tea though.

I'm not convinced its worth any more public development, with only 12 downloads of the source plus one single rating of a thumbs down for my youtube video of the MK2 player i'm pretty convinced nobody will ever use it !

Cheers,
Jon

I haven't downloaded it yet, but fully intend to do so, and to use it on several of my players here.

Just not yet.. in a particularly busy spell with work at the moment.

So please do continue with it!!!

I haven't downloaded it either, but I fully intend to in the future, maybe when there is a UI for Windows or -dare I say it- iPhone. I'm not a Linux user, and even though I'm now taking my first baby steps with my RPi (and love it), more than 90% of my own ecosystem is still windows, so that's why I'm holding off for the moment. If a Windows version never comes, then I'll probably WILL try the Linux version, but I don't really have the time to tinker too much with it at the moment.

But please don't chuck it in, I for one am VERY curious to see the direction this project is heading into!

Ditto. Only add a 3-year old, and a 3-month old on top of busy work!

Ditto again. 4,2, and 1 year old and an international move consuming my time...will try it soon.

Okay... sample code, then.

Ok, it looks like some people will use it so I will stick at it :-)

I also have some real work to do but at the end of the week I hit a work lul for while so I will have some time to burn. I guess next job is to add tuner and AUX input support for the empeg.

Like I said in an early post I wrote it for myself. My main concern was newer hardware and LED displays rather than the empeg unit itself, you have PCA to thank for the empeg support as he complained when I dropped it and encouraged me to put the code back in and make it work :-)

Thanks for the feedback.

Jon

Jon, so I take it what when you said the "player software has no GUI at all", you meant you were using a separate software as a GUI/front end, and that the player software per se did not have it. Great, it makes sense and offers a great deal of flexibility.

You are operating on that via mouse on a PC, and I think that touch would work better in the specific case of an in-car PC, where your software would be fantastic, I am thinking. But, please do not take this as criticism to your work, that is fantastic. I am just thinking out loud here



Are you being sarcastic here? There's no need to be, Jon, please read all my messages as friendly and if they seemed otherwise I am sincerely sorry.

No I was not, remember I can not tell anything much about you. You have said you have a lot of windows kit and like touch screen, I take this as you being on the younger side, I have looked at your profile now - you are only a few years younger than me so I guessed wrong!

I am over 40 and worked with PCs well before Windows, a lot of people less over the hill than myself think (partly thanks to Microsoft marketing) that PC is Windows. I have endless examples of me saying to a client "yes, I can make that works on a PC" and getting a reply "bla bla windows bla bla" as they have failed to notice that windows and PC are not the same entity. As it happens I can write for Windows, but mostly I code for linux on generic PC kit.

As you changed platform at least twice and operating system 3 times in just one post, I wanted to check that you did appreciate that PC is not the same as Windows, if you had confusion on this I would then explicitly state "PC/windows" and "PC/linux" in my answers to help clarify it for you. I was not in any way taking the piss.


I did not take it as a criticism. When you talk to developers appreciate they are often highly context sensitive and staggeringly literal. This can seem rude but its not intentional.

I have not taken any offence from anything you have said, nor have tried to cuase you any offence, sorry if I have managed to do so.

It can be difficult to helpfully answer your questions if you constantly change context, my replies have mostly been trying to pin you down to one context so I can fully understand what you are asking me and offer a useful reply.

Touch screen emulating Up Down Left Right buttons = Yes, very easy.
Touch screen as a more complex interface (drag, gesture etc) much more tricky, possible, but not my cup of tea !

Thanks,

Jon

http://www.youtube.com/watch?v=xsN5hh2G7l8

No offense taken.

I understand your project, looked at the diagrams, looked at the videos, understand the software architecture you've designed, and most likely will be testing it on one of my empegs.

Having said all this, my first post was underlying one particular possible usage of your project, and was based on the assumption/understanding that you were doing on a PC (whatever OS) what you are in fact doing: replicating the Empeg UI on screen, making it a GUI in all regards.

And that is: IN-CAR PC.

I've been thinking for a while that current tablets would be quite interesting if used as an in-car PC. There are some iPads hacked as such, but my personal problem with that is that
1. an iPad is not a PC, so I've been waiting for an some x86 tablet to hit the market. That's happening now.
2. I don't know of any software that can get close what I consider the best ui and feature set for an audio player in a car: the Empeg.

So, an all-software empeg on a x86 tablet is very, very interesting. The Empeg device is now old, not in production, and everyone here is complaining that there's no such car player in the market anymore. I've been complaining about that for years now
Now, you can revive the empeg, with your software, in many ways: on all the hardware you mentioned (Pi, existing Empeg) but ALSO and very interestingly on an x86 tablet, and THAT can get in a car. In other words, you can take the empeg experience and free if from the hardware (now obsolete) that it was originally conceived for. In particular, bringing it on X86 tablet seems to me a wonderful opportunity.

That's what I am talking about.

Now that would be interesting. The only tablet I have ever had any use for is my Kindle. Apple, Android, whatever, they just don't do anything that I want or need to do. Obviously tens of millions of people are wrong and I am right, of course... Seriously, there's nothing wrong with tablets, they're just not for me.

But this idea... if Jon can get a "software empeg" working on a tablet, and if I can then pipe the output of that tablet into my car's audio system, I'll be standing in line at the computer store to buy whatever tablet it works on.

tanstaafl.

Dont forget a Raspberry Pi add kit on is in the works, this would make empeg style hardware for a reasonable (as yet uncalculated) price, not give away cheap but less than an x86 tablet I suspect.

Another thought though... under most android tablets is a linux kernel. If somebody can modify a cheap (ARM) tablet to run generic linux then it should be possible to run my software. The softwrare has both X11 and framebuffer output code, the framebuffer code scales so it would drive a smaller tablet full screen. Worth a thought .... Personally I would rather have the VFD (or on my new hardware OLED) display, but that is just my personal taste.


No promosis but I will see what I can do. Any reason it has to be x86?, would a $80 Arm tablet that did just one job suit or do you prefer an application running on a Tabet desktop (slightly more tricky but possible)..

Jon

Any portable device that can emulate the empeg hardware and do everything or nearly everything the empeg UI does would be fine. I am not a "techie" - I want a turnkey solution: buy the tablet, load your software onto it, add the music, and voila! I have a fourth-generation empeg in a car whose integrated stereo system doesn't allow modification.

Would the ability to drag-and-drop the music onto the tablet from my Windows PC require an x86 tablet? Would we use emplode to load the music onto a Linux tablet?

How about the capabilities available only through the empeg remote, like "next song by same artist", that sort of thing?


Remember that you are talking to people who ten years ago unflinchingly paid more than a thousand dollars for the original empeg. I put a good few thousand dollars after that into building a stereo system for my car that, alas, is no longer with me. A few hundred dollars for a tablet is trivial at this point.

At first I didn't understand the point of your project, but now I get it. This is exciting.

tanstaafl.

Any cheap hardware that allows a new, updated Empeg device in my car would be superb to me as well.


But, ALSO, in addition to the above, and to answer to you question on why x86:

>>> In-CAR PC.
Today there already are real PCs (i3, i5 processors) in Tablet form factor. With those and software like your, one could have a real in-car PC that ALSO offers the empeg experience.

Also, this could be a device you don't leave in the car, unless you want to. This is a device you take with you for work or any other reason. A real tablet PC.
The UX I would love for myself includes using this tablet PC docked for work, at home on the couch, travelling. In other words, ALL the things I do today with my laptop and can't do nearly as well with my iPad. BUT ALSO, with a software like yours, I could dock in in my car and start the Empeg software, and replicate the BEST, by far, in car experience ever.

One more idea (which I quickly mentioned in an earlier post): why not an "App"?
Also interesting, even though less for those like me who like full featured tablet-pcs (x86), would be to make this an App for the most popular OSs: Android, for Android tablets (or phones?), iPad (hoping one can easily replicate the empeg experience using mp3s on the iPad), Windows (where one could easily use MP3s on the local file system). This could get an interesting and, who knows, popular App if its GUI is designed for in-car use (which means, to me, large icons and fonts, and touch).

The fact is, it seems to me we are really a step away from making our smartphones and tablets the main way to control our on board stereo system. If you put an Empeg-like App on them, and people start to realize its potential, who knows, that could even, maybe, create some market.

To sum up, I see three things here:

1. New cheap dedicated hardware for a revamped, possibly inexpensive, Empeg. --> Raspberry Pi, for example
2. Empeg as an APP for most popular OS ecosystems (Android, iOS, Windows Phone)
3. Empeg as an App/software for PC OSs (Linux, Windows) for in-car PCs.

Pretty cool, I think. But, again, I am just thinking out loud and throwing out ideas one may or may not like.

As Doug, I'd be standing in line to get it, and happily pay for it. Of course, not easy to say how many others would. For me, I'd pay way more than the cost of a standard App for this.

A picture of some prototype dedicated hardware

pca

Hmm... it needs more nipple.

Ooo. So am I right in guessing that prototype has an OLED screen? (based on the file name)

It's a 256x64 OLED panel, which although smaller (and much thinner) than the empeg VFD, has a visible display area almost exactly the same dimensions. Also 16 grey levels, unlike the VFD's five and half, rounded down to 4

Jon's current software emulates the 128x32 2BPP display on the OLED display in a very convincing manner. The blue one also looks very much like the empeg display, but if anything is brighter.

It's driven by SPI from the raspberry pi expansion port, and also has the same button and rotary encoder layout as on the empeg, with a consumer IR receiver as well.

pca

WINNER! Laughing out loud here.

Seriously, though, GORGEOUS photo of a super-clean display board there. Wow.

Raspberry Pi kit progress
Pi board

http://www.youtube.com/watch?v=qbrIKQTly_s&feature=youtu.be

Just a quick update,

Jon

Nice!

I'm guessing I'm not the only one here thinking about ripping out my empegs guts, sticking a Raspberry Pi in there along with that beautiful display.

Although how to get my illuminated buttons working...

That would, in my opinion, be a mistake. The empeg is a reliable, resilient system with excellent audio output, a lot of tolerance to power supply fluctuations, and is specifically designed for high vibration environments.

The Raspberry Pi is none of the above

That said, it has two things going for it - it's cheap, and it's quite fast. The reliability can be improved significantly by powering it from a source other than the micro USB socket. The audio is more of a problem. While it's acceptable, it's certainly not audiophile grade (it needs a lot more silver plating for skin effect reduction, for example ). I have been considering doing a small expansion board that would give a better codec, but haven't yet had the time.

I am in the process of designing a nice acrylic box to put the Pi, a small switch-mode PSU, and the display board in, which would give a neat table-top audio player.

I'm not convinced it's the right hardware for a car player, though.

What I have been wondering is if there is any point in doing a replacement display board for existing empegs that uses the OLED panel. The display area of the OLED is about 1mm smaller horizontally and vertically than the VFD, and it's at least as bright. One problem is that it's much more monochromatic, so it needs a filter exactly the right colour or most of the light goes away.

pca

I haven't had a chance to try the centro player yet, but I do have a crazy pipe dream feature request.

So, we all love our empegs, but a lot of us are also cheating on our empegs with podcasts and cloud-y music services. The possibility of tight integration of these things into the stock player was virtually nil, but with a fully open-source player, it seems like these ideas might be within reach.

One such idea I'm thinking about would be the ability to play tracks from Google Music, and it turns out someone has already done a lot of the hard work involved in exposing Google Music libraries as a Linux filesystem using FUSE. You install the app, run it, and it goes out and indexes your collection, and gives you a relatively sane directory structure under which you can get easy access to the MP3 files.

So, the missing piece is how to easily integrate MP3 files on the Android smartphone's filesystem with the Centro ecosystem, and for that, I was thinking something like MPD might fit in well. There's an android port, which means in theory one could run a server on the phone to serve up the mp3 files as content that can be streamed over to an mpd client, e.g. a Centro player speaking the mpd protocol.

Obviously the architecture is getting a bit Rube Goldbergian at this point, but with these pieces of the puzzle available, the task of having Google Music content playing on empeg hardware actually seems doable.

Anyway, I'm still finishing up my own empeg install and associated software bits, but once I have an empeg in my car, I'm going to give Centro a try, and if it's something I could see using as my everyday player, I might (might!) try to experiment with making this happen. Just thought I'd throw the idea out there and see what y'all think.

Thanks to a plonker in a taxi the "display-extender in the XKR" install is no more

I'm at the point where I don't want to use the empeg in a new install now - my interests in mobile computing mean I'm more interested in a raspi or tablet-like solution.

So to address the sound quality from a raspi I was thinking:
http://www.ebay.co.uk/itm/YJ-TE7022-WM87...=item2577110cf3

also Tony - I think you may have the mpd architecture wrong. The mpd server is typically a headless unit which can be controlled by mpd clients,
You'd want the head unit to run mpd and your phone to be the control interface.

You could write something to plugin to mpd to stream audio to the player using jon's udp protocol. Then you'd have to figure out display udp. I really think that's not going to work.

At that point I think you're using the empeg as a TCP->RCA convertor with a very limited display and the knob/buttons. Reasonable if it's already installed - and I'll probably explore that in my other installation.

For me, for a new install, I think it'd make more sense to use a RasPi or a UDOO with some decent DAC (like ^^^ ?) and a display/input (eg a phone/tablet or Patrick's display replacement).