Distribution: Debian testing/unstable
System: Linux 2.4.3 i686 unknown


Description:
If it's running, use esd for sound playback.  Also, if esd isn't running
locally, but the Espeaker variable is set, use that instead of trying to
play locally.  If Espeaker is set, but the deamon isn't running wherever
it's supposed to be running, give user a list of alternate playback
options (retry, local esd, remote esd, /dev/dsp, /dev/audio, alternate
file/device)

These all come from a Debian user, who goes by the nickname of xsdg.

-   The Home and End keys should be used for (play|file|whatever)list
    navigation.  I am not sure if they are used elsewhere, but this is the
    most intuitive use of these keys.

-   If it's running, use esd for sound playback.  Also, if esd isn't running
    locally, but the Espeaker variable is set, use that instead of trying to
    play locally.  If Espeaker is set, but the deamon isn't running wherever
    it's supposed to be running, give user a list of alternate playback
    options (retry, local esd, remote esd, /dev/dsp, /dev/audio, alternate
    file/device)

-   There should be a "reverse t" feature to step backwards through mixers.
    Optimally, this would be some modifier+t.  This feature should be
    present for the "T" keymapping as well.

-   Allow the user to press a key to start playing at the song under the
    cursor, and continue playing through their playlist in the method that
    their options define.

-   When I play a Joint Stereo song, followed by a normal Stereo song, the
    song type display displays "Stereotereo" instead of "Stereo".

-   There should be an option for the cursor to follow the currently-playing
    song.  However, if the user moves the cursor manually, it should stop
    this behavior until some key is pressed to jump to the currently-playing
    song.  Additionally, there should be a key to jump to the
    currently-playing song, but _not_ follow it.  Check out ksmp3play for
    the gist of it, even though it doesn't implement that last feature.

-   mp3blaster should be able to stop after the currently-playing song, stop
    after the currently-playing song by using a fadeout, or fadeout and stop
    "right now."

-   mp3blaster should be able to fade into songs, fade out of songs, or
    crossmix.  For bonus points, it should be able to fade in/out or
    crossmix individual channels in a song.  For more bonus points (:oP) it
    should be able to swap the (left | center | right) channel with the
    (left | center | right) channel (where channel 1 != chanel 2 :o)  The
    volumes and delays (on the fades) should be variable.

Of course I do not expect anyone to modify mp3blaster because of his
requests, but, since he filed bug reports for these, I need to at
least forward his requests and tag them properly.

Thanks,
Carlos.

Carlos Laviola wrote:
[snip requests]
Well, some of those make sense. Others just scream 'make a patch and mail
it to me!'. Whatever's left is either out of scope (cross-fading, who'd
use mp3blaster for that? What's next, someone's going to ask for
beat-sync cross fading! (yes you may send a patch that does this :))

But my biggest question is: Why are such requests not auto-forwarded to
the maintainer? There are many distributions and OS's that have mp3blaster
in their ports/package system, but none of them actually (auto) forward
feature requests or bug reports. It does happen on occasion, but often
I have to keep track of this myself. It's not overly difficult,
but it's a lot of work and my resources are limited too of course.
I'd say, auto-forward all such input to the mp3blaster-devel list if that's
possible in the future.

Kind regards,
Bram