OK, I have noticed several posts lately from people who want a non-windows utility to transfer music to their Empeg and maintain the DB. I know the guys@empeg already know we want this, but I thought a headcount might be interesting. There are several of us on this board who could probably write something given some specs and/or source code from empeg.

Yes, I know there is also a linux/X86 version. No, it does not really suit my needs.

So, without further BS. If you want a utility like this please leave your name and platform/OS requirements below. This might even incent some of us to do something about this when I finally convince Hugo and company to give us some specs ;-)

-Mike

OK, I will start. I don't much care about serial or USB. I want ethernet support on one or more of the following platforms (in order of preference)...

MacOS X Server/PPC
MacOS X Client/PPC
LinuxPPC/PPC
MacOS 8.x-9/PPC
MacOS 8/68040
NeXTStep/68030
Solaris/Sparc

Of course I think the ideal would be a java client as it could run on all of these (except, I believe, NeXTStep) or something that ran on the Empeg itself with a web UI.

-Mike

I've also said I would take a stab at writing a Perl module that handled the connections/sends/receives, to allow other people to write cross-platform stuff, so long as I had some specs to follow.

D

That would be ideal, as I can even run perl on RISC OS... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 for sale 4 gig #30, apply within)

There *won't* be any specs - we just don't have time to write them I'm afraid.

There *will* be portable C++ code, however. You don't have to persuade us to release it, we will be releasing it when we're happy with it.

Hugo

I'll stick my hand up for Mac OS X Client version as top preference,then Mac OS-9. Ethernet support is the only method of real interest. Can't help the writing but I'm a very willing beta tester...

Phil

Make my vote Mac OS-9 version as top preference, then Mac OS X Client. The way they are going with Mac OS X Client, the empeg software should turn up first ;-). In my case I'd prefer USB. I only have a Mk 1 at the moment, and I don't want to have to go out and buy an ethernet hub either. I have two perfectly good USB ports :-)

Have had a look at writing a USB driver so I could try sending commands to the empeg over USB like you can over the serial connection (is quite cool :-) ), but so far it wasn't any more than a look.
Am also a very willing beta tester :-)

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

Yeah, I'd like a Mac version. Like most other people here, I really only care about Ethernet.

Really, though, you should just be able to FTP stuff back and forth without installing a dev image.

I'm also concerned about upgrading. Until we can upgrade via Ethernet, I'm not really sure how I'm going to do it. I might get one of those Stealth serial ports for my G4, but it's not quite RS-232 serial...something like RS-422 or something where some of the more obscure pins don't work. Anyone given this a try?

Alex

You only need 3-wire serial; I suspect the generic USB<>Serial adaptors should work with MacOS, Mike did try a generic (D-link possibly?) USB<>Serial with Win2000 and this worked for talking to the empeg.

Hugo

Hugo,

I did not mean to imply that you needed persuading. Just trying to get a head count and show you guys (if you don't know already) how many of us are interested in alternative methods for syncing our empegs.

Thanks,
Mike

We already have a good idea of how many people want Mac or non-i86 Linux software, because those clients aren't usually shy about emailing us and stating their demands.

As your thread seems to have shown so far, there aren't very many of them.

That doesn't mean we don't want to accommodate other platforms and, as we've said repeatedly, the source for synchronising will be released when we're ready to release it. I realise it's been a long time in coming, but we've had to concentrate our efforts in areas that will generate the revenue we need to build a successful company in the short term. Cross platform support will help to ensure our success in the longer term, and it will happen.

Rob

Rob,

I hope you will take this as constructive criticism (as that is how it is intended). That response comes off as very snotty. Those of us who don't use windows on a regular basis are very used to hearing 'there are not very many of you, but your presence is loud and unwanted so we are going to placate you by saying that we will support you at some distant time in the future when we get around to it'.

I don't think that was how it was intended, but from a customer service perspective that is not the way you want to come off. I can appreciate the comments that you guys have made (particularly the more technical descriptions of how you are trying, but want to have the sync specs finalized first). I do not appreciate being told that there are not many others in my situation. I started this thread because I wanted to see if it would be worth my time to write a emplode type tool for MacOS or LinuxPPC. To be clear I am not asking for or expecting full cross platform support from empeg. I am not trying to petition empeg for anything that you have not already promised.

Fortunately I know that empeg has a good customer service record and that you have a really cool product, otherwise I might be looking more closely at that Alpine MP3 playing head unit right about now.

-Mike

Hi

One point I'd like to make right away is that I don't post here in a Customer Services capacity. I post here in a personal capacity, which means I get to be far more open and frank than if I were replying from info or support @empeg.com.

I didn't intend to come across as snotty. Looking back over my email archives (which run from June '99), we've had about 60 requests for Mac software, and no more than half a dozen Linux users who aren't happy with emptool. It's a plain and simple fact that the vast majority of our clients, currently, run Windows.

There's no need to preach about the rights or wrongs of this - we have a number of die-hard Linux and Mac fans at empeg, and I don't think anyone here is a big fan of Windows.

Nonetheless, it never fails to fascinate me when, should we fail to quite meet the level of service an Open Source advocate demands, their reaction is to move to a major brand that will NEVER open it's source in a million years.

In short - we intend to provide the source for synchronisation. The source requires some work before we can do so, most people at empeg already work well into the evening/night, and it's going to take us a while to get to. I've raised this issue with the development team a number of times, but right now, with Consumer 1.0 just around the corner and final release of a major OEM project almost due, the answer has been short and to the point.

What nobody seems to have considered is that Consumer 1.0 is due out in a couple of weeks, and it is intended to be a stable release. It would seem to make a lot more sense to petition for a source release after that time.

Rob

I didn't intend to come across as snotty. Looking back over my email archives (which run from June '99), we've had about 60 requests for Mac software,

Let's see, though... 300 units... 60 requests for Mac software, that's a firm 20% of the market. Is Empeg really so rich that they can afford to completely ignore that market segment?

What nobody seems to have considered is that Consumer 1.0 is due out in a couple of weeks, and it is intended to be a stable release. It would seem to make a lot more sense to petition for a source release after that time.

What seems to make a lot more sense ... to those of us on THIS side of the equation ... is that Empeg should have released it early on, and the die-hard Mac/Linux users would have already PRESENTED you with code that worked, which you could then include on the Consumer 1.0 CD, which you could distribute to new customers, and then you'd have had cross-platform support, "eight o'clock, day one".

You can argue that "we keep changing the code", which is fine, but its also easy to say "Give me a diff on the code", so that the outside developers can see the changes and incorporate them immediately.

It's just that (IMHO) it was short-sighted to not release the source code -- in whatever condition it was in -- early on, because people WOULD have figured it out so that they could build a Mac version.

One thing to keep in mind, Rob, is that you have customers -- not beta-testers as companies like Microsoft tend to treat them, but customers -- who may have spent upwards of $4000 already with your company, and possibly much more on car audio equipment to USE your hardware. At the price-point for the Empeg unit, the customer doesn't deserve to "have to understand Empeg,Ltd's problems" about deadlines on other products, etc. Now, I know you'll point out that the web site claims no real support for Mac's, and that Mac support is "on the back burner" according to the site. The point is simply that the Mac product could have happened completely WITHOUT Empeg man-hours, simply by releasing the Emplode code, in whatever condition it currently exists/existed.

This, to me, isn't about "Open Source" at all, its simply about functionality. You can make the license on the source code as resrictive as you want. I think, by and large, empeg Mac users would send you back the completed work, simply because they WANT support for the Mac.

I don't doubt you're going to support the Mac "eventually", but as a Mac user who is used to "eventually.... eventually ... some day... oh, well we changed our mind.", it does ring hollow in the ear. I know Empeg is mildly different than most companies in that regard, but when the effort required is completely zero , I can't see "Why not?"...

D

but as a Mac user who is used to "eventually.... eventually ... some day... oh, well we changed our mind."

You make some valid points, Dredd, but I wanted to chime in here with a response to the statement above:

Perhaps there's a reason we keep hearing that line from other software companies. If so, it's hard to get upset at Empeg for following the same pattern.

Fortunately, Rob has already stated the company's commitment to release the synch code. In my book, that goes above and beyond the call of duty. Other companies would consider that stuff proprietary. So don't badger them about it too hard, they're doing their best.

Although I agree (and have stated as much) that releasing the synch sources sooner rather than later would be a good thing. We have to realize that it takes work/time to do it, though, and time is something they're short on at the moment. We have to wait until the Mk2 builds settle down a bit.

___________
Tony Fabris

We have to realize that it takes work/time to do it, though, and time is something they're short on at the moment.

$ tar -czvf emplode-src.tgz ./src/emplode
$ cp emplode-src.tgz /home/ftp/pub/sources/emplode-windows/.

Remember that I said "give us what's there, as-is"... that requires NO extra effort other than the act of creating a tarball. Heck, now that I know the .upgrade builds are automated, I'd suspect its a matter of them just adding two lines in a script somewhere to also have the "current emplode source" get tarred and released simultaneously.

People WILL figure out the code if its there, regardless of how sloppy it may currently be.

D

Remember that I said "give us what's there, as-is"... that requires NO extra effort other than the act of creating a tarball.

Not that simple, I'm afraid. Hugo has already stated that some of the code is dependent on third-party libraries that aren't redistributable. They need to change the code a bit before it can be released that way.

___________
Tony Fabris

He said this about EMPLODE? What third-party libraries could they possibly be using in there? Only thing I can think of is the ID3 stuff, and it shouldn't be hard to NOT include that (if necessary) as part of the tar command, and since it is completely foreign to the actual task (synching) it should be a moot point...

D

The protocol is reliant upon libraries within the empeg internal build structure that we don't want to release - we only want to release the classes that are needed to actually build the tool & not some of our other core libraries.

Please understand that it is *not* as simple as tarring it up and stuffing it on the website!

Hugo

The empeg guys have stated, many times in the past, that they are a software company and not a hardware company. I must agree with the decisions regarding their source code as that is the mainstay of their business. While I agree with the notion that Mac/Solaris/Be/*BSD/Linux/etc support would have been evolving over the last X monthes; the fact remains the vast bulk of the empeg owners are MS Windows users, and empeg must focus their efforts to support them. That is a fact of reality. Patience has its own rewards, and I think that this is one of those situations where we (the Mac/Linux minority) must be patient. It serves our purposes, to a greater degree, to work with empeg rather than against them. If we continually badger them about this point; we may end up with no support. Some monthes ago, a rather heated license discussion erupted. All issues were resolved in the end, but in the thick of the disussion it was not so clear cut. In the final analysis, I have the impression that the whole situation left 'a bad taste' with the empeg folk.

Personally, I've been waiting for eight monthes, others have been waiting longer; I don't think it's going to hurt us one bit to be patient. If we play our cards right, we'll have an ally rather than a begrudging acquaintance or an enemy.

"Nonetheless, it never fails to fascinate me when, should we fail to quite meet the level of service an Open Source advocate demands, their reaction is to move to a major brand that will NEVER open it's source in a million years."

FWIW, this is not about open source. If you where to send me/Dredd/whoever else has commented on wanting to write a MacOS version the currently existing sync source with the provision that we could never re-release that source, but could distribute (for free) binaries derived from it, I do not think you would hear many complaints. We are interested in functionality at this point, not trying to force empeg to open source anything you don't want to. You keep saying that you don't have the staff at the moment to deal with other projects, but you seem to be missing the fact that some of your "clients" are offering to do it for you.

-Mike

Exactly!

I have long said "show me how it works, and I'll write a perl package that does the net IO so that other people can write the apps to talk to it".

I'm perfectly willing to sign any suitable NDA in order to make this happen.

D

> Let's see, though... 300 units... 60 requests for Mac software

Erm, no - this is info@empeg.com email - POTENTIAL clients. So, 60 requests out of over 15,000 registrations. I have no doubt that the actual percentage of Mac owners in the queue is greater than 0.4% (what is the Windows to Apple ratio worldwide? I have no idea) but I guess some of them are OK with using Virtual PC and Ethernet for the time being.

> Empeg should have released it early on

Well whatever the argument there, we don't do time travel.

> One thing to keep in mind, Rob, is that you have customers

I know, I'm responsible for Customer Services, and I don't think we do a bad job. I get to sell to clients whatever our R&D team develop, and right now I'm selling stop-gap Mac and Linux solutions. I think we've been above board about this, to the extent of (when we shipped Mark 1 players) advising Mac clients not to buy unless they had access to a Windows machine.

I don't think we misled anyone - I know that's not what you're saying, but unless we had done so I don't think there's an issue for complaint. I think there's a Wishlist issue, but this is getting a bit stronger than "What we'd like is..."

> empeg Mac users would send you back the completed work

It's VERY unlikely it will be that straight forward - some technical support will be required. I fully agree that a little tech support in return for Mac software would represent excellent value for money, but right now none of our developers are able or willing to provide that time and effort. At risk of further inflaming the thread, yes, we do have more important things to do right now. We have a to-do list for all empeg car tasks (that we have thought of to date), everything is prioritised, everything will happen in an order that has been decided. When the list was drawn up we had not anticipated the enormous success of our OEM business and we are behind the schedule that we had determined. Nonetheless, everything will get done, and getting the synch libraries finalised, cleaned up, documented and released is one of those tasks.

Regards

Rob

> $ tar -czvf emplode-src.tgz ./src/emplode
> $ cp emplode-src.tgz /home/ftp/pub/sources/emplode-windows/.

You must be joking - it's full of proprietry OEM stuff that we can't even hint about let alone release. We're not kidding when we say the source needs work before we can supply it!

Rob

> I have the impression that the whole situation left 'a bad taste' with the
> empeg folk.

For the record, we're fully supportive of the GPL and open source obligations. The issue might have been resolved a little quicker had Debian made available the source to the version of the binaries we distribute (yep, they were in contravention of the GPL - I guess everyone makes mistakes!).

Rob

I guess everyone makes mistakes!

Too True! :)

One think people here need to realize is empeg is a business, and they need to make money to survive. At this point, they have only shipped a handful of players to people who understood it only came with support for Windows, and a simple Linux tool. They have invested a good chunk of change into the new Mark II and other products that have not earned enough to pay for themselves. Yes, they are saying "We will support other platforms later" for a very good reason. If they sit down and start work on even the base for getting a non Windows tool out, they will loose time better invested in making sure they don't go out of business by the end of this year. Personally, no matter what side of the fence I was on, I would not be bothering them this much at this point. They have said support was coming, and never deceived any existing clients. Beyond that, there is not much that can be said.

Douglas Adams is a die hard Mac supporter, but when it came down to making his game "Starship Titanic", he had to either release it for Windows first and wait for returns to make a Mac version, or never make a game. Empeg is in a similar position, and people need to respect that, or watch the company either die, or go to a no public-product method.

Also, the fact that Rob is having to drop out of customer support mode to participate in this fourm should be a clue to stand down for now.

Once again, no one is asking for empeg to spend one minute working on a mac version of emplode at this time. We are just looking for something to get us started writing our own.

I respect Rob and appreciate the fact that his postings here are not as a official representative of Empeg. I am not sure however, that the average reader of this board understands that. I also do not know how he would respond to the same query placed through official channels (support@empeg.com). This is why I decided to post my original response re: customer service.

I am not trying to press empeg too hard at this point. I am primarily trying to evaluate my options. Do I wait for empeg to release something, do I attempt to reverse engineer the protocals with etherpeek or a similar tool, do I look for another mp3 player that will better suit my needs, do I wait for someone else to write something? I don't have an empeg yet, and before I drop $2k on one I do not think that it is unreasonable to ask when the already promised sync source code will be available.

If anyone at empeg thinks I am being an a**hole about this please tell me and I will not waste anymore of their time with this discussion (I will continue to evaluate my options privately). If anyone at empeg wants to publicaly state when the already promised source will be available that is fine too. My only gripe is that 'whenever it is ready' is really not a very good answer. If Rob sent you a letter saying they would like you to pay for your empeg now and that they will ship it to you 'whenever it is ready' how would you respond?

-Mike

OK, official response.

"Q. What support is there for the Mac, or for Linux?"

"A. We do not currently support the Mac directly, however the Windows software will run under Virtual PC using an Ethernet connection to the car player. You may need access to a Windows PC for loading software updates onto the player, although we are working on a way to do this over Ethernet. We do hope to provide native Mac software in the future, but we cannot offer any specific time frame for this at the moment.

We supply a command line tool for Linux, currently as an i386 binary. It is intended that source code for this tool will be released in the near future to facilitate building for other hardware platforms."

Rob

Arghhh, (mcomb smacks forhead with palm of hand).

I have to do this, you understand right?


"Q. What support is there for the Mac, or for Linux?"

"A. We do not currently support the Mac directly, however we are currently working with some outside developers (enthusiastic clients really) to provide an open sourced alternative that will allow synchronization on a wider variety of platforms. We expect that this partnership will produce a variety of syncronization tools some of which have timed their initial release dates to correspond with the widespread availability of the MarkII player later this summer."


I am going to try my best to make that the last message I post on this subject seeing as we don't seem to be getting anywhere.

-Mike