I'm working on it folks ... only 41 build errors left in jEmplode (down from a couple hundred). Since Karma was a higher priority, I basically closed the jempeg-empeg project as I made tons of changes to the backend to add all the fancy features for Rio Music Manager Lite because they have a pretty radically different method of synchronization (i.e. refactoring wasn't really an easy option here). So I'm in the process of porting the Empeg stuff up to the new Karma API's -- so you guys will get cool features like background autosync and the visible (soon editable) sync queue. One thing that has disappeared right now is tag rewriting on download -- because of licensing for Karma, I had to port the Rio MP3 libs rather than use the ones that were in jEmplode and I only ported the read portion ... Unclear what the best method of attack is to get it back right now (i.e. keep the previous MP3 libs for jEmplode and ship different ones with Karma, or try to standardize on a single set of libs, which would require me to do tag writing too).

Anyway -- That's where things are right now ... It's getting there.

ms

... Make that 25 build errors -- I was accidentally counting my "Note To Self"'s that show up in the same list.

Totally rad man, can't wait!

wohoo!! does this mean that i'm going to have to recalculate my crcs from v45? also, do you still have that long list of requests and bugs from the v45 days? i just want autosync with tags... not too much to ask for, right? =)

One thing that has disappeared right now is tag rewriting on download

As long as the nifty file naming features are still in there, then I don't need tag rewriting on download. I can carefully name the files and then after they're downloaded, do a filenames-to-tags pass with Tag Studio. So no worries.

I'm hoping that someday we can get a GUI version of the playlist backup/restore functionality that you implemented as a command-line tool for the Karma...

Oh, and I have to say, for the benefit of those who don't have Karmas yet...

Mike's RMM lite is THE BUSINESS!!!

Very very slick and works really well. For some, it will become the preferred method of loading tunes into the Karma even when the Win32 version of RMM is available.

Wooooo! This will be most excellent!

Indeed, very nice work on RMM Lite Mike!

I think the CRC's are the same actually -- The algorithm I used was strategically the one that was going to be used for the Karma. At least that was the theory -- I don't recall making any changes.

Yeah -- I have a huge list of requests ... Unfortunately, I probably won't get to any of them for this next release (unless people would rather me hold off getting a release out and add more stuff). My focus right now is just getting it back where it was but on the new platform.

Oh and it does autosync on tags ... (actually for everything) Autosync will probably be a configuration option.

ms

Yep -- it's still there ... I actually had to remove a lot of features (like this) for the Karma.

The backup/restore thing is definitely on the list of things to do ... If I spend a little time on it, it could easily allow you to backup/restore between devices, so I'll probably do that first.

ms

Oh, Tony Fabris, you make me blush

ms

I'd just like to get rmml running on my Redhat9 system soon..

Exception in thread "main" java.lang.NoClassDefFoundError: rmmlite/jar

Scrub that.. got it now.

java -jar rmmlite.jar

Can you do a java -version or java -fullversion and see what version of the JDK/JRE you have installed? You might want to go to java.com and see if it recommends that you update ... That error sounds like what you would get from a 1.1 VM (which didn't support the -jar commandline param and is interpreting rmmlite.jar as a package name), but that's just a guess.

ms

Naw, it's working fine now.. just didn't realize it needed the "-jar" flag.

Cheers

<rant temperament="ornery">
On a completely tangential note, I think Sun should be thwapped over the head with a cluestick for not following generally-accepted standards for command options. "java -jar" should be either "java -j" or "java --jar". I can't tell you how many times I'm working with WebSphere at work and I type "java --fullversion" to find out what JDK I'm in, only to get this:

Unrecognized option: --fullversion

Could not create the Java virtual machine.

.
I know Java isn't the only software out there that does this, ("xterm -display" is another one that I hate.) But it makes so much more sense to use a single hyphen for single-character options, and a double hyphen for "long" options. Or at the very least they should support both for forgetful schmucks like me who can't remember which program uses which "standard."
</rant>

I totally agree ... I also get annoyed that you need a -jar at all -- how about just looking at the file extension and seeing it's .jar and let you do "java rmmlite.jar"?

oh well.
to dream.

File taxi gives me a nice traceback, though. Want it here, or on the Beta BBS?

Cheers

Actually, you can just email it to me ... [email protected] . Does RMML work, or do they both fail?

That standard was widely accepted due to the FSF, if not actually created by them. It's by no means a Unix standard. I'd be hard pressed to expect Sun to cooperate with the FSF, an organization with goals pretty much diametrically opposed to Sun's own.

And the xterm example is not restricted to xterm; it's the way all Xt apps are expected to behave.

That being said, it would be nice if it supported what everyone expected, they break their own ``Command Syntax Standard'' (from intro(1)) by allowing multi-character options at all, and it's not like Java predates the widespread acceptance of GNU software.

well, I got into UNIX early enough (1983-ish) to think that the --foobar instead of the nicely concise -f stinks...

What? Not early enough to avoid the wasteful use of the `-' altogether?

In reply to:

---

What? Not early enough to avoid the wasteful use of the `-' altogether?

---

As in tar xvlfa /dev/st0" - sure

8 years later it wasn't hard to get a similar experience. Aside from gcc (since SunOS 4's bundled compiler sucked) I didn't get the "gnu experience" until later; I still attempt to live in a very BSD world. This means /usr/ucb/ps and not /usr/bin/ps, for instance. So, every time I use a root shell on a random machine, ps bitches at me that I gave it invalid aarguments. Oh well.

I think the CRC's are the same actually -- The algorithm I used was strategically the one that was going to be used for the Karma.

i seem to recall in an earlier thread that the checksum is the of 1st, middle, and last 64k of the datastream. thread here. what the crcs are right now are of all the stream.

41 or 42 did the entire stream ... I think 43-44 does the 1st/middle/last thing (it definitely does now). Only time will tell

nyeah, i definitely know that 45 did do a full one. we were discussing a way to shorten the scan time when you went off to do karma. wonder if i can even claim my place in karma fame for proposing the front, mid, and back 64k crc. bleh. i just want my name in some program's credits someday. heh.

but anyhow, i'm assuming that jemplode is going to use the 2.1 diretory structure? (drive0/fids/XX/YYYY)