From: Yusef Napora <ynapora_at_hotmail.com>
Date: Tue, 25 Jun 2002 22:27:45 -0400

Hey,

   I've got next/previous track working, but the code is too big to post,
and i've never used diff before, so you'll just have to take my word for it!
  I do plan to send someone a tarball soon so they can look it over, commit
it, etc. Til then, you can get a binary at my rockbox page:
http://www2.emji.net/ynapora/rockbox/ there's also a couple screenshots, and
a list of the changes made to the source.

   I also changed the wps implementation around to use a separate thread,
because i thought it would be neat if the mpeg code could tell the wps code
when the currently playing file changed. After debugging that for a while,
i checked out the web site's recent cvs changes (nice addition to the site,
btw), and found that zagor had already made a change where the wps refreshes
every second, which is probably the saner way to do the same thing. So,
anyway, i've got next/prev and a new look for the wps screen (with a
separate info screen for stuff like bitrate, etc).

- Yusef Napora


>From: "Lee Marlow" <lmarlow_at_yahoo.com>
>Reply-To: rockbox_at_cool.haxx.se
>To: <rockbox_at_cool.haxx.se>
>Subject: RE: WPS implementation
>Date: Tue, 25 Jun 2002 18:41:18 -0600
>
>Just thought I'd add my two cents (4 lines of code, in this case) for
>WPS. The one thing that keeps me from using rockbox fulltime, besides
>battery life, is being able to skip to the next track in a playlist.
>So, here is my little patch for the JBR20:
>
>Index: wps.c
>===================================================================
>RCS file: /cvsroot/rockbox/apps/wps.c,v
>retrieving revision 1.9
>diff -u -r1.9 wps.c
>--- wps.c 25 Jun 2002 17:44:05 -0000 1.9
>+++ wps.c 26 Jun 2002 00:28:43 -0000
>_at__at_ -165,6 +165,18 _at__at_
> global_settings.volume = 0;
> mpeg_volume(global_settings.volume);
> break;
>+
>+#ifdef HAVE_RECORDER_KEYPAD
>+ case BUTTON_LEFT:
>+ // play previous in playlist
>+ break;
>+ case BUTTON_RIGHT:
>+ //play next in playlist
>+ mpeg_play(playlist_next(1));
>+ //sleep(HZ);
>+ //id3 = mpeg_current_track();
>+ break;
>+#endif
> }
> sleep(HZ/20);
> }
>
>
>I hope that's the right format. This is my first time coding C and
>contributing here. Unfortunately, I couldn't get the WPS to update with
>the new track info, but I'll leave that as an exercise for the more
>capable.
>
>Lee
>lmarlow_at_yahoo.com
>irc: mecraw
>
>-----Original Message-----
>From: owner-rockbox_at_cool.haxx.se [mailto:owner-rockbox_at_cool.haxx.se] On
>Behalf Of Daniel Stenberg
>Sent: Monday, June 24, 2002 4:17 PM
>To: rockbox_at_cool.haxx.se
>Subject: Re: WPS implementation
>
>On Mon, 24 Jun 2002 jerome_at_geekrox.com wrote:
>
> > 1) playlists force back to the directory browse after the first track
> > loads. I have yet to find which part of the code causes this.
>
>Heh, yeah it looks a bit silly! ;-)
>
> > 2) I still need to hook into the "on" button or something to allow use
> > toggle of WPS.
>
>On the Recorder, one of the functions might be a good choice.
>
> > 3) Despite the "QUICK hack" comment, I still used peek_next_track to
> > determine display time. Thus the screen gets modified before the
>actual mp3
> > plays.
>
>We can't use peek_next_track() for that information. It is used for mp3
>buffering, not for actual playback info.
>
> > The first two are easy enough, but the third brings up questions of
>the
> > future for WPS. A couple things I've been thinking....
> >
> > 1) Improve the interface between mpeg & peek_next_track. Since it is
>a
> > "QUICK hack," a "fix" is required anyway.
>
>The interface here is that the mpeg thread is supposed to read the id3
>info
>from the song it plays. The WPS code could then read the information
>freely.
>That's the plan at least. I haven't yet tried to add this myself.
>
> > 2) Insitute WPS into it's own thread to take events when to display or
>give
> > way to the another mode (like dirbrowse). Possibly this fits into
>number
> > 1, but is a bit more involved.
>
>I'm not sure this needs to be a separate thread. In fact, having it as a
>separate thread from the UI thread might cause more problems that it
>solves.
>
> > So any help is appreciated. I haven't submitted any code, but would
>be
> > willing to tar ball anyone on the list who requests.
>
>I prefer a diff -u output! ;-)
>
>Uh, btw, *great* work!
>
>--
> Daniel Stenberg -- Rocking the box => http://bjorn.haxx.se/rockbox/


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
Received on 2002-06-26