dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: .LNK FILES IN ROCKBOX - an other approach

Re: .LNK FILES IN ROCKBOX - an other approach

From: Neon John <>
Date: Mon, 05 Dec 2005 23:26:38 -0500

On Mon, 05 Dec 2005 23:07:37 -0500, Ray Lambert
<> wrote:

>I don't believe M3U supports this, but I've been thinking about
>implementing some M3U extensions like this. Some ideas are:
> - an "include" directive to suck-in other play lists
> - the ability to name a sub-directory instead of having to iterate all
>the separate MP3s
> - embedded commands such as "play in shuffle mode" (perhaps anything
>that can be in a config file)
> - commands that populate the play list by querying the song DB or use
>regexp's to match songs on the disk (by filename or, possibly, by ID3 tag)
> - I'm sure there are plenty more ideas...
>Of course, these would be rockbox-specific and "extended M3Us" would not
>function with other SW.

There is a compatible way to do this. Winamp did it in the beginning.

m3u files support the comment field. Winamp put the additional
information inside a comment. Other parsers would simply ignore the
entries following, I believe, a semicolon or a pound sign.

To keep the rockbox parser from trying to execute other comments, I'd
preface each rockbox command with some magic, say, "rockbox:" followed
by the command.

Calling lists from lists and executing commands from within playlists
has been discussed before. Most all the users who commented wanted it
but so far no one has picked up the ball and run with it.

I'd particularly like to be able to execute sound settings from within
a play list. That way I could set up the player the way I want it for
that list once, place those commands at the top of the playlist and be
done with it. Now I have to go to the extra steps of maintaining a
playlist and a cfg file with the same name and go through the steps of
executing both.

It would be acceptable to me to limit or eliminate recursion to
preserve stack space. Just the ability to execute sound setting
commands would satisfy most users' needs, I think. Jumping to but not
calling (no return) another list would be adequate also, in the name
of stack preservation.

John De Armond
See my website for my current email address
Cleveland, Occupied TN
Received on 2005-12-06

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy