In this entertaining review, Savanna takes us through her discovery of JuK, a new pearl in the treasure trove of KDE applications. Expect to see JuK ship with KDE 3.2 since it has already made an appearance in the KDE Multimedia module. Kudos to Savanna for taking the time to contribute the review and, of course, hats off to the developers of JuK!
A User's Perspective on JuK
by Savanna
"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. :)
I just want to say that I am using noatun with Hayes playlist for about one year now. I want to thank the authors for their work :)
And now I am trying Juk but it doesn't have the same advantage / disadvantage of Hayes. I will stay with noatun and Hayes for now but thank you to the Juk author too/
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.
BTW is it planned to have a meta-data view (artists, albums etc). That would be more interesting than playlists for many purposes, IMHO. Having a playlist for each album should not be neccessary.
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).
Yes, it was there as of about a week ago. I decided to refactor that code and so at the moment it doesn't work again, but I'm hoping to get that done by this weekend.
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
Actually really the slowness for adding directories is because JuK:
- 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.)
I wonder, do you have anyone using JuK over NFS?
Hayes delays as much as possible, and does as little as possible, and I still get NFS complaints.
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.
I do. I have my home directories and MP3s on NFS. Nothing special, a 700MHz P3 with a big disk and a half-gig of RAM. I'm using 2.4.20 with the kernel nfs server on a 100m switched network.
It's perfectly usable. I've been using this setup (with various hardware/disk changes) for many years now without complaint.
Worth noting that the iTunes interface is patented.
http://jriddell.org/patents.html iTunes patent details linked from that page.
Like all software patents the problem is probably best ignored until/unless they come after you.
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.
Just my 2c
-ian reinhart geiser
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. :(
Have you submitted a bug report? Scott's usually pretty quick to reply, and now that I've got a bit more free time I'm going to get back into JuK development.
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.
I notices that juk uses doubleclick to play a file - I thought KDE is per default single click?
So, what about
point: single select
point&drag: multi-select
shift/ctrl+click: multi-select
click: play
So far juk looks nice!
Bye
Thorsten
... is how easy it is to connect to various parts. Start Juk, open your favorite terminal, and type:
"dcop juk Player"
You get a nice list of available controls.
"dcop juk Player play" starts playback, and so on... It makes scripting a breeze. DCOP rules ! :)
2nd that!
/kidcat
let's see apple do something THAT open!
One word: AppleScript. It doesn't have to be open-source to provide a clean, scriptable interface, and AppleEvents (the interface) has been around since Mac OS 7.0 came out in the early 90s.
I don't really understand how it can "output" to both aRts and GStreamer. They are multimedia frameworks both, they do the whole thing apart from the user interface.
So, how does it use both?
Well, it doesn't use both at the same time. ;-)
Better said, if you have GStreamer installed when you're compiling JuK, you can choose between using aRts and GStreamer at runtime.
Couldn't aRts be made a gst sink (I think it already has been..), and can't gst be made an artsplayobject (I think it already has been)
Maybe, but I thought the main target group for GStreamer were those who do not have arts installed (or deactivated it, or have arts-incompatible hardware, or...).
or... prefer alsa for the speed.
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.
If my "User's Perspective on JuK" is negative and I reflect why in this topic, will my post be removed?
If the answer is no, why was my negative perspective removed? Last time I checked, I was not a trolling.
What's even more disturbing is that no-one has picked up on the fact that the dot was hacked today.
Why did this happen?
I even have the webpage source to prove it :)
s/hacked/ISP was screwed up/
I discovered Juk recently as well, it's a great app and simple to use. A big thanks to the authors. Can't wait for the lastest version in KDE 3.2.
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.
Regards,
Mystilleef
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!
You know something? I just tried this (umm, over nine months later. LOL.)
Kplayer is at version 0.5 now (from CVS) and I like it. It compiled fine and worked quite well, once I upgraded GNU automake as it required.
I guess I'll have to try Kmplayer too, at some point.
Maybe it doesn't make much sense to reply after this long a time, but on the other paw, let's hear it for archives :O)
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 do not think that the Arts backend supports it, but GStreamer should.
KDE's lack of FLAC support is the only thing keeping me using XMMS. This is something that needs to happen at the aRts level. If that happen, any media player in KDE should "just work."
Vote for bug #54394 in bugs.k.o - http://bugs.kde.org/show_bug.cgi?id=54394
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?
One day, I'll try Juk with gstreamer :-)
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*).
You're brilliant =D
Finally, I can use juk, an average of 4% cpu-time on a XP1800 for a sound server is still ridiculously high (mplayer can play mpeg4 videos using less =/ ) but at least it delivers
juk ownz u
Try this:
Go to kcontrol --> Sound --> Sound System --> Sound I/O --> Sound I/O method.
Change this to Threaded Open Sound System.
See if that helps at all.
smeat!
Thanks for your answers. I'll try these settings when I'm back home.
Hmm, juk runs fine over here, even if i compile something in the mean time.
rinse
What the hell is wrong with that site designer?! I'll be seeing green stripes for weeks. Oh the pain...
which site designer???