April 23, 2002 saved for the future to see... :-)

git-svn-id: svn://svn.rockbox.org/rockbox/trunk@200 a1c6a512-1295-4272-9138-f99709370657

2 files changed, 1013 insertions, 0 deletions

diff --git a/www/irc/index.t b/www/irc/index.t
index 0de43cd2be..76814ace6b 100644
--- a/www/irc/index.t
+++ b/www/irc/index.t
@@ -20,6 +20,7 @@ for later reference.
 <li><a href="rockbox-20020417.log">April 17, 2002</a>
 <li><a href="rockbox-20020418.log">April 18, 2002</a>
 <li><a href="rockbox-20020419.log">April 19, 2002</a>
+<li><a href="rockbox-20020423.log">April 23, 2002</a>
 </ul>
 
 #include "foot.t"
diff --git a/www/irc/rockbox-20020423.log b/www/irc/rockbox-20020423.log
new file mode 100644
index 0000000000..153c700e06
--- /dev/null
+++ b/www/irc/rockbox-20020423.log
@@ -0,0 +1,1012 @@
+**** BEGIN LOGGING AT Tue Apr 23 07:54:50 2002
+
+--> Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox
+--- Topic for #rockbox is Open Source Jukebox Firmware - http://bjorn.haxx.se/rockbox/
+--- Topic for #rockbox set by Zagor at Fri Apr 12 15:45:52
+>nickserv< identify nintendo
+-NickServ- Password accepted - you are now recognized
+--- services. sets mode +e Bagder
+-MemoServ- You have no new memos
+>chanserv< op #rockbox
+--- ChanServ gives channel operator status to Bagder
+<adiamas> man o man.. am i behind.....
+<adiamas> heheh
+<Bagder> hey
+<adiamas> hows it going?
+<Bagder> just fine
+<Bagder> I finally got my usb2 working, then everything must be fine doesn't it? ;-)
+--> Linus (~linus@labb.contactor.se) has joined #rockbox
+<Bagder> morning
+<Linus> Morning!
+<Linus> Man, I just went to bed... :-)
+<Bagder> ugh
+<Bagder> :-)
+<Linus> Fells like it anyway
+<Linus> feels
+<Linus> Sleep is overrated
+<Bagder> indeed, you do too little good work then ;-)
+<Linus> But I do no harm either. :-)
+<Linus> The threading kernel rocks!
+<Bagder> you've ran it on target now?
+<Linus> Yup. Yesterday evening.
+<Bagder> *neat*
+<Linus> It wasn't *that* hard. Half of the SH registers are scratch registers.
+<Linus> The PR was the tricky part.
+<Linus> I hate that gcc doesnt inline functions unless you optimize with -O.
+<Bagder> right, there should be some way to force that
+<Linus> I tried a few preprocessor tricks but it messed up my stack frame.
+<Linus> The next thing is a timer tick to sleep() on.
+<Bagder> yeps
+* Linus goes to fetch a cup of coffee
+* Linus says "aaaaaah"
+<Linus> I modded Zagors serial port yesterday. No contact. :-(
+<Bagder> oh pain
+<Linus> I wonder how many Player users have tried the remote control.
+* adiamas quotes "rest is for the weary and sleep is for the dead"
+<Linus> Good morning!
+<adiamas> i ment to ask.. was there a decision reached about what type of filesystem we will be using?
+<adiamas> bah.. gettin ready for bed
+<Linus> FAT32.
+<Linus> Or have I missed something?
+<adiamas> have we implimented open() and stuff?
+<adiamas> for file opens and closes.. etc
+<Bagder> no
+<Bagder> but we intend to
+<Bagder> I mean, follow the standard file paradigms
+<Linus> That doesn't really depend on what filesystem we use.
+<Bagder> Linus: do you know how to see what device the Archos appears as under Linux? I mean for /dev/sdaX...
+<Bagder> is that just the scsi devices enumerated?
+<Linus> Not a good way. The storage driver outputs the string "sda1" (or whatever) in the kernel log.
+<Bagder> right
+* Bagder documents some of the USB madness
+<Linus> Yes they are enumerated. So the first storage device you plug in gets sda1, the next gets sdb1 and so on.
+<adiamas> right, but ive never written anything that low level.. i mean for file IO...
+<Linus> Björn may have som info about that...
+<Linus> I mean the USB madness.
+<Bagder> yes
+<Linus> The file I/O API will most likely look like POSIX
+* Bagder found some rather good (small and clean) id3-tag code he'll dissect today
+<Linus> You mean version 2?
+<Bagder> both v1 and v2
+<Linus> Nice. It's a pity that ID3 V2 tags arent small and clean...
+<Bagder> hehe
+<Linus> Some people should reaaly be shot
+<Linus> Why do I always type double "a" when I want double "l"???
+<Linus> I guess it's a matter of brains size.
+<Bagder> :-)
+<Linus> (and there was an extra "s" after "brain" ...)
+<Bagder> we'll need a seek for the id3 tag stuff to work
+<Linus> Of course
+--> Zagor2 (~bjst@labb.contactor.se) has joined #rockbox
+--- Zagor2 is now known as Zagor
+<Bagder> morning
+<Zagor> morn
+<Zagor> of course you're supposed to start the archos before you load the modules. ;-)
+<Bagder> you know why?
+<Zagor> yeah, that's the timing issue they mentioned. the recorder takes too long to initialize
+<Bagder> that's probably also why you can't have it in the kernel, you're forced to use modules
+<Zagor> yes
+<Bagder> Zagor: I have a first id3 code approach
+<Zagor> ah, nice!
+<Linus> Zagor: why does it work for you?
+<Linus> (the recorder)
+<Zagor> because I've always done what you just discovered
+<Zagor> I just never thought it was special
+<Linus> So you had it working out of sheer luck!
+<Zagor> well, sort of yes. it's a habit I established since writing the isd200 driver, to always load usb-storage last
+<Linus> Grrr
+<Bagder> Zagor: I've tried to summarize the Linux/USB/Archos stuff in a little HOWTO
+<Bagder> I'd be glad to get some Player info added too
+<Zagor> ok, good.
+<Bagder> should I add it to the www module somewhere?
+<Zagor> sure, call it usb.t
+<Zagor> or usb-howto
+<Bagder> in docs/ ?
+<Zagor> no, in the www root
+<Bagder> ok
+<Zagor> docs is for data sheets
+<Bagder> added, it is plain ascii for now 
+<Zagor> ok
+--> wavey (~wavey@dlan1431.dircon.co.uk) has joined #rockbox
+<wavey> good goddamn morning to y'all
+* Bagder waves
+<Zagor> hi there
+* wavey badgers
+<Bagder> reading v1 and v2 tags mostly working now
+<Bagder> even estimates song length in seconds
+<Linus> Rock'n'roll!
+<adiamas> wavey.. any particular reason you have a dir named after yourself in the CVS?
+<wavey> Bagder: excellent!
+<wavey> ad: it's where I'll be developing stuff
+<adiamas> hehe k :)
+<adiamas> hehe tetris.. i love it.
+<wavey> do we have any generic data structure code yet?
+<wavey> i wanna toy with playlist impl ideas
+<adiamas> no.. what do you need?
+<wavey> lists, stacks
+<adiamas> hmmm and it's not c++ so stl is outta the question...
+<wavey> yus
+<adiamas> i could hack you out a quick list class if you want...
+<Zagor> we have a list class
+<wavey> heh
+<wavey> so could I 
+<Zagor> just not in the cvs
+<wavey> :)
+<wavey> it's about reuse :)
+<Linus> a "class"?
+<adiamas> hehehe i know :)
+<Zagor> not class, file :-)
+<adiamas> nods
+* adiamas has c++ terms on the brain.
+* Zagor is polluted too
+<wavey> apparently glib has all that inside it
+* wavey investigates
+* Bagder all of a sudden realizes that now he can check the total playtime of his entire mp3 collectin using his new tool ;-)
+<Zagor> hehe
+<Bagder> Title: Forever Young
+<Bagder> Artist: Alphaville
+<Bagder> Album:  Forever Young
+<Bagder> Length: 225 seconds
+<Bagder> Bitrate: 128
+<Bagder> Frequency: 44100
+<adiamas> Bagder: you have source up yet?
+<wavey> bad: you decoded the file according to the spec, or you stole the source from elsewhere?
+<Bagder> I stole it
+<Bagder> from Ample
+<Bagder> GPLed
+<wavey> stole in the best possible way, of coiurse :)
+<adiamas> nods
+<wavey> heh yeah
+<adiamas> what about id3?
+<adiamas> you said you ahve id2 and 1 down yes?
+<Bagder> yes
+<Bagder> id3v1 and id3v2
+<adiamas> nice little command line util i pulled off of sf the other day...
+<adiamas> got ya..
+<adiamas> been hacking on that...
+<Bagder> now, I'll make the estimated time to not use floats...
+<adiamas> so before i continue playing.. is there any use to the little battery display i tosed up?
+<Linus> Daniel: how to remove all TABs in a file in emacs?
+<Bagder> untabify
+<Zagor> adiamas: i think it's useful, as soon as we get a UI going
+adiamas adi|atWork <Bagder> adiamas: you should port it to use the proper lcd API though
+<adiamas> nods
+<Linus> Bagder: Yeah right. Any better idea?
+<adiamas> thats what i was talkin about...
+<adiamas> in emacs? no idea.. vi its easy.
+<Bagder> Linus: "Convert all tabs in region to multiple spaces, preserving columns."
+<Linus> "in region" Ah.
+<Zagor> vi is never easy :)
+* Zagor ducks
+<adiamas> hehehe
+<adiamas> bah..
+<adiamas> :%s/<your tab char>/ /g
+<Zagor> that just replaces it, then you have to reindent your whole source
+<Zagor> untabify does it right
+<wavey> glib looks reasonably complete. 
+<Zagor> reasonably slimmed, too?
+<wavey> need to check the way it allocates memory 
+<wavey> we using malloc?
+<Bagder> if I wanna add test code for the id3 stuff, should I create a new dir in test/?
+<Zagor> not if we can avoid it
+<Zagor> Bagder: yes. test/bagder or test/id3
+<wavey> what i figure
+<wavey> d
+<Bagder> ok, will use test/id3
+<adiamas> did we ever straighten logging out?
+<adiamas> like what funcst were using?
+<Zagor> logging?
+<Bagder> for simulators etc
+<adiamas> nod
+<Linus> debugf()?
+<Linus> I think you could use the same API as debug.h
+<Zagor> glib is a MONSTER
+<Linus> The glib lists require malloc()
+<Linus> Well, most lists do... :-)
+<Linus> I suggest that we use my list functions for lists. Daniel and Björn know what I'm talking about.
+<Linus> I can commit them in a minute.
+<Bagder> sure
+<Zagor> ok, I admit:
+<Zagor> we need a subdir :-)
+* Bagder chuckles
+<Zagor> for all standard code such as lists etc
+<Zagor> those will quickly grow to many files
+<Linus> OK here we go. Here comes the "common" directory! :-)
+<Linus> Aaaaaah!
+<Zagor> no! not "common" aaaaaaaaaaagh!
+* Linus fears the "common" directory
+<Zagor> i still (stubbornly) think it's a good idea to have the current code in a single dir, though
+<Bagder> I hope it is fine to commit the id3.c source even though it still contains a few malloc?
+* Linus wants to brain wash Zagor
+<Zagor> sure
+<Linus> So what shall it be? A "common"?
+<adiamas> would you rather call the lower level funcs that malloc references?
+* adiamas doesn't understand the problem about malloc
+<Zagor> i would rather avoid dynamic allocation alltogether, as far as possible
+<Linus> No. it's just allergy to dynamic memory.
+<Linus> adiamas: Say after me "memory leak" :-)
+<adiamas> say after me: code properly
+* Bagder committed his id3 code
+<Bagder> a single c file
+<Zagor> it's not just memory leak problems. it's memory use predictability
+<Zagor> we have *VERY* tight memory requirements, so control is of the essence
+<adiamas> memory use predictability?
+* adiamas figured it was that..
+<Linus> How much memory is used when
+* Zagor is not always too fluent in english ;)
+* Linus is waiting for a response about the "common"
+<Zagor> do we have a bid for a better name?
+<adiamas> nah.. i think that works...
+<adiamas> cause im against "stuff_that_everyone_is_probably_going_to_use_kept_in_one_spot"
+<Zagor> so am I. but I don't like the name "common" :-)
+<PsycoXul> 'shared'?
+<adiamas> we can always rename later
+<adiamas> id rather common over shared
+* Zagor grudgingly accepts 'common'
+<Zagor> mumble mumble
+<Linus> ALOOS (A Load Of Old Shit)?
+<Zagor> ALOUS (A Load Of Useful Shit) ?
+<adiamas> okay.. battery.c in
+<adiamas> use it whenever you want, or ignore it.. whatever
+<Bagder> we have a few other widgets in Gary's code too
+<Linus> apos (A Pile Of Stuff)
+<adiamas> poe
+<adiamas> (pieces of excriment)
+<Zagor> poetic :)
+* adiamas winks
+<adiamas> oh.. oh.. how about...
+<adiamas> "stuff"
+<adiamas> hehehe
+<Zagor> haha
+<Linus> A winner
+* adiamas bows deeply
+<adiamas> and my mothe said i would never amount to anything...
+<adiamas> s/mothe/mother
+<adiamas> what other widgets are in garys code?
+<Bagder> "Draw battery level indicator" ;-)
+<adiamas> lol figures :)
+<Bagder> progress bar
+<Bagder> horizontal slider
+<Bagder> vertical slider
+<adiamas> perhaps a "widgets" file would make more sense...
+<Bagder> "Draw function key labels at bottom of screen"
+<adiamas> is gary's code in the cvs yet?
+<Bagder> no
+* Zagor has a revelation
+<Zagor> "drivers"
+<Zagor> :)
+<Zagor> for all the current stuff
+<adiamas> hmmm that don't seem right...
+<Zagor> heck, I'm man enough to admit I'm wrong
+<Zagor> sometimes I am, anyway ;)
+<adiamas> Bagder if you want to either a: mail me or b: submit to the cvs, ill try and update to current lcd code
+<Zagor> adiamas: you can find it on the web page
+<Bagder> Zagor: I think it might be a hit
+<adiamas> where?
+<Zagor> http://bjorn.haxx.se/rockbox/gary/
+<wavey> found a nice non-float random number generator
+<wavey> tiny too
+<adiamas> that works.
+<wavey> with references to knuth throughout the code :)
+<adiamas> would it make more sense to have a 'widgets' file that has this sorta stuff in it?
+<Zagor> adiamas: don't put everything in the lcd.c, though
+<adiamas> right
+<Zagor> yes
+<adiamas> k
+<Zagor> maybe we should even have a 'ui' directory
+<Bagder> wow
+<adiamas> hmmm don't think we need that yet...
+<Bagder> Zagor's in the mood today ;-)
+<Zagor> hehe. it's either 0 or 1, you know ;)
+<adiamas> we cold always create it later when the need suits..
+<Zagor> yes
+<Linus> I have sinned
+<adiamas> ?
+<Linus> I added a "common" directory
+<Zagor> you mean apart from toasing my jukebox? ;)
+<Zagor> toasting
+<Linus> Prove it. :-)
+* adiamas runs around screaming that the sky is falling
+<Zagor> hehe
+<Zagor> we'll have a mailreader.c before you know it...
+<wavey> :)
+<wavey> netscape syndrome
+<adiamas> lol
+<Zagor> "Every software evolves until it can read mail"
+<wavey> and it won't be mailreader.c, it'll be mail/Imap.c mail/pop.c mail/smtp.c
+<wavey> because i'm committing them now ;)
+<Zagor> hehe, right
+<PsycoXul> heh
+<adiamas> well the hell with you guys... im commiting common/Solitare.[ch] outta spite.
+<wavey> :)
+<Zagor> ...i already committed tetris.c. neener neener ;)
+<adiamas> i know.. i played withit..
+<Linus> Sorry. I'll have to move them to common/mail/pop.c etc.
+* wavey chuckles
+<Bagder> I'm off for a few hours, back later...
+<Linus> CU!
+<adiamas> now a really cool tetris would be able to increase and decrease in size ;)
+* wavey Bagders
+<adiamas> later
+<Zagor> adiamas: yeah, mine is a bit small :)
+<wavey> coolness is related to the ability to pulsate?
+<wavey> that's a new one
+<adiamas> whats was the final word on src format?
+<adiamas> 4 spaces on indent yes?
+<Zagor> yes
+<adiamas> and i_am_a_function, not IAmAFunction
+<adiamas> right?
+<Zagor> yes
+<Zagor> and IAMAMACRO
+<adiamas> right
+<Zagor> or I_AM_A_MACRO is acceptable too
+<adiamas> any word on comments?
+<wavey> glad to hear it :)
+<Zagor> C style
+<adiamas> namely, multiline?
+<wavey> there's // comments already in there
+<Zagor> wavey: yeah, but their about to go extinct
+<Zagor> they're
+* adiamas will fix those as much as he can as he goes
+<wavey> ok cool
+* adiamas wonders if the src formats should be added to the FAQ
+<wavey> yes
+<Zagor> we have a CONTRIBUTING file describing it. that should be mentioned in the faq
+<wavey> and CONTRIB
+* adiamas nods
+<Zagor> ok guys, commit what you have. I'm about to move all drivers
+<Linus> OK Zagor. Define driver.
+<Zagor> good point
+<Zagor> here's my thought about which files go into "drivers":
+<adiamas> pile.c
+<adiamas> hammer.c
+<adiamas> andretti.c
+<Zagor> ata, button, fat, i2c, lcd, led, mas, serial
+* adiamas cackles happily
+* Linus falls asleep
+* adiamas nods
+<adiamas> seems sensible
+<Linus> Kick it!
+<Zagor> CLEAR
+* Linus ducks
+<wavey> heh
+<adiamas> with cvs, as long as i do an update -dP, do i still ahve to do a checkout before i work on and submit code?
+<Zagor> you should
+<Zagor> to avoid complex conflicts
+<adiamas> k.
+<adiamas> how should i reference the CONTRIB in the FAQ?
+<adiamas> just tell them to check out CONTRIB in the source?
+<Zagor> yes, or bjorn.haxx.se/firmware/CONTRIBUTING
+<Zagor> ok i'm done
+<adiamas> that url doen'st work
+<Zagor> ah, forgot "rockbox"
+<Zagor> http://bjorn.haxx.se/rockbox/firmware/CONTRIBUTING
+<adiamas> node
+<adiamas> nod
+<adiamas> okay.. all fixed
+<Zagor> web page updated
+<wavey> my cvs update didn't create the drivers subdirectory within firmware. isn't it recursive?
+<Zagor> you should use "update -dP"
+<wavey> ok, cheers
+<Zagor> as it says on the web page :)
+--- Linus is now known as Linus|lunch
+<wavey> doh
+<adiamas> whats the address to send _to_ the mailing list?>
+<Zagor> rockbox@cool.haxx.se
+--- Zagor is now known as Zagor|lunch
+<adiamas> okay.. last addition to FAQ for the night.. bed time now...
+<adiamas> night
+<wavey> night
+--- adiamas is now known as adi|sleep
+<adi|sleep> oh... btw.. if my humor gets a bit much.. tell me...
+<adi|sleep> i tend to wander a bit on the 'acceptable' scale
+<wavey> weird behaviour on my recorder - all sound ceased
+<wavey> a shutdown and restart with dc power didn't change that
+<wavey> a battery pull with no dc woke it up
+<wavey> piece of shit
+--> alkorr (jbcoax@srs03v-6-237.n.club-internet.fr) has joined #rockbox
+<wavey> hiya alan
+<alkorr> hi everybody
+<wavey> 'hi doctor nick!'
+* wavey chuckles 
+<wavey> simpson's reference
+<wavey> s/'//
+<alkorr> :)
+<-- alkorr has quit (Client Quit)
+<wavey> does id3 have upper size limits for strings?
+<wavey> for memory saving, it seems sensible to me to extract the values from a track we want to display at runtime using the id3 code, (with a fallback to the filename if id3 is empty ) rather than having the track entry in the playlist duplicate those values. 
+<wavey> i know that makes almost no sense
+<wavey> so ignore it
+<wavey> until i can express myself clearly :)
+<adi|sleep> i keep having a file that lists as 'read only' but the permissions are set otherwise...
+<adi|sleep> ive had this before.. 
+<adi|sleep> how do i change it.
+<wavey> on unix?
+<adi|sleep> yup
+<wavey> i've never had that
+<wavey> chmod 777 fails?
+<wavey> are you accessing the file from the cmdline or some tool?
+<wavey> and aren't you asleep? :)
+<adi|sleep> cmdline
+<adi|sleep> i kno i know...
+<adi|sleep> and i have had it before..
+<wavey> linux?
+<wavey> ext2?
+<adi|sleep> learned it when a box i was working on was cracked...
+<adi|sleep> yeah.. its not related to the chmod perms
+<wavey> and you are su?
+<adi|sleep> yup... tried it that way to.. i know its not tht..
+<wavey> you're saying that root is being told a file is read only?
+<wavey> that only happens when the fs is read only
+<adi|sleep> yes... dude.. ive had this before... trust me..
+<adi|sleep> no.. its not..
+<adi|sleep> i know what im talking about here ;)
+<wavey> sounds fucked to me :(
+--- Zagor|lunch is now known as Zagor
+--- Linus|lunch is now known as Linus
+<wavey> by the way, i've started coding playlist.c to provide a simple list of tracks 
+<wavey> it'll use linus' lists.c
+<wavey> and some randomising code i found
+<wavey> add, remove, get next, get previous, etc
+<Zagor> sounds good
+<Zagor> wavey: we're using newlib, which includes rand()
+<Linus> wavey: rand() is part of stdlib.
+<wavey> how large is newlib
+<wavey> i didn't expect to be using any libs
+<Zagor> a lot smaller than glib :)
+<wavey> ok cool
+<Linus> Pretty large if you link it all. Stdio and stdlib takes about 30k.
+<wavey> (i was going to extract stuff from glib, not use it ;)
+<wavey> and you intend to use it all?
+<Linus> Yes. In the beginning. After a while we will find out what we need and what we don't, and replace newlibs functions with our own.
+<wavey> ok
+<wavey> sounds reasonable :)
+--- wavey is now known as wav_lunch
+<wav_lunch> latersss
+<Linus> Yeah, we want to develop the archos specific stuff first.
+* Bagder returns
+<Linus> Welcome Bagder
+* Bagder bows
+<Bagder> lots of commits
+<Zagor> yup
+<Zagor> I'm writing a progress mail for the list. any specific points I should include?
+<Linus> The thread API
+<Bagder> yes, run on target
+<Zagor> that's included
+<Bagder> ran even
+<Bagder> the need for documentation of APIs :-)
+<Bagder> id3 code 
+* Bagder is gonna cut off the malloc()s now
+<Linus> Bagder: It's actually double work to try to simulate the threading code. :-)
+<Bagder> indeed
+<Linus> So obviously it is only run on target.
+<Bagder> yes, but the point would be to tell that it has run
+<Linus> Of course.
+<Bagder> as we already have mentioned the thread api before
+<Linus> I think the threading code it quite neat and even cool.
+<Bagder> I like it. Very little extra, only the very stuff that needs to be there
+<Zagor> yes, it's beautiful
+* Bagder committs
+<Zagor> hmm, how do we glue together newlib and our fat code?
+<Zagor> anyone done it before?
+* Bagder shakes his head
+* Linus hides
+<Bagder> if you build the id3 test program now, it is easily tested on large amounts of files
+<Zagor> have you tried writing tags, or only reading them?
+<Bagder> only reading
+<Bagder> writing isn't that important, is it?
+<Zagor> ok. good enough for now
+<Zagor> no, not until much later
+--- wav_lunch is now known as wavey
+<Zagor> wavey: how are you designing the playlist code?
+<wavey> simple abstract list at the moment
+<wavey> i see a track_t struct
+<wavey> and the playlist is a list of these 
+<wavey> or a list of meta info about each track perhaps
+<Zagor> sounds like a lot of ram for 999 songs?
+<wavey> i only wanna hold the filename in the struct at the moment
+<wavey> ideally
+<wavey> i don't think we can hold any less than that in mem
+<wavey> alternative is the inode for each title
+<Zagor> you can have a byte index for the start of the line in the playlist file
+<Zagor> (there are no inodes)
+<wavey> ah :)
+<wavey> ok
+<wavey> so playlist is always a file based entity?
+<wavey> ack phone
+<Zagor> yes, i think we will always use files for playlists
+<Zagor> if we make one on-the-fly I would say we still want to save it before using it
+<wavey> ok no problem
+<wavey> the more ram we keep free the better
+<Zagor> exactly
+<wavey> so we need to store the filename in question and the line number
+<wavey> makes the playlist code rather simple :)
+<Zagor> we don't really need to store the filename either
+<wavey> course we do
+<Bagder> in the file we do
+<Bagder> playlist file
+<wavey> oh, of course
+<Zagor> index the list file, looking for newlines. keep a list of the index of each new line. that is the play list in ram
+<wavey> we gonna persist all other normally memory resident information too?
+<Zagor> such as?
+<wavey> user settings
+<wavey> vol
+<wavey> balance
+<wavey> etc
+<Zagor> I want them persistent, yes
+<wavey> all in one file?
+<Zagor> or using the pre-fat sector that the player uses
+<wavey> how much space is in there?
+<wavey> are we supporting ext2? :)
+<Bagder> *g*
+<PsycoXul> how about ext3?
+<PsycoXul> :p
+<wavey> heh
+<PsycoXul> journalling baby, do these devices good :p
+<Zagor> each sector is 512 bytes, and i think there are 63 unused sectors
+<PsycoXul> course with other filesystem support we still need to have a fat root
+<wavey> 32k
+<Zagor> 512 bytes is plenty for these settings
+<wavey> be nice to have a good API abstracting that space for our storage
+<Zagor> yes
+<wavey> this is getting quite sexy
+<wavey> ok
+<wavey> playlist is in-memory indexes into our playlist file.
+<wavey> if user abandons that playlist
+<wavey> by selecting a new playlist from disk
+<wavey> we copy the contents to our special playlist file?
+<wavey> and recalc the indexes
+<Zagor> no
+<Zagor> or
+<PsycoXul> you know another thing that'd be kinda nice is to be able to make a playlist of playlists sorta deal
+<Zagor> what do you mean "special playlist file"?
+<wavey> um
+<wavey> i understood that 
+<Zagor> PsycoXul: metalist. yeah, good idea. next version :)
+<wavey> we would be storing filenames for our playlist in a special file 
+<wavey> to save ram
+<Zagor> but we already have the filenames, in the playlist...?
+<Bagder> the playlist on disk *is* the file names
+<wavey> and if the playlist is constructed on the fly?
+<wavey> interactively
+<Bagder> then it must be stored
+<Zagor> they must be saved on disk too
+<Zagor> shouldn't be a problem
+<wavey> yes - but the user shouldn't have to name the file
+<wavey> so we have a special one
+<Zagor> yes
+<Bagder> ah
+<PsycoXul> just like a tmp file
+<wavey> i guess
+<wavey> ok, so with pre-existing playlists, we store the filename and indexes in memory
+<wavey> for an on-the-fly list, we create a special file and do the same as befor
+<wavey> e
+<Bagder> sounds fine
+<wavey> cool
+<wavey> ok, makes for trivial code. which is good :)
+<Zagor> trivial is good
+<Bagder> simplicity is golden
+<wavey> indeed :)
+<PsycoXul> also makes the on-the-fly lists easy to persist 
+<Zagor> yup
+<Zagor> we could have an option to "save" (rename) an on-the-fly list
+<wavey> zag: sure
+<PsycoXul> yeah
+<Zagor> later :)
+<wavey> and randomise simply changes the order of the indexes
+<Zagor> yup
+<wavey> to do disk-wide random play, our playlist file idea gets a little more complex
+<wavey> or a little larger, at least :)
+<Zagor> do you have a good randomize algorithm?
+<Bagder> I want randomize-among-all
+<Zagor> to randomise a bit array
+<Bagder> but it takes some thinking
+<Zagor> big array
+<wavey> my exp isn't that good with randomising, but we'll get something working
+* Bagder nods
+<wavey> perhaps knuth has an archos and will be willing to help out :)
+<Zagor> yeppers
+<Bagder> hehe
+<Zagor> anyone feel like writing lcd-charcell emulation for the simulator?
+<wavey> you said there are no inodes
+<Zagor> :)
+<wavey> do we have aything similar that we can access files by?
+<Zagor> wavey: we have clusters, almost the same thing
+<Linus> Yup. FAT entries
+<wavey> so we could do disk-wide random by examining these clusters by index?
+<Bagder> Zagor: charcell LCD simulated could just use the recorder's lcd string output function, two lines 11 chars
+<Zagor> the problem with those is that you have to look them up for each file, which is what takes so long in the current firmware
+<wavey> hang on
+<Zagor> Bagder: of course. good idea
+<Bagder> it would probably need a more complete charset simulation though
+<Zagor> and some icons
+<wavey> will the fat32 code give us these clusters by index?
+<wavey> oh
+<wavey> you mean it's file->cluster relationship?
+<wavey> nor cluster->file?
+<Zagor> yes
+<wavey> bugger
+<Zagor> so it's not really useful for indexing
+<wavey> it might still be an option.. pre calc all file->cluster entries ready for later use
+<wavey> i.e. a user option
+<wavey> (go make a large cup of coffee option)
+<Zagor> yeah, but what for? there's no gain
+<wavey> because later use of these indexes means instant random file access
+<wavey> for disk-wide random play
+<wavey> perhaps my ignorance of the fat layer is confusing me :/
+<Zagor> instant, as opposed to 200ms delay for looking up the file?
+<Bagder> disk-wide
+<Bagder> you can't have the file names then
+<Zagor> yeah, but disk-wide we still need an index file
+<Zagor> so why save clusters rather than filenames?
+<Bagder> it would make a smaller file
+<Bagder> but I agree
+<wavey> hmm, given a cluster id, can't we get the filename easily?
+<Linus> No
+<wavey> ok, scratch that idea then
+<wavey> worth a try
+<wavey> the alternative is to create the special playlist  file with every filename on disk in it before we can do random play
+<Linus> The directories point out the start cluster of each file, but reverse lookup is not possible
+<Zagor> wavey: we need the playlist file in any case. i vote for filenames
+<wavey> which again is a big hit, but only once, compared to the archo's firmware solution
+<wavey> zag: we don't seem to have a choice anyway :)
+<Zagor> nope :)
+<wavey> ok cool
+<wavey> and it's consistent too
+<wavey> which simplifies things
+<Zagor> precisely. an on-the-fly list is handle by the same code as manually created lists
+<Bagder> so with something like 12-16 bytes in ram per mp3, we make can have a 4000 song playlist on 64K
+<wavey> start of new song in playlist pushes that song index to prefat storage? 
+<wavey> mid song end pushes the time to prefat storage?
+<wavey> mid song end = user decision
+<wavey> are those sentences are mystifying as they read to me? :)
+<wavey> s/are/as !
+<Bagder> I understand your point
+<wavey> goddamnit I can't talk today
+<Zagor> about pre-fat storage:
+<Zagor> we should have a "queue" of such things that "wants" to be stored
+<wavey> both points to enable resume
+<wavey> zag: nice
+<Zagor> then store it when/if the disk spins up for some other reason
+<wavey> hmm - that sounds like it might need a priority system
+<Zagor> why?
+<wavey> stop button on a song
+<wavey> to allow resume
+<wavey> would need to persist immediately in case user powers off too
+<Zagor> that could be a user option
+<wavey> yup
+<wavey> not so much a priority, but a wait or no wait option
+<Zagor> yes
+<wavey> shall I write up some of this for the list?
+<wavey> be good to capture it while it's fresh
+<Zagor> sure
+<Bagder> please do
+<wavey> i'll advertise irc again too
+<wavey> so damn useful 
+<Zagor> i just did in my last mail :)
+<Bagder> over and over again
+<Bagder> ;-)
+<Zagor> :)
+<wavey> how long until you envisage fat32 in place?
+<wavey> few weeks?
+<Zagor> it depends
+<Zagor> could happen next week, could take a couple
+<wavey> cool
+<Zagor> my plan is to start with fat32 and no long-filename support
+<Zagor> when that works we can test the MAS interface
+<Zagor> then we add long filenames
+<Bagder> sounds like a plan
+--- ChanServ gives channel operator status to Zagor
+--> edx (edx@pD950D24B.dip.t-dialin.net) has joined #rockbox
+<edx> hi :)
+<Bagder> hey
+<Linus> Welcome edx!
+<Zagor> ah, edx!
+<edx> the simulator is working for lcd.c
+<Linus> Cool!
+<Bagder> neat
+<edx> scanned my JBR and took it as the interface :)
+<Zagor> hehe
+<edx> hm i am not sure whether code for the JB (not recorder) will work - ill have to try that
+<Zagor> http://bjorn.haxx.se/rockbox/devcon/show.cgi?img4083.jpg
+<Bagder> good comparison pic
+<edx> what is the resolution of teh JBS displays?
+<Zagor> jbs?
+<edx> jukebox studio
+<edx> (normal jukebox)
+<Zagor> ah, 11x2
+<Zagor> characters
+<Zagor> we call it "player"
+<Bagder> edx: if you just get the kets too, you could play tetris soon! ;-)
+<Bagder> keys
+<wavey> can we agree to refer to individual mp3s as 'tracks' rather than 'songs' 
+<Bagder> sure
+<wavey> the current firmware refers to songs when loading spoken word tracks and it annoys me :)
+<edx> hm how is the lcd controller accessed - completely different way i guess.. ?
+<edx> (i mean from a higher level view...)
+<Bagder> yes
+<Bagder> they are two different APIs, at least now
+<Zagor> http://bjorn.haxx.se/rockbox/devcon/
+<Bagder> btw
+<Bagder> the id3 code uses ftell
+<Bagder> just for getting the size of the file
+<Zagor> ok
+<Zagor> shouldn't be a problem
+<Bagder> we didn't define any function to get the size, nor ftell ;-)
+<Bagder> (reading the devcon notes)
+<Zagor> our api definition is a little outdated, since we'll be using newlib anyway
+<Bagder> ya
+<Zagor> it contains all those functions
+<Bagder> but we don't yet know how to map them to the fat code, do we?
+<wavey> can i send to your list from an account it doesn't recognise?
+<Zagor> yes
+<wavey> cool
+<Zagor> we love spam :)
+<wavey> heheh
+<Linus> Implementing those functions in newlib isn't that hard.
+<Bagder> lots of fine closeups on Archoses!
+<Bagder> ok
+<Zagor> ah, forgot one picture: The Virgins! :-)
+<Linus> :-)
+<Linus> Pile'em'up!
+<Zagor> an almost offensive number of archoses...
+<edx> the devcon page is cool (jsut had a look at it :D)
+<Linus> It was cool!
+<Bagder> we should have more devcons!
+<Linus> The event of the year! ;-)
+<edx> i would have liked to join you :) - too far
+<edx> hey... could you give all cvs-registered ppl ops for this channel :D
+--- Bagder gives channel operator status to edx
+<Bagder> :-)
+<edx> thx
+<Zagor> hmm, i think we're all cvs registered actually :)
+<edx> LOL
+<edx> op everybody *lol*
+--> ironi (xircon@m213-101-132-20.swipnet.se) has joined #rockbox
+<ironi> ello
+<ironi> i read the progress report, fascinating =)
+<ironi> wavey, Linus
+<Zagor> alooh!
+<Bagder> getting crowded!
+<ironi> Zagor, hi
+<ironi> Zagor i am curious where oyu got the nick
+<Linus> Yoooo!
+<ironi> i know about a italian comic strip called zagor
+<Zagor> oh, it's an old one
+<wavey> ironi hi
+<Zagor> I made it up for a D&D character some time around ~83
+<ironi> ok so you just made it up? cool.
+<Zagor> he was a herb collecting monk, if i recall correctly :)
+<ironi> heh
+<ironi> i am really looking forward to the win32 simulator
+<Zagor> yeah, I made it up. didn't know about the comic strip until mid-90s
+<ironi> oh, so you do know about it.
+<ironi> =)
+<Zagor> yes, I do now :)
+<ironi> i dont think it really exists in sweden, does it?
+<Bagder> ironi: say boo to edx, he has made it work ;-)
+<Zagor> never seen it at least
+<ironi> edx, good job
+<edx> ironi: want an alpha version? (im coding it)
+<ironi> Bagder, i wanna try it , i wnna try i
+<ironi> want
+<ironi> edx, how big is it?
+<ironi> edx, cause im on gprs right now
+<edx> hmmm lets see... i can send you a release compile of the simulator (you cant test your own code then) - it is 44 kb
+<ironi> oh ok i tohught we were talking > 1 mb
+<ironi> send it
+<Zagor> good mail, wavey
+<ironi> not graphic, then?
+<Linus> Indeed. Well done!
+<wavey> cool ta
+* wavey goes for coffee
+<edx> it is graphic - it only supports graphics right now actually (nothing else [like keystrokes
+<ironi> ok well hand it over
+<ironi> what do you code it in?
+<edx> MSVC++ (7)
+<edx> but it is straight c code
+--> elinenbe (~chatzilla@bgp01080511bgs.wanarb01.mi.comcast.net) has joined #rockbox
+<edx> so you can compile it on any windows compiler
+<Zagor> hi elinenbe
+<edx> do you get the dcc request?
+<elinenbe> Hey there.  I have some great ideas for browsing/playlist implementation...
+<ironi> edx, i see. i do know some c++
+<elinenbe> DOes anyone here have a riocar/empeg player?
+<ironi> edx, not working?
+<Zagor> elinenbe: nope :)
+* Bagder has none
+<edx> give me your email adress.. ill mail it then
+<ironi> edx, cvitan@zworg.com
+<ironi> ehm, what wa si going to say...
+<elinenbe> well, the way it works is based on ID3 tags, but that is not the way this player is designed, so we will just use the folders instead.
+<elinenbe> what you do is start a playlist or just play songs.
+<ironi> yeah; well my linux-on-jukebox is not working well
+<ironi> i guess someone else could make it owrk in 5 minutes, but..
+<edx> if you want i can attatch source as well (only a few kb too)
+<elinenbe> and then if you browse to a new sond and you hold down play for 2 seconds, it comes up with an option.
+<ironi> edx, do that
+<Zagor> elinenbe: option for what?
+<ironi> edx, i am getting interested in installing my vc++
+<elinenbe> 1)insert after current song (does what is says)  2)append  (this will cue the song to be played after whatever else is queued)
+<ironi> got that somewhere
+<elinenbe> and if you just want to play the sond you just hit play (no hold down necessary)
+<edx> hehe
+<elinenbe> this works VERY well....
+<Zagor> elinenbe: sounds like a good interface
+<Bagder> elinenbe: sounds clever and convinient, yes
+<edx> ok.. sent it
+<elinenbe> they have a really sweet interface for only a few buttons...
+<edx> ah.. Zagor: what dir (cvs) should i put the simulator (w32) in?
+<Zagor> edx: uisimulator/win32
+<Bagder> we could possibly move the x11 stuff into a separate dir too
+<edx> right now (on my computer) i have it in uisimulator/uisw32 but doesnt matter anyways (just for the relative paths... they all go to ../../firmware)
+<Zagor> Bagder: at your convenience
+<Bagder> ok, I'll save that work for later ;-)
+<Zagor> edx: win32 is a better name imho
+<edx> it is.
+<edx> i chose the other name because i had to create msvc project file (and win32 is  a stupid project name IMO)
+<ironi> what headphones do you guys use with your player/recorder?
+<ironi> I have found the koss portapro to work really nice with my player
+<edx> ironi: (standard headphones)
+<Linus> some Sony plugs
+<elinenbe> I use the ones that come with it...  I have no problem, and they are nice because I can put them into my bag without worries (fold up)
+<ironi> edx, shouldn't it be IMHO
+<ironi> =)
+<Zagor> ironi: I use the Sony EX70 earplugs. best I've ever heard.
+<ironi> heh
+<ironi> portapro are also fold
+<ironi> Zagor, ex70...don't know about them...
+<edx> irony: why?
+<Zagor> you guys should try the EX70s. you haven't heard what the Archos can to until you've tried them
+<ironi> i don't like plugs very much myself
+<ironi> edx, just joking
+<edx> ok
+<edx> LOL
+<ironi> Zagor, how much are they
+<edx> yea how much
+<edx> (and where do i get 'em)
+<Zagor> ironi: don't remember really. $70 or some such.
+<elinenbe> http://www.etronics.com/product.asp?stk_code=sonymdrex70lp
+<elinenbe> $35 USD
+<ironi> Zagor, aeh? oh
+<ironi> alot for plugs
+<Zagor> I have a pair of Sony VDR-700 for $250 and the EX70 compares very favorably...
+<edx> LOOOOL @ $250
+<Zagor> what can I say, I like good stuff...
+<ironi> i wonder how they compare to portapro, which are considered to be the best portable headphones in the >$70 class (>$100 in europe)
+<ironi> for like 10 years now
+<edx> another thing: how long (in msecs) does a lcd_update take an a JB?
+<Zagor> ironi: In my opinion the Portapros are overrated. Narrow range not much oomph.
+<edx> because i have to simulate slowness as well :)
+<Zagor> but that's just my opinion :)
+<edx> Germany: (Sony headphones): 38,95 Euros
+<edx> LOOOL "avaibility: 2 to 6 weeks" argh!
+<Bagder> edx: I think Gary spoke about 20 frames per sec or somehing like that
+<Zagor> ok, so I remembered wrong :)
+<Bagder> lcd_update() I mean
+<edx> ah ok.. that makes... hmm 50msecs
+<ironi> Zagor, well I mean for a device like archos they deliver the base and solid clarity
+<ironi> oh this s a recorder simulator
+<elinenbe> I was just wondering -- how much is Archos going to pay you guys once the popularity of the jukebox explodes...  every open source / Linux nut will go nutty ofr an open source mp3 player (just wait until the slashdot crowd finds out about this...)
+<edx> hm it has the design of a recorder - but it will work for a JBP as well
+<Zagor> elinenbe: I wouldn't bet them even acknowledging our existence
+<ironi> hehe
+* Zagor has written a "slashdot protection" script for the website :)
+<ironi> Zagor?
+<edx> what is slashdot protection lol
+<Zagor> index.cgi counts hits. >10 hits in 10 seconds triggers a redirect to a mirror at sourceforge.net
+<edx> ahhh
+<edx> ok..
+<edx> what does the word slashdot mean than - like spamming?
+<elinenbe> are you serious about that?
+<Zagor> I have no idea if it's enough, but it's an attempt...
+<Zagor> elinenbe: yup
+<Zagor> slashdot is a website: slashdot.org
+<elinenbe> slashdot is a site all about geek news...
+<edx> aha
+<elinenbe> when a story is posted there nearly everyone reads up on it...
+<edx> ahhhhhh
+<edx> ok now i got it all :)
+<edx> sorry for being that slow ;)
+<elinenbe> therefore if your site is where the story came from, then you have 1000)+ hits very fast...
+<elinenbe> boom! crash! lock! <-- there goes your server
+<edx> yea.. hehe
+<Zagor> your site gets "slashdotted"
+<ironi>  /.
+<edx> are they gonna post about rockbox there? lol
+<ironi> well, gotta go, have a meeting with the student television
+<edx> cu
+<ironi> later, you guys.
+<Zagor> bye
+<ironi> maybe i should do my masters thesis with the rockbox as an example
+<ironi> and interview you ppl
+<Zagor> ironi: sure, i'm game
+<ironi> do a thesis with something about open source
+<ironi> it's a n interesting subject
+<ironi> =)
+<ironi> well worth to think aobut
+<ironi> i will talk to a ph.d. that does research on oss organisation forms, etc.
+<-- ironi has quit ("later <k!15b8>")
+<Zagor> edx: i expect we will be on slashdot some day. I just hope it will be after we have something to "show" rather than in the current state
+<Zagor> first impression, and all that
+<Zagor> so don't tell anyone :)
+<Bagder> ... 91 subscribers today
+<Linus> Gotta go! l8r!
+<Bagder> bye Linus
+<-- Linus (~linus@labb.contactor.se) has left #rockbox
+<wavey> zag: ex70 are the plug type yeah?
+<wavey> i have them
+<wavey> they're great
+<Zagor> wavey: they are then new type that you literally insert into the ear canal
+<wavey> if bass-heavy
+<wavey> yes 
+<wavey> i have to turn the bass down on the archos
+<wavey> too boomy otherwise
+<Zagor> pull down the bass on the recorder, and they give you exceptional range
+<edx> LOL
+<Zagor> yes, me too
+<wavey> yus - they're great
+<wavey> and close out the rest of the world very nicely :)
+<Zagor> yep
+<Zagor> I bought the Etymotic ER-4P
+<Zagor> $350 plugin headphones
+<wavey> yow
+<Zagor> they sucked, big time!
+<wavey> i saw refs to them when researching plugs
+<Zagor> yeah, they are considered the top of the top of the top
+<wavey> ppl loved 'em or hated 'em
+<wavey> said you need to learn to 'relisten' to your music
+<wavey> to compensate for no bass, or something?
+<edx> LOOOOL I cant get you are spending 350 bucks on headphones
+<Zagor> yeah, that's just an euphemism for "I can't admit I spent my money on crap"
+<Zagor> I sent them back and got a refund
+<wavey> edx: the argument is why spend big bux on a decent sound system, then peanuts on the delivery mechanism
+<Zagor> they really have *NO* bass. it's pathetic
+<edx> How do you lcd_init for char displays with currend lcd.c?
+<edx> i get the feeling we cant get around writing two seperate OSs... I mean I want real fancy graphics on my recorder (not the f*** char display graphics) :P
+<Bagder> we will probably write more or less two separate UI threads, yes
+<Bagder> +write
+<Bagder> one for each LCD
+<Zagor> the user interfaces will be different code, yes
+<edx> so how do i init char displays?
+<edx>     lcd_init ();
+<edx> wont work
+<edx> (LCD_BITMAP_blah not defined)
+<Bagder> hey!
+<Bagder> load-file alert
+<Bagder> bad paths
+<Zagor> looks like lcd_init is missing
+<Zagor> for charcells
+<Zagor> Bagder: ?
+<edx> lol the lcd.h does not define lcd_init for char cell lcds (yet?)
+<Bagder> Zagor: the emacs magic in the bottom of the files...
+<edx> ah ok
+<Bagder> Zagor: uses wrong file name
+<Zagor> ah, yes
+<edx> ill wait until it is released then - if i have enoguh time ill wirte a JBP GUI for the player then :)
+<Zagor> i'll take a look at it
+<wavey> do our fat32 fs entries have the archive flag?
+<Zagor> I wouldn't count on it
+<Zagor> i'm responding too :)
+<wavey> heh cool
+<Zagor> besides, scanning for archive bits isn't any faster than scanning for files
+<Bagder> *and* you can build the huge play list with an external tool while USB connected
+<wavey> well, the scanning is unavoidable, the comparison of a bit flag is certainly easier than a filename comparison
+<Zagor> but more uncertain
+<Zagor> i've sent my mail, read it :)
+<wavey> will do
+<edx> be back later... cu
+<Zagor> bye
+--- edx is now known as edx|bbl
+<wavey> i was also wondering if we should pre-fetch the previous and next playlist entry details to ensure smoother operation
+<Bagder> probably
+<Zagor> wavey: yes. maybe even several entries. sometimes you want to skip a few tracks
+<Zagor> a compile-time option, ideally
+<wavey> yus
+<wavey> open source. the only way forward :)
+<Zagor> yus ;)
+<Zagor> i'm going home. see you soon, guys :)
+<wavey> byee
+<-- Zagor (~bjst@labb.contactor.se) has left #rockbox
+<Bagder> I'll need to dash too, I might pop by a little later or tomorrow. See ya
+**** ENDING LOGGING AT Tue Apr 23 17:30:11 2002