OK, we knew this was coming.

I have a Mac. I want to be able to talk to my Mk.II without using Virtual PC. I can do that using Ethernet, so long as I know WHAT I have to tell it.

Can we now (finally) get the specs on how to talk to the Empeg for retrieving the existing playlists (as emplode does) and then for uploading new files and playlists?

e.g., Now that "device drivers" are no longer an issue, I'd like to start working on a utility to talk to the Empeg the same way emplode does, but on a different platform. (not sure if it'll end up being my Mac, but who knows )

D

I have been asking for the same thing on and off for the last six months without a very positive response. I run MacOS 9, MacOS X Server, Mac OS X Client, LinuxPPC, and could probably even come up with with Solaris or NeXTStep. But, I don't do windows and don't really do linux X86.

I have asked for a variety of things: open source emplode, version of emplode that runs on the Empeg and finds songs via NFS mount (possibly with a web interface), web interface to the empeg through which you upload directly. A command line version of emplode that ran on the empeg itself would open up a world of opportunities.

Come on guys, give us the specs to talk to the empeg so that someone can get something working that I can actually use by the time my number comes up for a MK2.

VPC is not a viable long term solution AFAIK. There are at least a few of us here that would be willing to write our own software to talk to the Empeg, but we need some info on how to do it.

Thanks,
Mike

Hmm, you can try it the Hard way, using Etherpeek ...
I spent a week beside a colorcopier talking via ethernet to learn its protocol ...
Ahhh long time ago :-)

But i guess you just have to nag the empeg people, otherwise give it a try with etherpeek ... maybe the protocol is realy easy ...

Nils
Ooops i hope this is not illegal or unwanted, if yes, please delete it from the protocol :-)

The main reason it's not been released is simply that people are still having sync'ing problems. We don't want to release anything until we're 100% sure it's stable enough not to change for the forseeable future.

Basically, the same error-correcting resilient protocol is run over serial, usb and ethernet (tcp socket).

The source consists of several C++ classes, from a basic protocol class family (with replacable connection objects for different media) to the emplode program which deals (albeit rather messily) with the way the empeg database works.

Unfortunately, we don't have enough people or time to produce wierd & wonderful things like web interfaces or versions that run on the unit itself - with only 5 people in the software team and lots of non-empeg-car things to do, we have to concentrate on the software actually necessary for the vast majority of users - ie, emplode.

Hugo

The main reason it's not been released is simply that people are still having sync'ing problems. We don't want to release anything until we're 100% sure it's stable enough not to change for the forseeable future.

Although I agree that you guys are busy, and that there's still software issues that take precedence (such as getting the Mk2 builds up to the stability of the Mk1 builds), I'm not certain that your "100%" goal is realistic.

Your synch protocols are going to keep changing over the long term. If you wait until they stop changing to release them, you may doom yourself to never releasing them.

Yes, some people are still having synch problems. But most of the major ones have been solved since around beta 10. And if you open-sourced the synch protocols, perhaps some of the experts could help iron out the last few problems for you.

Yes, there'd be the issue of third-party synch utilities becoming obsolete when you upgrade the player software, but that's for the third-party developers to worry about. And in any case, that's no different than an end-user upgrading his player without upgrading his Emplode.

So consider releasing the synch protocols once the Mk2 builds settle down a bit. If only for the Mac users...

___________
Tony Fabris

Sorry Hugo, I have to press you a little on this one. You guys are always going to be making changes (I hope) and whoever maintains other platform sync software is always going to have to play catchup. This is not that big a deal as long as you always update the specs when you release an updated version of the classes. I am sure you guys maintain internal documentation as you do upgrades so it shouldn't be that big a deal to make that documentation publicly available and up-to-date.

PPC/Sparc/Alpha/MIPS/(name your favorite platform/OS here) may only make up 10 percent of you target audience combined, but if you can grab this 10% for the price of keeping some docs and classes up to date isn't it worth it?

-Mike

OK, so maybe I am biased because I have been doing a bit of java programming recently, but it is really nice to have stuff that I can use on any of my computers (yes there is quite a variety).

"If only for the Mac users..."

Hmmm, if you where not agreeing with me I would probably take offense to that.

-Mike

Hugo, perhaps you wouldn't have so many synchronisation problems on another platform - weren't a lot of your USB problems related to poor support in Windoze 98?

Just another rabid Mac user who wants to connect to his empeg with something other than a serial connection on an NT box (hey, that's all they'll give me at work!). And will the Mk3 have firewire? Toss the USB if you like. Now that would be cool! No more opening the empeg to add extra disk drives! :-) and peer-to-peer support, and FAAAST, and, and ... :-)

(list 6284, S/N 00299, 4 gig blue)

FYI, I just added a "no doze" topic to try and get a head count for those of us who are looking for a non-X86 version to the General forum. Not trying to be a pain, just curious how many of us are in the same situation.

-Mike

As I've said, there aren't docs on the protocol - just the code. We have to find time to (a) tidy the code and remove dependencies (the protocol library rests on some of our core classes that we don't want to give out) and (b) write at least an overview of how it works - we don't have the time to answer lots of questions from 3rd parties when the code is released.

Hugo