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