"Juk? What the heck is that?"
"You really should try it."
"But I use XMMS. I love XMMS."
"Well, give it a try. It's sort of like iTunes - a very nice playlist editor."
"Okay, okay...I'll try it out."

And so I did.

That is approximately how the conversation went a few weeks back on the #debian-KDE IRC channel. A person there named "grepper" told me to try it. Grepper knew one thing: I like pretty things. In fact, that is why I like KDE and have since around a year.

I first experienced it when I got a copy of Debian installed on my backup machine. From there, I booted up KDE and started to play around. In about ten seconds flat, I had one of the nicest looking desktops I had ever seen, and I was hooked.

I'm a user, not a programmer. I don't know what makes most things tick in Linux and KDE, nor do I really want to. Only recently, I learned how to upgrade to the latest CVS packages and install an Nvidia driver Debian package without seeing anything but a console line - and without freaking out because I couldn't see a mouse cursor.

Okay, I admit it: I'm a blonde who isn't a techie. I'm learning because it is kind of fun, but I'll only go so far. I know most people who will read this will probably chuckle because this is for a techie site, but it is worth noting that I am a user who has switched her desktop from Microsoft to Linux with KDE. That is a pretty big jump.

So when Grepper talked about my switching from XMMS (comfortingly like a windows application) to Juk (something like a Mac application with lovely KDE tidbits - from my point of view), he knew that I would do so reluctantly.

What a surprise!

Juk is easy. Juk is elegant. Juk is simple.

Juk is awesome.

It opens up as a simple collection list with a space for icons in the left to make more custom playlists with. Nice big icons at the top make it very hard to miss the start/stop/skip functionality of the program. It looks friendly, and it is. Big columns on the right tell you everything you need to know. A search function at the top lets you instantly select things live from the collection list to make your playlist the way you want. A nice little icon in the tray on the Kicker lets you control the application from there as well. You right-click on the left area, create new playlist, name it, and then drag-and-drop from your collection list to your playlist.

You don't need to do anything else: it is that simple.

Every time it opens, it scans your MP3/OGG/Music directories (which you add very easily whenever you like) for any new music files. Alternate light gray and white rows make spotting songs a breeze. A "jump to currently playing song" button on the bottom right makes it really easy to go to where you are, even while you are building more playlists and listening to another. A pop-up track announcement from the Kicker tray with a forward and backward skip button on either side comes up (if you want it) at the change of every song. I find this particularly useful. Right-click on the Kicker tray icon and you get a selection of the standard music player functions. Click on it with the left mouse button, and the entire program pops up. Another click minimizes it once more. There are no flashy player skins from outer space, or separate player displays. This is a simple program which doesn't need many bells or whistles.

Everything is big and friendly.

Big friendly icons make for happy users.

I was hooked. In fact, I was so hooked that after I got the stable version from orth's CVS debs, I switched everything to Juk and no longer use XMMS.
Now, I do miss the XMMS skins, and I had quite a collection, I'll tell you. And I miss the plugins feature for falling asleep and waking up with music - but wheels assures me that this is going to be coded in relatively soon so I'm no longer worried about that.

Other than that, it is a dream come true. There is something to be said for a Mac-design where things are supposed to be friendly and simple for regular users. Juk hits that on the head. I love XMMS but it was sort of tiny on my screen and making a good set of playlists accessible was, at times, kind of annoying. I also like Noatun, but I have some issues with it at the moment - though with the Hayes playlist feature, it was as close to Juk and about as friendly and intuitive as I've ever seen it before (and does have its own very nice merits).

But Juk is...perfect. Well, so far. It screams: "non-coders will use me happily", and that is a good thing.

I love KDE because it is easy to use. Juk follows that example and reminds me, once again, why I run KDE in the first place.

Comments

I've seen a lot more people switch to music players that aren't winamp clones (xmms), recently. The move from winamp/xmms/audion, to itunes/juk/rythybox is great-- the former is way harder to use than the later. I think most people still use xmms because they are simply used to it and winamp.

Well, they are used to it, that's right, but I think, it was mostly performance reasons. I used a half year ago an AMD Athlon k7 500 (slot-a :) ) with epox board and had win xp installed. This OS was not very fast on my system. what should I do? Yes, install winamp, it executes fast and plays almost instantly. Then the board wished no more to work. Now I have an asus with athlon xp 2200 (is about 1900MHz) and now I use itunes and love it, because I have got enough performance to use hugher programs. so I do not wonder of the new trend. :)

There is also something to be said for a playlist player like JuK to be packaged, easily available and ready to go in KDE instead of requiring advanced plugin knowledge of Noatun from the user... JuK really has a chance to shine here.

IMHO, such a meta-data view should exist at the konqueror level... a search-folder like in the next kmail, but for the filesystem, sothat the result can be used in all kde applications (open file dialog for exemple).

i tried both noatun+hayes and juk, and i still prefer hayes (altough juk is nice) (http://www.freekde.org/neil/hayes/hayes.png), but that is probably a matter of taste. I really like the filesystem-based concept of hayes..

juk also has some problems that need to be sorted out: 'add directory' takes a loong time here (it takes more than a minute, xmms loads the same directory in a couple of seconds). xmms only loads id3 tags when they are shown, maybe that has something to do with it (but i don't think its the only reason). but kde3.2 is not released yet offcourse

- does a recursive scan of that directory
- adds playlists and audio files
- reads all of the tags at once and collects more information than i.e. XMMS
- optimizes for fast loading by doing all of the dirty work up front

Basically the idea behind JuK is to make the thing that you do infrequently (adding files) slow and make the things that you do more often (i.e. start the program) fast. As such, it caches all of the meta information and only updates it if the file is modified. I can load up my playlist of about 2400 files in about 3 seconds -- and aparently there are some people (hi Ian) using JuK with up to 50,000 items. Also I've tried to ensure that the GUI stays responsive while loading files so that JuK can still be used while loading files.

There will be some optimizations before 3.2 (I won't go into the details unless requested), but I would expect things to get 2-3x faster, not say 10-20x.

As compared to Hayes the main difference is that JuK is playlist / collection oriented and assumes that playlists and meta-data to be the primary way of organizing music; Hayes on the other hand assumes that the file system is being used for this. They're both valid takes on the problem and cater to different folks.

(D'oh, I guess I blew the cover; yes, JuK is for geeks too, though a significant motivation is keeping the interface simple and hiding the details that I'm talking about.)

It's not significantly worse over NFS on a 10 MB/s LAN than on the local file system (Daniel and I did a good bit of testing with this.). The initial scanning is slow -- but after that on load JuK just stats files on start up (and even that is delayed until after the GUI is up and usable in CVS). With stating files over NFS, your bottleneck is still a hard drive's seek time somewhere.

So while if you're loading 10,000 items over NFS it won't be exciting, you only have to do it once. After that you can read all of the items back in a few seconds.

Ian, who to my knowledge has the record for biggest collection in JuK (50k files) is on NFS.

See now thats the funny thing, as someone who has actually _used_ iTunes and Juk, they are not the same thing. In a static screen shot they may look the same, but they act VERY VERY different. Try to run them side by side and you will see :) I mean just because KDE has windows dosent mean its a copy of GEOWorks :)

Lets stop compairing Juk to iTunes... Its probibly the same as compairing Juk to Windows Media Player.

True, but I think the main components of the iTunes interface that can be reasonable supported as new and unique are the artist/album drop downs, and it's unique device integration capabilities. Also it's (now) media purchasing interface. However, playlists in a column with a list of tracks in the other window is hardly unique. Just my $0.02. =)

I bumped into Juk yesterday when I was trying to get a decent playlist manager. Compiled and installed it. It searched and added the files to the playlist, but when I clicked on the songs, KDE gave error. I don't know what is the problem with it. It did not even form album lists. :(

Just a "meeeee toooooo", but Juk is so much better than anything else on Linux for messy people like me who have songs spread about everywhere, not just in nice neat file hierachies. Id rather just throw the files at Juk and let it sort things out for me. "Search All Visible" is simply brilliant, I dont even have to think to get the songs I want, I just type whatever comes into my head first. Forget skins, they would only get in the way.

There is a sink for arts. I don't think anyone is using it though... JuK output with GST is currently hardcoded to OSS.

GST could be made an artsplayobject, but why bother? For pure playback it does not have any features that Xine does not have... GST shines when you do more complex things. One possibility that I am thinking about is to multicast the sound that JuK plays so other systems in the network can attach to it.

I tried Juk today, but my experience with it wasn't potent enough to warrant a change from Noatun. I've never really been a mouse and click person, so perhaps Juk isn't for me to begin with. I've grown accustomed Noatun's 'global' keyboard combinations, skins and inumerable plugins(hayes playlist inclusive). Juk is great, but Noatun is better. And Xmms is just old.

But for Noatun and aRts control, kde multimedia is an embarrasment, an abomination and an abberations. I hope exciting changes are been made to Noatun for KDE-3.2 because I don't yet find Juk as worthy replacement. I also hope (K)mplayer becomes KDE's default media player. It will be interesting to integrate Noatun, Kscd and K(m)player into a single application.

Otherwise, kde multimedia is just a joke. Are there any exciting features we can look forward to in KDE-3.2, with regards to kde multimedia? A thumbs up to both the Noatun and Juk team. To the kde multimedia team; we support you but we are yet to see the best from you guys.

Note kmplayer is no mm framework like arts, just a frontend for mplayer/xine/ffmpeg for people how know what they are doing (and have broadband internet). Its main focus is playing inside konqueror/khtml. So I don't expect kmplayer becoming the default media player ever.

I very much like Kplayer. Like Kmplayer it is a frontend to mplayer, but its interface rocks! Even though it is only at version 0.2, it is very stable already and has a great GUI, check it out: http://kplayer.sourceforge.net. There is no playlist support yet, but for films it's just great!

Just to be clear -- a lot of people are trying the CVS version and coming away saying, "Hey, this isn't stable at all. This isn't release quality."

Simply put, you're right. It's not. That's why it hasn't been released. JuK has been under heavy development for the last several months -- there have been thousands of lines of changes and additions to JuK's code since 1.1. There are crashes and bugs that I am well aware of and will get to before the next release with KDE 3.2, which is many months away.

That said, if you're using the stable version - 1.1 and still experiencing problems, *please* report them. JuK 1.1 has very few known bugs; If more are reported I'll backport my fixes and release a 1.2.

HEAD is where a lot of the cool things happen, but at this point in the release cycle (several months before we even hit the feature freeze) things will be broken on a regular basis; this is just the nature of software development.

I haven't noticed it in any of the feature lists, but a requirement for any media player for me is the ability to play FLAC files. I'm sure other people have other formats they want to play - does juk have input plugins?

I would love to use Juk, or any arts based player. If it wasn't for the sound click when I either:
- start a compile.
- switch virtual screen.
- in fact, do anything other than staring at the player window (yes, this is a troll)

My box is quite decent (1.2Ghz 256Mhz) and XMMS plays audio without any problem. I have tried to increase the arts buffer, but it didn't work. Any interesting settings someone want to share?

you should enable "realtime priority" in KControl, this ends this problems. But maybe you also have to set the '+s' bit of the arts executeable; turn the error messages on (also in KControl) to find this out.

artswrapper is the binary to set the bit on.
After that + enabling realtime priority it's quite hard to get arts playback to skip except if you have IRC problems or you try playing files from a hdd that is currently busy with other things (you know, buffers aren't infinite *g*).