rockbox/www/irc/rockbox-20020423.log

**** 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<42>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<42>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