diff options
Diffstat (limited to 'www/irc')
| -rw-r--r-- | www/irc/index.t | 1 | ||||
| -rw-r--r-- | www/irc/rockbox-20020423.log | 1012 |
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 |