Tiny Core Linux
General TC => Programming & Scripting - Unofficial => Topic started by: Jakob Bysewski on December 09, 2010, 10:32:48 AM
-
Hi @ all,
I'm searching for a small but full-functional little media player prevalent for playing audio files / playlists.
Deadbeef does a good job but is a GTK2 application - does anyone know of a lightweight application for this use case?
If there is nothing applicable I'm thinking about writing a small, lightweight FLKT app in the spirit of MikeLockmoore's apps.
As almost everyone interested in playing media files will use mplayer, I may use the mplayer slave mode for playing (audio) files. So there is no duplicated functionality and no libs would be needed.
What do you think about this idea - would you like to use such application?
I know of moc and mpd but if I can have it; I like a lightweight GUI ;-)
-
You might wanna have a look at mp3blaster which has a console GUI.
Pleased with MPlayer-nodeps, but I have to admit, whenever I have the resources I do appreciate smplayer for easily fiddling with various advanced options.
If even some part of that functionality could ever be implemented based on FLTK, that might sure be interesting.
-
Using the slave lib from the Geexbox project instead of straight mplayer might be easier, even if it is one small lib more.
Oh, and XMMS is gtk1.
-
Hi @ all,
I'm searching for a small but full-functional little media player prevalent for playing audio files / playlists.
Deadbeef does a good job but is a GTK2 application - does anyone know of a lightweight application for this use case?
As almost everyone interested in playing media files will use mplayer...
I know of moc and mpd but if I can have it; I like a lightweight GUI ;-)
You might wanna have a look at mp3blaster which has a console GUI.
[...]
A few weeks back I created a private extension partnering gnome-mplayer gui v1.0.0 with mplayer. It is GTK2, but for my purpose low CPU usage was of greater importance than number of dependencies. I have no actual measurements of performance but empirically its CPU loading is extremely light - much less than Deadbeef and moc also mp3blaster when casually tested with the same audio sources.
-
curaga: You're right - the old legacy XMMS might be an option here.
As I stated I'm not searching for a console application - I know there are some of them, but if I go for console I'm content with mplayer ;)
mplayer -playlist <(find "$PWD" -type f)
That little snippet creates a playlist from the working directory and plays it in mplayer.
I don't need such an application build any kind of music database for me because I have my files organized in a very straigt forward way (Interpret/Album/*) and mostly listen to albums as a whole.
As others, I've got this fancy geek dream of a system which is full featured but very lightweight. Tinycore is a very great step in this direction!
I'm working with embedded linux systems and so I'm really stunned every time I work with a current Windows7 system which is almost 10 GB out of the box. If you let windows update work a bit and install MS Office you've about 20 GB filled with worthless crap.
Maybe a FLTK frontend to mplayer would be useful, but on the other hand - why has noone done this before?
It doesn't sound very hard to me to get some basic functionality working in little time.
Edit: typos
-
@Jakob: Go for FLTK!! ;D
-
Should make a "playlist" app. Only thing it should do:
1. run play 'current file in list' whenever the previous command returns
2. show this editable playlist in a nice interface
3. customize associations of apps to filetypes. Use the output of `file` to determine the type
Some more thoughts:
Allow multiple instances and playlists as filetype -> Recursive playlists for every filetypes you may imagine.
Organise your workflow with playlists so that you don't have to look at your TODO list, instead force yourself to switch to appropriate window and set the window title to current task. :D
-
Nice idea! Maybe we can do this, too...
For a media player I'd like to have it at least play/pause buttons so it won't be possible to just start another application and wait for it to finish.
-
Nice point. Stop would still be possible with kill, but if you want more complicated stuff like pause and seek it is more difficult.
Perhaps this kind of functionality could go into the "play" command I've mentioned.
Original idea is from Mr. Squeek: http://sqweek.dnsdojo.org/code/m9u/ (http://sqweek.dnsdojo.org/code/m9u/)
-
You may already be aware of these. I don't know if they have any value, but they might offer interest, inspiration or reference. As I stumbled upon them yesterday I have posted links. Both are described as "Simple Sound Player using FLTK 1.1.7. and Audiere library"
http://blueplayer.sourceforge.net
http://mp3dzone.free.fr
-
Thank you technosaurus ad SamK for your further input.
I have seen blueplayer and mp3dzone before but these projects were not capable of convincing me somehow.
I will have to think about this some more, but I may build at least a tiny prototype using mplayer as well.
What I find useful about an mplayer-based solution that it would be audio/video with no further effort - but I really don't know what would be the ideal solution for most users. Probabbly there is no such ideal solution and in the end it's all about personal taste ;)
-
I will have to think about this some more...
...I really don't know what would be the ideal solution for most users. Probabbly there is no such ideal solution and in the end it's all about personal taste ;)
Just a few thoughts...
By design TC is lightweight and speedy. Happily, one consequence of this (but as far a I am aware, not a primary design goal) is that TC is usable on older, less powerful hardware. The forum contains examples of people using TC to extend the lifespan of otherwise redundant machines.
More modern (higher spec) machines have the widest choice of applications in the TC repository. Conversely, older (lower spec) machines are better suited to the least resource demanding applications. The range of choices can be expanded by upgrading the hardware. The benefits of doing this might be worthwhile as legacy RAM and storage is generally available and relatively inexpensive. The situation is reversed as far as the CPU is concerned, therefore, replacing the CPU is done less frequently. This leads to the CPU often being the limiting factor in determining what the machine is able to run satisfactorily.
If you consider it important that your GUI application is usable by the broadest spectrum of TC users it might be worth searching for an outcome that produces the lowest CPU loading as a primary goal. Having established this, optimizing RAM and storage requirements can then be conducted. In this way you might be able to produce an "ideal solution" i.e. one that fits your design guidelines and also offers the greatest number of TC users the option to exercise "personal taste".
-
I don't agree.
I've got a 700MHz celeron here, and my shortage of RAM is more disturbing than my lack of CPU power. I watch xvid videos in full-screen and the only thing I could use some processing power for is h.264 video. But I don't think my graphic card supports high resolutions anyway.
You can't just put gigs of RAM in any old PC. There's always a limit. I don't even have a slot for RAM, it's soldered.
-
I don't agree.
It's not clear what you don't agree with. The ideas are general in nature, not intended to address specific user cases and therefore not meant to be seen as universally applicable in all circumstances.
I've got a 700MHz celeron here, and my shortage of RAM is more disturbing than my lack of CPU power. I watch xvid videos in full-screen and the only thing I could use some processing power for is h.264 video. But I don't think my graphic card supports high resolutions anyway.
You can't just put gigs of RAM in any old PC. There's always a limit. I don't even have a slot for RAM, it's soldered.
I also support equipment of similar specification (including RAM soldered to the motherboard) which run TC and carefully selected apps quite adequately. When using legacy equipment it is often a case of tailoring its use to the ability of the hardware to a greater degree than when using more powerful kit.
-
I don't agree that low CPU usage should be the "primary goal".
-
I wish legacy RAM were always inexpensive, it is often not at all, depending on the type...
-
I'd agreee, that RAM is something you'd like to have a lot of - but at least windows is demanding more and more CPU power, too :P
D'Oh! was hijacking my own thread here, but I like the discussion anyway ;)
What I had written here was going very off topic so I opened another thread for it here (http://forum.tinycorelinux.net/index.php?topic=8229.0) where we can possibly dig deeper into discussion.
-
(http://preview.shareapic.net/preview7/024164115.png) (http://www.shareapic.net/View-24164115-TC.html)
I wanted to test libplayer ;) Mplayer GUI, 10kb binary, plays only local music. Took maybe two hours (gosh I'm bored, can you tell?).
-
Nice one - where do I get it? ::)
-
Responded to your PM. Nowhere public though, I don't intend to continue it.
(http://i53.tinypic.com/167kxa8.png)
Stats as given by loc - 179 lines of code, 39 lines of comments, 42 empty lines. Size:
text data bss dec hex filename
8373 1024 320 9717 25f5 flmplayer
Also, one can't switch songs by clicking in the list currently. One of its many lackings ;)