Top jEmplode Wishlist?

I have a huge list of emails of things I could fix/add in jEmplode, but I thought I'd post up here to get a (hopefully) smaller and more bang-for-the-buck set. What most annoys you in jEmplode or what would you most like to see added?

When making a new play list: I wish that after typing the name, hitting enter would create the playlist.

- When copying a playlist or a large number of tunes from one device to another (using the cool new features that you added for doing this), it sometimes exhibits a bug where it slows down to a crawl during the transfer. I seem to recall we discussed that one once. Someone else on the BBS reported the same behavior. It would be cool if you could track that one down.

- I would love to see the features that are currently separate command-line utilities (Rid rebuilding and playlist backup/restore) appear as menu options in Jemplode, so that we don't need the command line utilities any more.

- I would love to see the playlist backup/restore be intelligent enough to replace an existing playlist instead of creating duplicate playlists when you restore it. If that's complicated and too much work, then no big deal. Just a suggestion.

- I'd like to see jempeg.org be the single central repository for all things jemplode. Official Jars and bleeding-edge jars, either way. No more clandestine releases on the Inzyme site. I think that if you completely removed those self-installer packages and just put up a Jar, I don't think anyone would whine too loudly, as long as you said clearly "you need to get the runtime from sun <here>, then you can double click on <this> jar."

- Support for a virtual empeg (or riocentral) device

This would allow you to essentially back up (via click/drag) all of your music/playlists/dynamic partition stuff locally, organized as on the player, to allow for complete restores after catastrophic events.

Obviously, it would be a virtual device only in the sense of keeping track of the data and would not operate as a player. I suspect it'd just be a folder hierarchy controlled by jemplode with data situated accordingly.

Useful for people with no backup unit.

Not sure this is a top request, but more something that came to mind the other day and I couldn't dislodge it for some reason. It may be a monumentally bad idea.

-brendan

Fix the animation uploading. Fix fast database rebuild, it was cool with my collection. 15 seconds instead of 3 mintues. Finish the plugin capability, so that we can use palantir. everything else is all good in my end.

The ability to due a true one way sync to the empeg from a directory on the local computer. If a file is no longer on the local machine it should be deleted from the empeg.

-Mike

jEmplode or what would you most like to see added?


A one-click backup utility that would create a complete restorable mirror image of my player onto my PC. By complete, I mean everything -- EQ settings, play counts, playlist structures, etc. I want to be able to install a new hard drive in the player, copy the backup from my PC onto it, and have the player be in exactly the state it was in when I made the backup.

tanstaafl.

Tag filters to limit the tag fields that get downloaded.

I second this one!

> one-click backup utility

This would also work (vs. my virtual empeg idea).

-brendan

The fast rebuild stuff kicks butt, I'd like to see it back in the next version.

So the rsync theory is no good, or you want something more pointy-clicky?

Hm. Well, the dynamic data partition could be saved easily enough.

Oh right, and getting "Replace Tune" working, but I wonder if I'm somehow "special" in that regard.

> So the rsync theory is no good, or you want something more pointy-clicky?

Yeah. I suppose the idea of a "virtual empeg" (vs. backup) would be so that one could go ahead and keep updating playlists, tags/dbinfo and tunes, etc. while the empeg was not available (in car/in repair) which could later just be dragged back onto the unit when it became available again.

Perhaps a bit obsessive here?

-brendan

A rewrite in perl/QT!

Signed,
He-with-the-currently-borked-Java-install.

I have the code here somewhere; One of the BBS members did something to allow emulation of the server-side of the empeg protocol so he could use (j)Emplode to manage his DJing, and it strikes me that having jEmplode clone to something and having the something be external might be a better idea... sort of like the virtual ReplayTV which I'm told exists.

perl: maybe
QT: yuck

I did consider a perl module a while back. Shouldn't be that hard, but there are like 50 more worthy projects I'm not loving right now...

Hay Doug, haven't you asked for this before?

Rod

What's borked about your Java install? I'm sure we could get it fixed if you start a thread.

With the Karma<-->empeg syncing, add true sync support. If I add a song to a certain playlist, or change the tags on one device, sync this information to the other device.

I'm willing to do this with the requirement that both devices are on at the time, but an option to either delay sending the changes to one, or "resyncing" two playlists without sending all the data would be handy.

Hay Doug, haven't you asked for this before?

How did you find that post? I have looked for it several times since I first made it and could never locate it. I think I could add about three more "here"s to it by now...

tanstaafl.

Entered the words tanstaafl and backup as a search string.

Rod.

What's borked about your Java install? I'm sure we could get it fixed if you start a thread.

I doubt it. The only machine I have at home with an X server installed is a DEC Alpha with Linux. Sun hasn't released Java for this platform/OS for... um... a few years, to say the least, and I've misplaced the binaries I had. I've tried the open source java solutions, but they give me seg-faults in trying to load the Swing modules (I think).

I'm actually part way through building an x86 machine up, but my priorities got shifted part way through (there should be a post about that tomorrow evening, actually), and, since I don't actually have any new tunes that I want to upload to the Empeg, it's not that big of a concern for me at the moment.

I do appreciate the offer of assistance, though.

I have a huge list of emails of things I could fix/add in jEmplode, but I thought I'd post up here to get a (hopefully) smaller and more bang-for-the-buck set.

So did your plan work

doubt it. The only machine I have at home with an X server installed is a DEC Alpha with Linux.

Wow, ok, I thought you might have some form of a normal machine and just had a screwed up install .

So much for write once, run anywhere!

I still have functional IBM RTs, at least someone released a JVM for Alpha Linux.

Wow, ok, I thought you might have some form of a normal machine

Statistically speaking, you had the odds in your favour with that thought.

Man. I haven't used an RT since '90 or '91...

-brendan

I haven't run one as an AFS server in 5 years; Didn't want to deal with the Y2K issues in AOS 4.3. Nothing like a whole gig of space on an IDE disk...

Two wishes for jEmplode:

1. A "set playlist order" function that works (it doesn't seem to work for me).
2. Serendipity back -- even if it just displays recommendations and isn't integrated to a file sharing system.

FWIW,
jim

I dont know if its just me, but with v54 I cant seem to get setting Ignore as Child to work. I select it and then hit ok and it doesnt keep it, its back to off..

My top wishes for jEmplode:
0. Track Properties dialog boxes could really use 'Save and Next' and 'Save and Previous' buttons. If you're editing something for each track in an album, these really save a lot of time. I've grown addicated to them via Foobar2000 and Tag&Rename.

1. After pressing CTRL-L, the cursor should start in the "Name" field, and pressing Enter should save the new playlist. I'm tired of pressing CTRL-L, Tab, typing the name, and then Shift-Tab, Shift-Tab, Enter.

2. After creating a new playlist, the left scrollable pane should focus on the new playlist. Usually, you're going to do something else immediately after creating a new playlist.. and it's a safe bet to change the user's context to that new playlist.

3. non-Latin characters like ä and å do not display properly in jEmplode, but they work fine on the empeg itself.

4. I sure wish I could drag songs and folders directly onto a playlist in jEmplode, rather than having to open that playlist and drag things into the right pane. Fixing #2 in this wishlist would make this mostly a non-issue, though.

5. In the 'Columns' dialog box, it is strange to have to double-click a checkbox to activate or deactivate it.

6. I would like to be able to tell jEmplode to not report playlists as duplicates. If I'm adding a new album by Finntroll, it's mildly irritating to be told that 'Finntroll' is a duplicate. I may be the only one adding whole folders like this, though. Not sure.

7. Undo last action without reverting the whole empeg database.

Track Properties dialog boxes could really use 'Save and Next'

I think that emplode has this implemented by pressing 'Alt+3' instead of 'Alt+Enter' to bring up the properties dialog. It's similar to Winamp. Rio Music Manager does the same. Does JEmplode?

jEmplode doesn't ... So are the semantics that you select a single tune to edit, and Alt+3 edits the next one in the playlist? Does it work if you multiple select tunes?

No, you select a bunch of tunes, and rather than changing them all at once (like Alt+Enter), the Alt+3 properties dialog changes the first one when you press Enter, then displays the properties of the second one, then the third, and so on.

It's useful if you want to correct a bunch of track numbers in one go, e.g.

Ah .. I see. Thanks.

In reply to:

---

3. non-Latin characters like ä and å do not display properly in jEmplode, but they work fine on the empeg itself

---

They look okay in my JEmplode (v54, 2004-02-14) - I suspect your Java install is faulty. What do you see when you use these non-ASCII Latin characters? (From your examles, I see that "non-Latin" must be a typo/thinko - ä and å are in the "Latin-1 Supplement" block of Unicode)

In reply to:

---

7. Undo last action without reverting the whole empeg database.

---

Yes, yes! I'd like Mike to take his time and support multi-level do/undo/redo using the undoable Command pattern. (If he's feeling really nice, they could be logged to disk and, optionally, replayed after a JEmplode crash)

My absolute top wishlist is:

1. Don't add any new unstable and destabilising features! I like it to work

That said, a number of lesser wishes transpire up to my conscious layer:

• Write something useful to the window titles when transferring - apps such as xcdroast have the %-complete at the beginning of the title, so that when the window is offscreen, you can still get an idea of progress from a pager, task bar or other window list. At present, some of JEmplode's windows have no title at all.
• Get the "Total" progress bar correct on download. I tried download for the first time just now, and the total progress was stuck at 0% until the first track finished, then went to 100% for the remainder.
• Correctly set ctime on new playlists. At present, ctime is set on tracks, but not playlists. This makes it hard to find recently-created playlists.
• Animation editor would benefit from an option to upload the last frame as the static logo, as this is a common requirement. It would also be nice to override the frame count limit (with appropriate dire warning, of course). As I've mentioned elsewhere, I have a long animation that plays as TTS Clock starts, but I re-use lots of frames to keep the total size low. JEmplode limits the total framelist rather than the distinct frame count - these are two different maxima, for two different reasons. I can have a long (time) animation, but I still don't want to tread on the kernel.
• Separate "remote control" utility (perhaps also usable on its own?) to send player commands. At the moment we have play/pause on the toolbar, with three out of the four possibilities for playing FIDs; it would be nice to have some of the other commands there (particularly for those of us with dead remotes...) Are the usable commands the same as those available on the serial console?

Having a way of marking tunes as not in an album, and using that as a criteria for being in a soup or not. Then those of us with singles and albums could have album based soup views. Perhap there's an ID3 tag I could already use for this? I'll check it out when I get home.

Matthew

I use source="single" (for singles) and source="" (for other non-album tracks). But I don't use on-player soups, so I don't know how well this'd work for you.

In reply to:

---

They look okay in my JEmplode (v54, 2004-02-14) - I suspect your Java install is faulty. What do you see when you use these non-ASCII Latin characters? (From your examles, I see that "non-Latin" must be a typo/thinko - ä and å are in the "Latin-1 Supplement" block of Unicode)

---

My empeg is in the car, and I'm feeling lazy.. but I'll post a screenshot next time I have it inside. I assumed everyone had this issue. I'm using Java 1.4.2_03, and I've seen this improper-display quirk on every machine I've used jEmplode with. I might just be doing something wrong, though. I've always called these characters non-Latin, but I guess I've been using the wrong term.

Anyway.. If you would, could you try creating a playlist with some characters like this in it?
Älvefärd
Åsmund Frægdegjevar

Those are both album titles that don't display properly in jEmplode, but look fine on the empeg. (For me.)

A-umlaut, A-ring, and the AE ligature are all in ISO-8859-1 as well.

Here's a screen grab of me editing such a playlist.

What do you get? Do you get garbled strings, or do you get some kind of "blank" character indicating that the fonts your Java is using don't have the required characters? If the latter, you probably need to configure Java to use different fonts. I'd offer some advice, but I've never had this problem, and fonts are generally very platform dependent (you didn't say what platform you're using; someone else may be able to offer help if they have this information).

Mine is kinda stupid... but:

* - Having the Jemplode link at the top of the BBS, or the "Bleeding Edge Downloads" section of http://jempeg.cs.caltech.edu/ list the most recent release along with clear install instuctions for current users. I'm always digging through threads to get links and never really sure on what files need to be replaced or not..

I guess I frequent the BBS in "bursts" so I often miss out on things.

I don't think it's stupid at all, I agree completely and have mentioned this to Mike before. I'd like to see jempeg.org simply link the latest Jar, wherever it is. And just don't bother with the big installer packages, just make people install the Sun runtime and then grab the Jar. Couldn't be simpler.

I think that's my number one wish for jemplode, too - clarify the installation and distribution. I don't think the installers are necessarily a bad idea. They could be pretty useful in a few cases, like if there's any particular directory structure jemplode wants to see, or to make sure to get links in Windows start menus, or if you wanted to distribute a total package of all the jemplode/rmml jars. But, they are certainly problematic if they never get updated.

One other thing I miss is having the .app version for OS X. Sure, I can load the dev tools and use the MRJPackageBuilder or whatever it's called to figure out how to do it myself, but it was a lot easier when Mike did it for me.

Thanks for the screenshot. I'll capture one of the issue on my system tonight. I'm running Windows XP SP1 English, Java 1.4.2_03, Intel Xeon.
I don't get blank characters.. They are garbled, seemingly 'split' into two separate characters. I'm sure a screengrab will be able to explain it better.

In reply to:

---

I don't get blank characters.. They are garbled, seemingly 'split' into two separate characters. I'm sure a screengrab will be able to explain it better.

---

Sounds like Java is using UTF-8 for fonts, but the fonts are 8-bit, perhaps? I don't know much about Windows, and nothing about how its font mechanism works, so I can't actually be any practical help, I'm afraid.

I think others have working Java fonts on Windows, though. Anyone?

I don't know much about Windows, and nothing about how its font mechanism works

Windows (NT/2K/XP, anyway) uses UCS2 (or was it UTF16?) for output. For legacy applications, it has code pages, mapping 8-bit character references into UTF16 (or was it UCS2?).

Not all fonts have all of (or even useful bits of) the code points defined by Unicode in them.

Problems with Java and fonts are probably down to the JVM using the 8-bit font stuff, rather than the 16-bit font stuff.

Peter knows more about Unicode under Windows than I do -- he did most of the Unicode support in Rio Music Manager.

OK. Here's what it looks like on my system:
http://hellninjacommando.com/misc/broken_latin.png

I haven't used jEmplode in a while, so I'm working from memory. Apologies if it's been fixed or if I'm just wrong.

As I remember, jEmplode sorts newly imported playlists alphabetically by filename. For many people, this is not the correct order. Having jEmplode automatically sort new playlists by track number would probably be the best for the most people. But you could keep the old function by having a default sort-on-import setting. I'd default it to track number, but allow filename to be an option.

On a related note, many people at one point imported a bunch of albums and got the sort order wrong. It'd be nice if there was some way to resort a bunch of playlists at once instead of having to go to each one and perform a good number of actions in order to resort them. I can't imagine a good GUI for this, but the function would be well appreciated by some, I'm sure.

Edit: Uhh, nevermind.

Yes, that looks like you have ISO-8859.1 fonts that Java thinks are UTF-8.

Anyone know how to fix this on (IIRC) Windows XP?

Something that's been mentioned before, and would probably form a significant project, is to provide a (text) scripting interface.

This would, for example, allow users to iterate over all the playlists in the /albums playlist, and sort them in tracknr order (to use an example that's been requested recently).

Scripting would allow users to add this kind of stuff more easily than hacking the Java code, leaving you free to code more cool stuff.

There is already a plugin interface which would allow you to create your own java program and distribute a .jar file along with jemplode. It's documented here. I guess I would rather see Mike work on some other requests other than a scripting interface first (especially a comprehensive website with all relevant links, documentation, betas, etc.). The plugin interface would suffice in place of a scripting interface for now anyway.

But I agree about custom code/scripts for JEmplode, it would make things a lot more flexible.

Then someone needs to write a jEmplode plugin that implements a scripting interface.

What font does jEmplode use? All the major system fonts in WinXP contain the full set of European Unicode glyphs.

Wish from another thread:

That the Album soup view on the RioCentral uses the Position column to keep track of the CD track order, and doesn't just assign the positions based on alphabetical order.

I noticed this problem when using jEmplode v54 to copy tracks from the RioCentral to the empeg. Not sure if the empeg also has the soup ordering issue or not, will investigate later.

-brendan

I've been using jEmplode for what feels like forever for my empeg, and ever since I've started using it, I've always had one and only one real request - when downloading music back off of the player, and using {tracknr}, would it be possible to have jEmplode pad the field with a leading zero for numbers less than 10? It drove me nuts enough that I decided it would be better to force it by adding a zero manually ( {artist} - {source} - 0{tracknr} ) and deleting it manually from the finished files for tracks higher than 10! BTW, thanks for all you've done for the community, I sold several people on the Karma by letting them know that it DOES support hierarchial playlists via your program! =P

{tracknr:2}