00:00:50 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF8E99.dip.t-dialin.net) |
00:01:18 | amiconn | hi |
00:01:28 | [IDC]Dragon | 'evening |
00:02:25 | [IDC]Dragon | I'm just in for a quick visit |
00:03:54 | iRiverMan | hey |
00:03:55 | amiconn | Interesting discussions today in the channel... |
00:04:11 | [IDC]Dragon | the database? |
00:04:18 | iRiverMan | the iriver isn't very good at shuffling songs in playlists |
00:05:16 | amiconn | [IDC]Dragon: Yes. I wonder why all those various additional tables per relation are proposed |
00:06:00 | amiconn | This will soon get us in a table mess, imho, especially if more different info is added. |
00:06:04 | [IDC]Dragon | I've never been good at databases (my weak point) |
00:06:45 | amiconn | Sequential search is slow, of course, but why not use a binary tree for search? |
00:06:55 | [IDC]Dragon | so I stay away from that discussion |
00:08:49 | amiconn | I'm not very good in that area either (and I don't see the benefit from a db in the proposed form - static on the box) |
00:10:00 | [IDC]Dragon | all I remember is that there is a redundancy/speed tradeoff in the # of tables used |
00:19:43 | | Quit iRiverMan ("CGI:IRC (Ping timeout)") |
00:20:09 | amiconn | [IDC]Dragon: Argh! Solitaire accesses an array with out-of-bounds index! |
00:21:11 | [IDC]Dragon | yours, or before? |
00:21:26 | amiconn | Before. |
00:22:05 | amiconn | Try the following: Start solitaire. From the menu, select "Help", Note down the string displayed in the first line. |
00:22:22 | [IDC]Dragon | sorry, not now |
00:22:31 | amiconn | Start the game, and immediately exit to menu. Select "Help" again. What do you see? |
00:24:32 | midk_ | yyyss a key to see |
00:24:40 | midk_ | y with the dotty things :) |
00:24:43 | amiconn | Yup. |
00:26:36 | amiconn | The mistake itself seems obvious, but I don't know whether fixing it will break the proper behaviour of the game... have to try |
00:31:42 | midk_ | why would it break the behavior of the game? |
00:31:54 | midk_ | well, i'm not too sure of the fix anyways without looking at the source |
00:32:22 | midk_ | the 'press a key, get the info' kind of help is nice, but if you do try to fix the bug you should also make the text disappear instead of just sitting there |
00:32:38 | midk_ | ie.. on keypress, clear the screen, draw the help text and then draw the corresponding button text |
00:34:20 | amiconn | The problem is that as soon as the game starts, the first 3 bytes of the help text get overwritten. There is an array immediately before it, char stacks[4]. The init writes from 0 to 6... |
00:34:56 | midk_ | switch it to char stats[6] or 7 then? |
00:35:32 | amiconn | No, it looks like only the init is wrong. It should write form 0 to 3 iiuc |
00:39:08 | midk_ | oh |
00:40:24 | amiconn | Hmm. |
00:43:07 | | Quit silencer_ (Remote closed the connection) |
00:43:09 | | Join silencer [0] (~silencer@zen.via.ecp.fr) |
00:51:25 | [IDC]Dragon | Phew, I'm done with the radio. |
00:52:07 | amiconn | What solution do you have for the presets? |
00:58:37 | [IDC]Dragon | long press of Right |
00:58:56 | [IDC]Dragon | and extra menu entries beforehand |
00:59:10 | [IDC]Dragon | for what can't be on buttons |
00:59:20 | [IDC]Dragon | gotta leave now |
00:59:32 | | Quit [IDC]Dragon () |
00:59:35 | *** | Saving seen data "./dancer.seen" |
01:00 |
01:36:26 | | Join napgravy [0] (user@S0106004095d1df8f.cg.shawcable.net) |
01:39:31 | | Quit napgravy (Client Quit) |
01:52:54 | | Quit mecraw_ ("Trillian (http://www.ceruleanstudios.com)") |
02:00 |
02:03:03 | | Join edooo [0] (~edooo_188@82.129.244.5) |
02:05:47 | | Quit edooo (Read error: 54 (Connection reset by peer)) |
02:05:58 | | Quit AciD (Remote closed the connection) |
02:13:33 | | Join Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
02:16:54 | midk_ | hi bc |
02:26:45 | Bluechip | hi |
02:33:40 | | Part amiconn |
02:36:03 | | Join zargoyle [0] (zazz@079-099.dialup.sunysb.edu) |
02:39:27 | | Quit Sebulba02 (Read error: 54 (Connection reset by peer)) |
02:41:16 | | Quit midk_ (Read error: 104 (Connection reset by peer)) |
02:42:59 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
02:54:21 | | Quit edx (Read error: 110 (Connection timed out)) |
02:59:37 | *** | Saving seen data "./dancer.seen" |
03:00 |
03:38:37 | | Quit midk (Remote closed the connection) |
03:42:20 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
03:44:01 | | Part Bluechip |
03:53:05 | | Quit zargoyle ("sudden death") |
04:00 |
04:19:43 | | Join Sebulba02 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc) |
04:33:52 | | Join edx [0] (edx@pD9EAA501.dip.t-dialin.net) |
04:49:44 | | Quit midk ("Leaving") |
04:50:47 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
04:59:40 | *** | Saving seen data "./dancer.seen" |
05:00 |
05:02:24 | | Join adiamas [0] (~chatzilla@host-64-179-64-18.alb.choiceone.net) |
05:14:04 | | Quit scott666 ("i'll be back...eventually...") |
05:19:14 | | Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
05:46:36 | | Quit scott666 (Read error: 104 (Connection reset by peer)) |
05:52:03 | | Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
06:00 |
06:59:41 | *** | Saving seen data "./dancer.seen" |
07:00 |
07:04:54 | | Quit scott666 ("i'll be back...eventually...") |
07:12:56 | | Join LinusN [0] (~linus@labb.contactor.se) |
07:22:56 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
07:24:39 | | Quit adiamas ("Chatzilla 0.9.65 [Mozilla rv:1.7.3/20040913]") |
07:49:56 | | Quit matsl (Remote closed the connection) |
07:52:29 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
08:00 |
08:18:47 | | Join MofuTech [0] (~80ebf233@labb.contactor.se) |
08:19:11 | MofuTech | hello |
08:19:47 | MofuTech | have you guys gotten that broken h120 you needed? |
08:20:04 | MofuTech | i think i know someone who broke his... |
08:20:40 | MofuTech | i'll ask him if he wants to give it to me, or if i should buy it from him... |
08:21:39 | | Join Lurkski [0] (~Miranda@24.30.163.142) |
08:22:56 | LinusN | MofuTech: we have a broken one already, so we don't really need another one |
08:23:06 | LinusN | thanks anyway |
08:23:42 | midk | LinusN, drop yours? ;) |
08:25:51 | LinusN | hehe |
08:26:08 | LinusN | no, we got a broken 120 on Ebay a while ago |
08:26:39 | midk | oh, where zagor101 swiped it at the last second? |
08:26:44 | LinusN | yes |
08:26:52 | MofuTech | oh ok |
08:27:14 | midk | what's that called? |
08:27:16 | MofuTech | how is the development process? |
08:27:17 | midk | camping? |
08:27:22 | LinusN | and i have a 140 PCB on it's way here as well |
08:27:31 | LinusN | and a broken remote |
08:27:45 | LinusN | well, the threading works |
08:28:04 | LinusN | i have written most of the interrupt handling code |
08:28:14 | LinusN | working on the tick timer interrupt |
08:29:46 | MofuTech | how did you guys decide on starting work on the h-series? |
08:31:00 | LinusN | lots of pressure from misticriver and iriverlounge |
08:31:08 | LinusN | :-) |
08:31:21 | LinusN | we have been looking for possible target platforms for a while |
08:32:00 | MofuTech | were your options only limited to UMS devices? |
08:32:06 | LinusN | and the iriver is a good candidate, since it is built out of off-the-shelf chips, with publicly available documentation |
08:32:15 | LinusN | UMS? |
08:32:23 | MofuTech | USB mass storage class |
08:32:31 | LinusN | not at all |
08:32:46 | LinusN | but we prefer it |
08:33:15 | MofuTech | its good that the info on the iriver chips are available |
08:33:32 | LinusN | absolutely |
08:34:03 | MofuTech | there has been a lot of work concerning libnjb and the nomad jukebox/zen/dell players |
08:34:16 | LinusN | oh |
08:34:19 | MofuTech | have you ever considered those devices? |
08:34:33 | LinusN | not that i know of |
08:34:58 | LinusN | i don't know what hardware they are based upon |
08:35:10 | LinusN | ipod is out of the question |
08:35:16 | LinusN | so is rio karma |
08:35:29 | MofuTech | why is that? |
08:35:40 | LinusN | they are based on the PortalPlayer chipset |
08:35:58 | LinusN | you have to give away your firstborn to get the data sheets |
08:37:06 | MofuTech | wow |
08:38:14 | MofuTech | i think that the iaudio m3 is based on the same hardware as the h100 series |
08:38:41 | MofuTech | im not too sure though |
08:40:23 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
08:42:09 | MofuTech | if everything goes to plan, God willing, what will the first few releases of the firmware look like? |
08:42:29 | LinusN | they will look like rockbox on the archos |
08:42:52 | LinusN | they will probably play wav and mp3 |
08:43:04 | LinusN | no recording |
08:43:52 | MofuTech | sounds good |
08:44:13 | MofuTech | for a start, it has to work first |
08:46:54 | | Join millow [0] (~millow@67.227.adsl.i4surf.net) |
08:50:26 | | Part millow |
08:50:50 | | Join millow [0] (~millow@67.227.adsl.i4surf.net) |
08:53:45 | | Part millow |
08:54:00 | | Join millow [0] (~millow@67.227.adsl.i4surf.net) |
08:56:48 | | Join Dujodu [0] (APDesign@CPE-24-167-199-72.wi.rr.com) |
08:57:22 | | Join [IDC]Dragon [0] (~idc-drago@pD9E34C4A.dip.t-dialin.net) |
08:58:00 | [IDC]Dragon | LinusN: I made a mess in radio.c |
08:58:20 | [IDC]Dragon | #ifdef hell |
08:58:42 | | Quit millow (Client Quit) |
08:59:45 | *** | Saving seen data "./dancer.seen" |
09:00 |
09:01:24 | | Quit [IDC]Dragon () |
09:01:37 | | Join Zagor [242] (~bjst@labb.contactor.se) |
09:02:15 | | Quit MofuTech ("CGI:IRC (EOF)") |
09:09:13 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
09:10:37 | | Join kurzhaarrocker [0] (~knoppix@p50876588.dip0.t-ipconnect.de) |
09:16:38 | Zagor | i'm beginning to have second thoughts about the shine codec. it purposefully degrades quality to enhance performance. will we ever be happy with such an approach? |
09:17:33 | kurzhaarrocker | Are there alternatives that don't delay the development process? |
09:18:44 | Zagor | well I'd say we simply start with recording to wav |
09:19:17 | kurzhaarrocker | cool, we start with recording and not with playback :) |
09:19:42 | Zagor | ah, no. shine is only for recording. for playback we use libmad, which has no problems. |
09:20:01 | Zagor | in fact libmad has higher quality than many floating-point implementations |
09:20:12 | * | Dujodu wishes he knew what you were talking about. |
09:20:20 | kurzhaarrocker | Ah, I see. |
09:21:03 | kurzhaarrocker | Dujodu: its about the software engine that encodes the sound to mp3 format. That's necessary on targets like iriver that don't have a dedicated chip for that. |
09:21:27 | Dujodu | that's cool |
09:22:25 | Dujodu | and pretty amazing, that you guys are making it. |
09:22:48 | kurzhaarrocker | I don't. Zagor does. |
09:22:56 | Dujodu | heh |
09:23:15 | Dujodu | you probably do some other cool stuff though |
09:23:16 | LinusN | Zagor: shine is a bare-bones mp3 encoder |
09:23:42 | LinusN | and no, we will not be happy with the quality, we will have to enhance it ourselves |
09:23:51 | | Quit kurzhaarrocker ("Trillian (http://www.ceruleanstudios.com)") |
09:24:18 | Zagor | ...which will be a HUGE work. we need to invent a whole psychoacoustic model. |
09:24:30 | LinusN | probably |
09:24:51 | LinusN | it would of course be nice if we found another, better encoder |
09:24:51 | dwihno | Psycho acoustics \o/ |
09:25:17 | | Join kurzhaarrocker [0] (~none@p50876588.dip0.t-ipconnect.de) |
09:25:25 | LinusN | realtime encoders don't grow on trees, unfortunately |
09:25:49 | Zagor | well the question i'm asking is: do many people really prefer to record direct to mp3 rather than to wav and then use a high-quality offline encoder? |
09:26:04 | dwihno | WAV recording, "until something better pops up"? |
09:26:05 | LinusN | it's a matter of disk space |
09:26:25 | Zagor | is it, really? |
09:26:26 | kurzhaarrocker | And a matter of battery drain. Wav takes considerably more hd activity. |
09:26:29 | LinusN | a 2-hour lecture in WAV takes a few Kbytes :-) |
09:26:35 | dwihno | :-) |
09:26:55 | Zagor | kurzhaarrocker: mp3 takes considerably more cpu power... :) |
09:27:09 | dwihno | LinusN: Recording speech doesn't require 44.1khz stereo :) |
09:27:14 | | Quit silencer (Nick collision from services.) |
09:27:15 | | Join silencer [0] (~silencer@zen.via.ecp.fr) |
09:27:32 | kurzhaarrocker | Well I suspect that cpu power is cheaper than spinning hd motors and heads. |
09:27:38 | LinusN | indeed |
09:28:04 | LinusN | but i don't think those 1.8" drives are that power hungry |
09:28:07 | | Quit silencer (Nick collision from services.) |
09:28:57 | kurzhaarrocker | If we can get a device that ergonomically and reliably can record > 5h to wav on batteries I'll buy it and don't need any mp3 encoding any more. |
09:29:24 | Zagor | kurzhaarrocker: what are you recording for >5h? |
09:30:10 | * | Bagder spots something weird on the web site |
09:30:20 | kurzhaarrocker | I use it to track live concerts. Its a plus to record the entire concert which may feature 6 bands and last from afternoon till midnight. |
09:30:42 | Bagder | Zagor: is the lower part of the menu supposed to be left aligned and the upper part right aligned? |
09:30:42 | Zagor | kurzhaarrocker: you record 5-hour concerts in the audience? |
09:30:53 | Zagor | Bagder: no, that's a wiki bug. me fix. |
09:31:00 | LinusN | Bagder: the wiki css seems bad |
09:31:06 | kurzhaarrocker | No, I fix the mic somewhere, put the stuff somewhere else and rock the stage myself :) |
09:31:17 | Bagder | LinusN: that's html, not css actually |
09:31:58 | Bagder | Zagor: the point is probably valid for students that record lectures etc |
09:32:11 | LinusN | ok |
09:32:15 | | Join silencer [0] (~silencer@zen.via.ecp.fr) |
09:32:21 | Zagor | fixed |
09:32:23 | | Nick silencer is now known as silencer_ (~silencer@zen.via.ecp.fr) |
09:32:30 | Bagder | nice |
09:33:14 | kurzhaarrocker | Zagor: you could only beat LinusN's 11-Minute fix because bagder didn't write a bug report. |
09:33:23 | Zagor | Bagder: actually it appears to be an issue with fcpp. see Makefile for head.tmpl |
09:33:33 | Bagder | aha |
09:34:59 | Bagder | hey! an Ondio q on the forum! ;-) |
09:36:12 | * | Bagder walks off to get a cup of that black stuff |
09:36:51 | kurzhaarrocker | hardcore smokers drink the tar? |
09:39:48 | Dujodu | ha |
09:42:51 | kurzhaarrocker | ot: Do any of you use fancy gui cvs clients? Or do you cvs all in the shell? |
09:43:34 | Zagor | shell all the way |
09:43:55 | Bagder | emacs is my gui |
09:44:07 | Zagor | if you're on windows, i can recommend tortoisecvs though. it's the best cvs gui i've seen. |
09:44:24 | * | kurzhaarrocker considers emacs more as a shell than a gui |
09:45:08 | kurzhaarrocker | tortoisecvs is cool. |
09:46:23 | kurzhaarrocker | I just wished I found out how to modify the diff parameters to create patches with it. |
09:46:32 | kurzhaarrocker | with tortoisecvs |
09:48:11 | Zagor | try the "Make patch" menu item :) |
09:49:33 | kurzhaarrocker | yes but with that I don't know how to specify the diff -B option. I get many many honks that are only changes because of whitespace. |
09:50:05 | kurzhaarrocker | sorry, it's the -b option of course. |
09:50:31 | Zagor | right. I've never actually tried making patches with a gui tool. |
09:50:53 | Bagder | I always used the command line tool for that, even when using tortoise |
09:53:41 | | Part Lurkski |
09:58:59 | kurzhaarrocker | strange: cvs diff doesn't seem to be allowed as anonymous. But if that was true how can turtoise manage that? |
09:59:19 | Zagor | diff should be allowed |
09:59:31 | Zagor | what error do you get? |
10:00 |
10:01:13 | kurzhaarrocker | : no such repository |
10:01:13 | kurzhaarrocker | cvs diff: authorization failed: server rockbox.haxx.se rejected access to /cvsro |
10:01:13 | kurzhaarrocker | for user anonymous |
10:01:13 | DBUG | Enqueued KICK kurzhaarrocker |
10:01:13 | kurzhaarrocker | cvs diff: used empty password; try "cvs login" with a real password |
10:01:53 | Zagor | you need to login for anonymous access too, just use username "anonymous" and no password |
10:02:20 | Zagor | http://www.rockbox.org/twiki/bin/view/Main/UsingCVS :) |
10:03:23 | Zagor | just tried anonymous diff here, works fine |
10:03:53 | kurzhaarrocker | Ok I generally seem to be a cvs moron. |
10:06:46 | kurzhaarrocker | I thought once you have checke something out you didn't have to specify the -d option in cvs any more - as long as you are within your cvshome. |
10:08:35 | Zagor | you don't |
10:11:00 | kurzhaarrocker | When I don't specify the -d with cvs login it correctly says (Logging in to anonymous@rockbox.haxx.se) but then there's the authorization failure again. |
10:11:16 | kurzhaarrocker | with -d it works |
10:11:48 | Zagor | you need to run two commands: first login, then checkout. both need -d. after that, you don't need -d. |
10:12:30 | kurzhaarrocker | I still seem to need it afterwards. |
10:12:43 | Zagor | then something is wrong in your sandbox |
10:13:09 | Zagor | try checking out to another directory |
10:15:01 | | Join amiconn [0] (~jens@pD9E7EF9B.dip.t-dialin.net) |
10:15:16 | amiconn | Morning |
10:16:25 | Zagor | morning |
10:17:30 | kurzhaarrocker | moin |
10:19:30 | amiconn | I have a problem with the solitaire plugin... it is hard to adapt to Ondio. Not because of the number of keys, but because it uses a clever macro for the help text display. |
10:20:05 | amiconn | I didn't find a way to include conditional compilation *within* a macro. Is that at all possible? |
10:20:13 | Bagder | no |
10:20:16 | Bagder | not portably |
10:20:24 | Zagor | ouch, u-g-l-y! |
10:20:35 | Bagder | make two macros |
10:20:41 | amiconn | Hmm. So that means I have to unroll all uses of that macro |
10:20:57 | Zagor | yes, please. it's a single function call |
10:21:12 | | Join Lynx_ [0] (lynx@134.95.189.59) |
10:21:17 | kurzhaarrocker | I don't believe it! Tortoise cvs created a CVS/Root file that has CR+LF endings. command line cvs doesn't like that, it wants LF only. |
10:21:45 | Bagder | haha |
10:21:46 | amiconn | Zagor: I would be no more a single call on Ondio, depending whether the button has 2 functions or not. |
10:21:48 | Zagor | kurzhaarrocker: that's what you get for fooling with guis ;) |
10:21:50 | Bagder | wwwwiiiinnndddooowss ;-) |
10:22:10 | Zagor | amiconn: aha. well all the more important to not make the code harder to read then |
10:22:14 | amiconn | kurzhaarrocker: I use command line cvs only (never looked at tortoise) within cygwin |
10:22:42 | amiconn | Zagor: Okay. Then I'll go for unrolling the macro completely. |
10:23:03 | Zagor | good |
10:23:16 | kurzhaarrocker | Here at work we _must_ use the cvs from Eclipse. Don't ask my opinion on cvs client that don't cvs! |
10:25:34 | Zagor | rigid tool rules are always good for productivity. i bet you're only allowed to use a company-specified text editor too? |
10:25:45 | Zagor | and pants |
10:27:40 | kurzhaarrocker | The pants are up to my choice. But whenever we decided to use _that_ tool only we very soon got stuck in the restrictions that tool has and made a hell of effort to circumvent them. I prefer to rigidly specify the results and not the tools. |
10:30:00 | Zagor | classic clueless management. they have no idea how to manage the development process, so they manage whatever they can understand: the names of the tools |
10:30:42 | Zagor | i see it everywhere |
10:30:55 | kurzhaarrocker | erm, its a very small company. Fortunately those who make the decissions suffer them too. :) |
10:31:22 | Zagor | hehe |
10:47:33 | | Quit Dujodu () |
10:52:25 | amiconn | Zagor: Is it okay to continue with plugin adaption (both for Ondio and for USB handling via default handler) while the feature freeze is in effect? I would like to change the plugin api when done with tha (taking out usb_screen(), therefore breaking backwards compatibility -> sort functions) |
10:53:56 | Zagor | if you are reasonably confident no problems will remain after the weekend, I think it's ok to continue |
10:57:24 | kurzhaarrocker | A design question: I believe that triggered recording _could_ be split into very little code that must reside within rockbox, and other code (most of it) that could be separated into a plugin. Would it be desirable to allow triggered recording from a plugin only? |
10:58:46 | amiconn | kurzhaarrocker: *Imho* recording is a core feature, and core features should be handled in the core. |
10:59:14 | Zagor | i agree |
10:59:18 | kurzhaarrocker | It would be slightly hazardous though as then I'd need a callback so that rockbox can pass events to the plugin |
10:59:49 | *** | Saving seen data "./dancer.seen" |
11:00 |
11:02:46 | amiconn | Zagor: I'd rather do that plugin stuff before release, because (iirc) shortly after the last release we broke api compatibility. That raised a number of "support calls" on the ml, because people wanted to flash with mixed rockbox/plugin versions, and got "incompatible version" |
11:03:57 | | Join B4gder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
11:04:19 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
11:04:19 | * | B4gder tries chatzilla |
11:04:47 | Zagor | amiconn: yes, i agree |
11:08:04 | | Join pillo [0] (~trillian@adsl-ull-93-252.46-151.net24.it) |
11:09:36 | kurzhaarrocker | (wished I had a reason that strong for including triggered recording) |
11:09:43 | Zagor | Bagder: binary db format table added |
11:10:20 | | Quit kurzhaarrocker (Read error: 104 (Connection reset by peer)) |
11:10:30 | Zagor | we should probably have a db version field too |
11:11:08 | B4gder | version field is goodness |
11:15:31 | B4gder | I'll try to adjust my perl script for this format during Agnes' afternoon nap |
11:15:41 | Zagor | great |
11:17:12 | | Join ashridah [0] (ashridah@220-253-119-223.VIC.netspace.net.au) |
11:20:43 | | Join kurzhaarrocker [0] (~none@p50876588.dip0.t-ipconnect.de) |
11:22:03 | | Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
11:22:13 | amiconn | Zagor, Bagder: Instead of adding all that mapping tables, wouldn't it be faster to just add indices that allow a binary-tree search? |
11:22:32 | Zagor | that's what we do |
11:22:43 | amiconn | Imho having all those mapping tables would bring us into a table mess |
11:22:52 | | Quit B4gder ("ChatZilla 0.9.61 [Mozilla rv:1.7.3/20040910]") |
11:22:54 | Zagor | which mapping tables? |
11:23:19 | amiconn | I read yesterday's discussion... |
11:23:43 | Bagder_ | check our zagor's updated wiki instead |
11:23:47 | Bagder_ | check out |
11:23:50 | * | amiconn checks |
11:26:55 | | Nick Zagor is now known as Zagor|lunch (~bjst@labb.contactor.se) |
11:28:16 | amiconn | Hmm. I see a problem with "array of pointers to songs" How many entries should that array have? |
11:31:30 | amiconn | I don't understand why we need different tables at all. All song info of one mp3 file is connected anyway, so imho it might be easier to use just one table, indexed on song name, artist, and album. It would be easy to add more criteria this way (year...) |
11:34:45 | kurzhaarrocker | <- knows nothing about dbs. Would the indices be separate data structures? |
11:36:02 | | Quit pillo (Read error: 104 (Connection reset by peer)) |
11:36:57 | amiconn | Yes. The index would contain the field the db table is indexed on, and a pointer into the table. |
11:38:21 | amiconn | One index should fit completely into memory, but tthat should not be a problem. Assuming a field length of 50 chars (more than id3v1 provides), it would allow ~30,000 db entries (tracks) on the Archos (~1.5 MB) |
11:38:31 | kurzhaarrocker | Would all indices (eg index for artist, year, album...) go into the same table like data structure? Or would they be stand alone and independend? |
11:39:49 | amiconn | Separate files would make updates easier, while all in one file might be better for assuring db consistency |
11:42:07 | amiconn | Hmm, for combining the results of several indices, they either have to fit together, or we would have to use an intermediate file... |
11:53:09 | amiconn | ..or don't load the complete index to ram |
12:00 |
12:01:41 | | Quit Bagder_ ("Leaving") |
12:10:04 | | Join Lynx [0] (lynx@134.95.189.59) |
12:15:55 | | Join Lynx0 [0] (lynx@134.95.189.59) |
12:23:35 | | Quit Lynx (Read error: 60 (Operation timed out)) |
12:24:06 | | Nick Zagor|lunch is now known as Zagor (~bjst@labb.contactor.se) |
12:24:18 | Zagor | amiconn: i think we are discussing different use cases. |
12:24:58 | amiconn | I don't think so |
12:25:31 | Zagor | ok, then I don't understand how you mean. how do you find all songs that are in a specific album |
12:26:10 | amiconn | You mean, from browsing the album list? |
12:26:24 | Zagor | yes, the list of albums made by a specific artist |
12:26:42 | | Quit Lynx_ (Read error: 110 (Connection timed out)) |
12:26:42 | | Nick Lynx0 is now known as Lynx_ (lynx@134.95.189.59) |
12:27:20 | amiconn | : Album list is displayed, so the album title is known. Load the album index, search for that album (binary tree search), and you'll find all songs of that album |
12:28:20 | Zagor | there will be more than one albums called the same thing made by different artists |
12:28:46 | Zagor | also, how is a search faster than a lookup? |
12:30:25 | amiconn | It's certainly not faster, but should be reasonably fast. My point is that a lookup is only possible if you use a predefined table for that relation. |
12:31:03 | Zagor | of course. why is that bad? |
12:31:17 | amiconn | Imagine how many tables that would be if you extend the concept to include artist, album, song name, year, genre, play time..., and the want to allow any combination of 2 (or 3...) criteria |
12:31:48 | Zagor | imagine how many searches you get if you *don't* have any tables |
12:32:08 | Zagor | we can't solve everything with lookup tables, but we can make the common cases much simpler and faster |
12:32:51 | amiconn | I still think searching would be relatively fast if we utilize binary search. |
12:32:51 | Zagor | it is an explicit design goal to "waste" database size if we can gain cpu time and memory use |
12:33:15 | Zagor | you still haven't explained why we should be "reasonably fast" when we can be immediate |
12:33:27 | amiconn | Many lookup tables also increase db size, which slows down seeking |
12:34:12 | Zagor | seeking is always orders of magnitudes faster than searching |
12:34:25 | amiconn | Lookup tables are not immediate either, because of the hd accesses. CPU time would be only a small fraction of that. |
12:34:50 | Zagor | you are avoiding the question. searching uses many more hd accesses than lookup. |
12:35:20 | amiconn | Not with the index in-mem approach. |
12:36:01 | Zagor | ?? how do you search an index. you need to look at the data the index indices |
12:36:28 | Zagor | and in any case, album name (for example) is not a unique data key |
12:36:49 | amiconn | Yes, but only on those that match. This has to be done with lookup as well |
12:37:04 | amiconn | I never said the key has to be unique |
12:37:15 | Zagor | arghh! lookup does not search, it reads the right data entry immediately |
12:37:40 | amiconn | You mean, each table contains all data from a song??? |
12:38:08 | Zagor | you've seen the table format suggestion |
12:39:33 | Zagor | can we get back to the issue? why do you want to use search instead of lookup? |
12:39:34 | amiconn | Yes, and there it has pointers to the rest of the song data. That means you have to load it separately -> additional hd accesses |
12:39:58 | Zagor | yes, a single access. searching requires dozens. |
12:41:11 | amiconn | No it doesn't. You load the index, search that, and find a number of mathing pointers. Then you load that data, which is (obviously) exactly the same number of entries than lookup would yield |
12:41:19 | | Quit Lynx_ (Read error: 104 (Connection reset by peer)) |
12:41:28 | Zagor | you can't search the index, you need to look at each data point: load it from disk |
12:41:43 | | Join Lynx_ [0] (lynx@134.95.189.59) |
12:41:53 | amiconn | That's the purpose of the index - searching |
12:42:25 | Zagor | you can't binary search an index. you have to look at the data to know which way to search next. |
12:43:08 | amiconn | The index contains both the index key value and the pointer, so no additional data lookup required |
12:43:30 | Zagor | right, that is exactly what my proposal contains |
12:45:47 | amiconn | Not exactly. You store album, artist, and song name separately. This requires index arrays in each of the additional tables, which raises the question of how large those arrays should be |
12:46:25 | Zagor | the array size is specified in the header. it is big enough to suit the data set. |
12:47:20 | amiconn | What if this is e.g. set to 20 tracks per album, and then an 21-track album is added? This requires re-generating the whol edb |
12:47:44 | Zagor | the database is always regenerated |
12:48:06 | kurzhaarrocker | a nightmare for the jukebox but a piece of cake for a pc |
12:48:07 | amiconn | Yes, but it should be possible on the target |
12:48:17 | Zagor | it is possible, just a lot of work |
12:48:35 | amiconn | (lunch) |
12:48:48 | Zagor | the format is designed for easy reading, not easy writing. |
12:50:26 | | Join Lynx [0] (lynx@134.95.189.59) |
12:59:53 | *** | Saving seen data "./dancer.seen" |
13:00 |
13:04:54 | LinusN | i wonder why people are so focused on generating the database ono the jukebox itself? |
13:05:24 | Zagor | beats me. store the perl script and perl.exe on the jukebox instead. |
13:05:44 | | Quit Lynx_ (Read error: 110 (Connection timed out)) |
13:05:44 | | Nick Lynx is now known as Lynx_ (lynx@134.95.189.59) |
13:05:54 | LinusN | perl.rock :-) |
13:05:58 | Zagor | haha |
13:06:05 | kurzhaarrocker | It's only interesting for freaks like me who actually record with the recorder. And - well - for searching only I don't care about databases at all. I want statistics and ratings. |
13:07:06 | Zagor | i want it too, but I don't think we should mix it with the id3 database. the statistics are long-life data that you want to make sure survives a long time. the id3 database can be recreated at any point in time. |
13:08:50 | kurzhaarrocker | that's true. And if we did as dirty things as store that statistical info in some id3 tags too even that data could be recreated. |
13:09:02 | Zagor | yes |
13:14:33 | kurzhaarrocker | But now I think you're right: it might be good to think about the statistical infos and updating / reindexing them separately. Even if we had to update an id3 tag and half a dozen db entries - for that task we have plenty of time. |
13:17:08 | amiconn | Zagor: Your db design may lead to very large index tables, if (for instance) you have many tracks by one artist, even if the number of tracks by other artists is much smaller. |
13:17:27 | Zagor | yes. we waste disk if that gains cpu or ram |
13:18:20 | * | kurzhaarrocker wastes time to gain some food now |
13:18:27 | | Part kurzhaarrocker |
13:19:00 | amiconn | Searching such a large index might take significantly longer thatn searching an index into a one-entry-per-song table. I happen to have that case on my disk - I have > 100 songs by one group |
13:19:50 | Zagor | no it won't. seeking a file will always be MUCH faster than searching it. |
13:19:55 | amiconn | LinusN: Generating the db on the box itself might be useful if you connect the jukebox to a computer that is not yours and add songs. |
13:20:17 | Zagor | amiconn: store the index program on the jukebox. then it doesn't matter what computer you connect to. |
13:20:57 | amiconn | Zagor: It does matter, or I'd have to store the index program for any CPU and OS type I might come across |
13:22:01 | amiconn | Zagor: You'd have to search the index with either approach. The only search to avoid with indexing is searching the ram table data |
13:22:04 | Zagor | come on, be real. how many operating systems do you connect to normally? |
13:22:13 | amiconn | 3 |
13:22:29 | Zagor | windows, linux and another unix? |
13:22:38 | dwihno | how about mac with os9 : |
13:22:41 | amiconn | Windows, Linux, and AmigaOS |
13:22:57 | Zagor | fine, then you need perl.exe, perl-amiga and update.pl |
13:23:01 | amiconn | s/ram table data/raw table data/ |
13:23:10 | LinusN | and you are unable to connect it to the linux box for indexing? |
13:23:13 | Zagor | amiconn: no you don't need to search with a lookup table |
13:24:03 | LinusN | Zagor and amiconn, i think you're so far apart that you need to explain your concepts from the bottom up |
13:24:14 | Zagor | my concept is in the wiki :) |
13:24:18 | LinusN | (lunch) |
13:24:27 | Zagor | but i agree, it seems we don't understand each other |
13:24:34 | amiconn | Zagor: Then it might be that I don't grasp it. |
13:24:51 | LinusN | Zagor: the wiki doesn't explain how rockbox will use the format |
13:25:16 | Zagor | LinusN: true |
13:29:10 | amiconn | I think both solutions are not too far apart. Iiuc, the wiki described format is something like that: |
13:29:54 | amiconn | First part is (apart from the table pointers) the raw data, one entry per song with all fields. |
13:30:47 | amiconn | After that there are several indices, but with only one entry for all raw data entries, containing an array of pointers to the data |
13:31:57 | | Join Tang [0] (tristang13@c211-28-75-247.frank1.vic.optusnet.com.au) |
13:31:59 | amiconn | My approach would also index the raw data, but with one index entry per raw data entry. This requires only one pointer to the raw data, and therefore avoids the problem with large pointer arrays |
13:32:35 | Zagor | why is a larges arrays a problem? |
13:32:38 | amiconn | As the index entries for the same key value would be adjacent, this should not create additional overhead |
13:33:26 | amiconn | Searching the index would be fastest if the whole index is loaded into ram. That will be obviously more difficult with large pointer arrays per entry |
13:33:58 | Zagor | the tables are not intended to ever fit in ram |
13:34:35 | Zagor | since they are sorted and fixed-size, we don't need an index to find a position |
13:35:09 | amiconn | Imho the tables towards the end *are* indices |
13:35:19 | amiconn | And: you always need to search somewhere. Otherwise, how am I supposed to find an album if I enter a string? |
13:35:56 | Zagor | yes, for freetext searching we have to use real search. but that is linear searching, which is another issue. |
13:36:46 | amiconn | We don't need linear search, unless we want to support real substring search. |
13:36:48 | Zagor | there are very few optimisations available in freetext searching |
13:36:55 | Zagor | we do want substring search |
13:38:01 | amiconn | And for linear search (substring), fitting the index table into ram should really boost performance |
13:38:07 | Tang | Hello |
13:38:21 | amiconn | hi |
13:38:25 | Zagor | yes, but we won't ever be able to do that. there will always be more song name data than we can fit |
13:38:31 | Zagor | hi tang |
13:38:52 | Zagor | especially since we want to be able to browse and search while music is playing... |
13:39:27 | LinusN | for the first step, we are only working on database *browsing* |
13:39:32 | Tang | Um, my nick is supposed to be Kuros - I posted a few ...replies on the rockbox forum - I'm about to take apart my iriver H340 |
13:39:53 | LinusN | good luck with that :-) |
13:40:01 | Zagor | LinusN: yes, but searching is trivial to add |
13:40:16 | Zagor | Tang: sounds good. have you got a flatbed scanner? |
13:40:50 | Tang | We'll see how we go - (yes I have one of those) that other guy had a bit of trouble |
13:40:59 | LinusN | Zagor: my point was that amicann was talking about searching and you were talking about browsing |
13:41:35 | Zagor | LinusN: well not really. we were both talking about browsing. he just wanted to use searching as part of the datafinding algorithm (afaui) |
13:43:04 | LinusN | some proof-of-concept is probably in order |
13:43:14 | amiconn | I don't need browsing at all for artist/album/genre. I already have that. But searching might be useful. |
13:43:18 | LinusN | "show me the code" :-) |
13:43:25 | Zagor | yes, i'm writing some code now |
13:44:41 | Zagor | amiconn: aha, so you were in fact talking about searching all along? that would explain our confusion! :-) |
13:46:14 | amiconn | Yes, but searching might also be involved for browsing with more than 1 selection criteria |
13:46:23 | Zagor | yes |
13:47:54 | amiconn | (Or adding more and more lookup tables - imagine that for every combination of 5 or more criteria!) |
13:48:10 | amiconn | That's why I suggested to have 1 index per field. The index table would be relatively small, and therefore searchable in a reasonable time |
13:48:10 | Zagor | see "unsolved issues" :) |
13:48:15 | LinusN | many lookup tables isn't a problem imho |
13:48:34 | Zagor | no but we can't solve it with just lookup tables |
13:48:57 | Zagor | or if we can, tell us how :) see the wiki for a case. |
13:49:38 | amiconn | And the create-indices-on-the-box has another reason (and this is one that could convince me to actually use the db) - adding dynamic info from playback, as kurzhaarrocker suggested |
13:50:22 | | Join alx5000 [0] (~usuariouc@salasrt.alumnos.unican.es) |
13:50:32 | alx5000 | hi |
13:50:59 | | Join Zagor_ [242] (~bjst@labb.contactor.se) |
13:51:06 | LinusN | amiconn: i think dynamic info should be in a separate database |
13:51:27 | LinusN | alx5000: hi |
13:51:53 | | Quit Zagor (Broken pipe) |
13:51:58 | alx5000 | ive got a simple question about iriver's h series processor... i was just wondering |
13:52:51 | LinusN | wondering what? |
13:52:54 | alx5000 | if it would be powerful enough to play video files |
13:53:03 | LinusN | probably |
13:53:08 | LinusN | but you' |
13:53:31 | ashridah | i'd be inclined to suspect you wouldn't get a decent framerate out of the lcd screen |
13:53:48 | LinusN | ashridah: why not? |
13:53:52 | amiconn | LinusN: Yes, although it still has to be connected to the static part in some way |
13:54:00 | LinusN | amiconn: yes |
13:54:09 | Zagor_ | we play video on the 12MHz archos today. the iriver will be a piece of cake. |
13:54:45 | LinusN | the lcd connection is parallel on the iriver, gives us quite a lot of bandwidth |
13:54:46 | Zagor_ | (if anyone wants to do it, that is. it's not exactly a #1 priority...) |
13:55:18 | ashridah | LinusN: ah, is it? kinda had the impression it wasn't. |
13:55:57 | LinusN | from the schematics? |
13:56:11 | alx5000 | Zagor_: how fast is iriver's? |
13:56:13 | ashridah | no, the update rate of some things. ;) |
13:56:27 | ashridah | but that's probably just a poorly written bit of update code in the normal firmware |
13:56:44 | LinusN | alx5000: we can adjust the cpu frequency up to about 140MHz IIRC |
13:56:56 | LinusN | but we will probably stay around 70 |
13:57:10 | Zagor_ | unless we want to encode ogg ;) |
13:57:16 | LinusN | ooooooh |
13:57:19 | ashridah | that'd be nice |
13:57:25 | Zagor_ | with emulated floating point... |
13:57:27 | ashridah | is there an integer-based ogg encoder? |
13:57:29 | Zagor_ | no |
13:57:33 | ashridah | ah. |
13:57:45 | Zagor_ | LinusN: can you kill Zagor. i'm not allowed to get op for this nick |
13:57:46 | alx5000 | so we can call video playing a feature, not a dream, then? |
13:57:55 | Zagor_ | alx5000: a possible feature |
13:57:58 | LinusN | does anybody know of a decent real-time mp3 encoder except Shine? |
13:58:05 | * | ashridah hands alx5000 a text editor and a compiler |
13:58:14 | alx5000 | ok, thank you very much, youve made my expectations grow :) |
13:58:15 | Mode | "#rockbox +o LinusN " by ChanServ (ChanServ@services.) |
13:58:29 | alx5000 | hehehe |
13:58:45 | LinusN | Zagor_: Zagor is not here according to my client |
13:58:58 | Zagor_ | ah, it left |
13:59:06 | | Nick Zagor_ is now known as Zagor (~bjst@labb.contactor.se) |
13:59:58 | alx5000 | oh, theres another stupid thing... my videocamera can output video and sound through a jack-2-rca cable... could this be coded in the firmware or is it hardware related? |
14:00 |
14:00:48 | Zagor | well... in theory we could perhaps do something with it since we've got straight input. but i just made jokes about encoding og... |
14:00:53 | Zagor | ogg |
14:01:12 | ashridah | that's a point. is there a standard for outputting video via optical out? |
14:01:36 | alx5000 | how does gmini400 do it? |
14:01:39 | Zagor | none that i know of. but i'm no video guru. |
14:01:48 | Zagor | alx5000: dedicated ports and hardware. |
14:02:08 | alx5000 | heheh ok, thats it, then |
14:02:37 | alx5000 | wish we could have both firmware and hardware upgrades :D |
14:03:15 | Zagor | free hardware is a bit harder to realise than free software :) we need some serious physics innovation first. |
14:03:40 | alx5000 | hehe |
14:03:41 | LinusN | i suggest that you hold your dreams a while, otherwise you'll be disappointed with the first iriver verison of rockbox |
14:03:58 | LinusN | it will be very basic |
14:04:24 | alx5000 | i know, but now im stuck in iriver's firmware |
14:04:29 | alx5000 | and that... sucks... |
14:04:49 | alx5000 | anything greater than zero is something to point out... |
14:05:24 | alx5000 | im reading what youve done with archos so far, and im quite amazed... |
14:06:50 | alx5000 | btw, what does Speaking Menus Support mean? |
14:07:07 | LinusN | the menu options are spoken |
14:07:11 | LinusN | a voice |
14:07:21 | alx5000 | so you can go through them "blindly"? |
14:07:32 | LinusN | it's a feature mainly for the blind |
14:07:44 | LinusN | but it's nice when you're driving a car as well |
14:08:00 | alx5000 | i see.. :O |
14:08:59 | Tang | i hate clips |
14:09:35 | | Join elinenbe [0] (~elinenbe_@65.115.46.225) |
14:10:44 | alx5000 | are you focusing on H100 series? |
14:12:00 | Zagor | yes |
14:12:13 | Zagor | Tang: clips? |
14:12:54 | | Quit alx5000 ("Download Gaim: http://gaim.sourceforge.net/") |
14:13:48 | | Join alx5000 [0] (~usuariouc@salasrt.alumnos.unican.es) |
14:14:48 | alx5000 | back again... |
14:15:03 | Tang | yeah, those silly little plastic things you have to push a bit to disengage the chip board |
14:15:37 | alx5000 | heh |
14:22:05 | alx5000 | sorry for asking so much, but... how much storage space / memory do you have in h100 for firmware? |
14:22:21 | Zagor | 2MB flash |
14:22:27 | alx5000 | aha... |
14:22:41 | Zagor | and then a whopping 32 MB ram... |
14:23:04 | alx5000 | and how much of those 32 are used during normal playing? |
14:23:12 | Zagor | all of it |
14:23:16 | alx5000 | ok :D |
14:23:21 | Zagor | we always use all ram |
14:23:44 | Zagor | more ram just means larger buffers for mp3 etc |
14:23:54 | LinusN | and less disk activity |
14:24:02 | Zagor | less frequent anyway ;) |
14:24:08 | LinusN | meaning longer battery life |
14:25:24 | alx5000 | thats a point... |
14:27:31 | elinenbe | LinusN: how are your h100 commits coming? |
14:28:03 | | Join langhaarrocker [0] (~none@p50876588.dip0.t-ipconnect.de) |
14:28:04 | LinusN | haven't had time to test drive the code on the target |
14:28:24 | LinusN | (baan sick, actually) |
14:28:27 | LinusN | been |
14:30:36 | dwihno | huge mpeg buffer! me loves it |
14:30:38 | | Nick langhaarrocker is now known as kurzhaarrocer (~none@p50876588.dip0.t-ipconnect.de) |
14:32:15 | | Nick kurzhaarrocer is now known as kurzhaarrocker (~none@p50876588.dip0.t-ipconnect.de) |
14:32:28 | Zagor | got a haircut? |
14:33:53 | kurzhaarrocker | Yes, I entangled myself, but thanks to nickserv I'm free again. |
14:36:09 | Tang | obviously the people who fix up these things have about seven hands... |
14:36:48 | Tang | I've just come to a revelation - the front cover comes off as well as the back |
14:38:17 | * | kurzhaarrocker passes Tang an electric axe |
14:39:22 | Tang | thanks - as much as I'd like to right now, I still want to listen to music later |
14:39:46 | alx5000 | heh |
14:43:37 | kurzhaarrocker | Something completely else: I know there's an out of date _plugin_ for editing id3 info. If it's a plugin - how can we edit the id3 info while recording? bummer. |
14:44:50 | Zagor | you mean right now, or conceptually? |
14:45:10 | | Part alx5000 |
14:45:28 | kurzhaarrocker | As the plugin is out of date: conceptually. Should we allow plugins while recording? |
14:46:06 | kurzhaarrocker | Or should id3 editing - just like recording - be considered part of the firmware? |
14:47:02 | Zagor | well we can't edit the actual tag while recording, since we don't want to mess with the file. but we could edit a dummy file, from which the tag is copied after recording is complete. |
14:47:30 | Zagor | I'm not sure how much the gui thread is part of the recording process, if any. |
14:48:18 | kurzhaarrocker | as soon as it comes down to _triggered_ recording there is a problem with that approach of mine. |
14:48:52 | amiconn | Zagor: We could hold the (edited) tag in memory. It is only a few 100 bytes |
14:49:44 | * | Tang |
14:49:53 | kurzhaarrocker | ... especially as the tags for freshly recorded files don't contain any bitmaps and stuff... |
14:49:53 | Zagor | yes, but we have no mechanism to pass memory between the core firmware and a plugin. |
14:50:18 | Zagor | i'd like to use the same editor for new recordings and regular files |
14:50:36 | Zagor | and the easiest way is probably to use a dummy file for recording |
14:50:46 | * | Tang scratches the itch to throw the iriver out the window |
14:50:51 | LinusN | why is it necessary to edit the tag while recording? |
14:51:01 | * | Tang sighs |
14:51:08 | LinusN | can't that wait until afterwards? |
14:51:10 | kurzhaarrocker | Because you have time while you record, LinusN |
14:51:40 | LinusN | It should be fairly easy to implement |
14:51:44 | amiconn | Zagor: Then make it part of the core |
14:52:00 | Lynx_ | Tang: more clips? ;) |
14:52:07 | LinusN | the VBR info is updated when the recording ends, the ID3 tag could be changed at that time |
14:52:08 | Tang | The best I can do for the moment is tell you what harddisk it's got... but that doesn't help, does it |
14:52:25 | Zagor | i think an id3 tag is an ideal candidate for a plugin |
14:52:27 | LinusN | Tang: not really |
14:52:28 | Zagor | editor |
14:52:35 | LinusN | an editor, yes |
14:52:47 | Tang | hmm |
14:53:06 | | Join elinenbe_ [0] (~elinenbe_@65.115.46.225) |
14:53:07 | | Quit elinenbe (Read error: 104 (Connection reset by peer)) |
14:53:10 | | Nick elinenbe_ is now known as elinenbe (~elinenbe_@65.115.46.225) |
14:53:48 | kurzhaarrocker | And that editing becomes really interesting when you have timed recording and a file split happens while you're editing :) |
14:54:20 | Zagor | no problems if we use a dummy file |
14:56:01 | LinusN | starting a plugin while recording is a bad idea imho |
14:56:14 | LinusN | the time split is done by the main thread |
14:56:50 | Zagor | would it be ugly to move? |
14:56:54 | LinusN | i think a simple interface for entering title and artist in the recording screen would be sufficient |
14:57:09 | LinusN | then a "real" editor in a plugin |
14:57:58 | LinusN | i remember having difficulties moving the split to the mpeg thread, but i can't remember what it was |
14:59:19 | LinusN | i think the split belongs in the mpeg thread |
14:59:35 | kurzhaarrocker | With volume triggered recording it would be difficult to - unless we want separate read outs for the peak meter and trigger detection. |
14:59:38 | LinusN | the main thread should just monitor the recording |
14:59:53 | LinusN | kurzhaarrocker: true |
14:59:57 | *** | Saving seen data "./dancer.seen" |
15:00 |
15:01:38 | * | kurzhaarrocker still thinks that the peak value read out should have its own thread. |
15:02:08 | LinusN | because...? |
15:03:21 | kurzhaarrocker | For example the peakValueThread could fire trigger events and the peak meter might become more precise. |
15:03:47 | LinusN | because...? |
15:04:40 | kurzhaarrocker | because we could read out more often because the read out would be decoupled from updating the gui. The peak meter wouldn't poll, just draw. |
15:05:25 | LinusN | i don't get it, the gui takes just as long to update regardless if the peak meter is in a separate thread or not |
15:06:08 | kurzhaarrocker | Don't we have tick threads? (it's been a while...) |
15:06:13 | LinusN | no |
15:06:36 | LinusN | simple round-robin cooperative threads |
15:07:37 | * | kurzhaarrocker shuts up for a while |
15:07:52 | LinusN | :-) |
15:09:54 | amiconn | LinusN: There are tick tasks... |
15:10:55 | * | kurzhaarrocker sees something strange called IMIAO which he thought was something thread related, triggerd by a hw timer via interrupt. |
15:12:21 | amiconn | kurzhaarrocker: IMIA0 is the isr called by timer 0 interrupt |
15:13:14 | kurzhaarrocker | And is it an absolute nono to use that every nth time to read out the peak value? |
15:15:52 | amiconn | You should not do such a thing directly in the isr. Instead, use tick_add_task() to add a function that is called every 10 ms |
15:16:24 | LinusN | amiconn: i wrote the kernel, i know that you can add a "tick task" |
15:16:48 | LinusN | but a task that talks i2c with the MAS is out of the question |
15:17:16 | kurzhaarrocker | Due to timing? |
15:17:37 | LinusN | a MAS conversation can take several milliseconds |
15:17:43 | amiconn | LinusN: Ah ok. Of course i2c from interrupt is not allowed, silly me |
15:18:00 | LinusN | and the i2c driver uses a locking mechanism that can only be run by background threads |
15:18:49 | amiconn | I should know that (from my backlight dimming experiments); using i2c from interrupt may even lock up the box as soon as lcd access is going on in parallel |
15:18:58 | LinusN | still, i can see one valid reason to have a separate thread for the peak data |
15:19:31 | LinusN | and that is the peak trigger event business |
15:20:17 | kurzhaarrocker | Currently I implemented that using a callback function in the peak meter code. |
15:21:28 | kurzhaarrocker | -> works only when the peak meter is being displayed. |
15:23:31 | amiconn | That thread would only be needed when triggered recording is actually used. Threads can be started and ended dynamically iirc |
15:27:40 | kurzhaarrocker | The thread would be needed too as soon as a peak meter is displayed or we'd end up in separate read outs for peak meter and trigger again. |
15:30:10 | amiconn | Okay |
15:34:07 | amiconn | The thread may also be present all the time (or as soon as the peakmeter is used for the first time), but then it should only read the values when necessary |
15:34:34 | LinusN | gotta go |
15:34:36 | LinusN | cu guys |
15:34:52 | | Part LinusN |
15:36:56 | | Quit ashridah ("sleep") |
15:40:28 | | Join zapotech [0] (zazz@dh051-118.chem.sunysb.edu) |
15:41:06 | Tang | ok, I don't think I can scan this, but I have some photos of it |
15:42:27 | Zagor | nice. uploaded anywhere? |
15:42:53 | Tang | Umm... |
15:43:32 | Tang | I don't know where to upload 'em ...I'm not sure of the best way.. |
15:43:46 | Zagor | you can upload them to our wiki if you like |
15:46:07 | Tang | ok... sounds ok - if I run into the hard wall of confusion and ignorance, I'll give you a bell |
15:49:42 | | Join Audiophil [0] (~dsads@213.236.154.41) |
15:49:58 | Audiophil | er dere svenske? |
15:50:00 | Audiophil | tøft :D |
15:51:24 | Zagor | Audiophil: some of us are, but the majority isn't. so we speak english here. |
15:51:33 | zapotech | alla svenskar suger fett..!! :) |
15:51:39 | Audiophil | ok |
15:52:14 | Audiophil | regarding iriver, will it be possible to reinstall the iriver software if you somehow want to do that? |
15:52:55 | Zagor | yes |
15:54:08 | Tang | It should work the same as the usual firmware upgrade - I accidently upgraded the firmware for my iriver to two releases before the one that came in the box |
15:54:17 | Audiophil | sweet |
15:54:36 | Audiophil | so how's the status on an iriver release? |
15:55:09 | Zagor | far away. we've just barely ran any code on it yet. |
15:56:39 | Zagor | maybe something early can be release around christmas, if things are going well |
15:57:25 | | Part kurzhaarrocker |
15:58:20 | Audiophil | oh :/ |
15:58:28 | Audiophil | well, keep up the good work |
16:00 |
16:06:17 | | Join Lynx [0] (lynx@134.95.189.59) |
16:22:44 | | Quit Lynx_ (Read error: 110 (Connection timed out)) |
16:22:45 | | Nick Lynx is now known as Lynx_ (lynx@134.95.189.59) |
16:23:54 | | Quit Audiophil (Read error: 238 (Connection timed out)) |
16:47:20 | | Join mecraw_ [0] (~lmarlow@69.2.235.2) |
16:56:34 | Tang | ok, I've hit that wall.... this is the first time I've ever put something on a wiki before - I've only ever read up on stuff before |
16:57:11 | Zagor | i see you registered sucessfully |
16:57:59 | Zagor | i suggest you upload to the IriverInfo page. we can always move it later if we want. |
16:58:12 | Zagor | go to that page, then click "attach" and follow the instructions |
16:59:58 | *** | Saving seen data "./dancer.seen" |
17:00 |
17:16:09 | | Quit einhirn (Read error: 54 (Connection reset by peer)) |
17:16:21 | Tang | ok |
17:22:00 | Tang | Is there a size limit? |
17:25:55 | Zagor | i don't think so |
17:25:59 | | Quit gromit`` (Read error: 110 (Connection timed out)) |
17:26:07 | | Join gromit` [0] (~gromit@ALagny-151-2-7-194.w82-121.abo.wanadoo.fr) |
17:26:13 | Zagor | are they huge? |
17:27:03 | Tang | not too huge - but they have different focus on different spots, so there is a few of them |
17:27:26 | Zagor | ok |
17:27:28 | Tang | 19Mb ? |
17:27:34 | Zagor | each? |
17:27:43 | Tang | alltogether |
17:27:47 | Zagor | ok, no problem |
17:30:33 | Zagor | i've gotta go. see you later. |
17:30:34 | | Part Zagor |
17:33:14 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
17:36:42 | Tang | Goodnight to those people who saw me log on - and good night to the computers of whos owners neglect to turn off |
17:37:06 | Tang | ....I'm tired. |
17:38:08 | | Part Tang |
17:40:48 | | Quit Lynx_ (" HydraIRC rocks! -> http://www.hydrairc.com <-") |
18:00 |
18:05:39 | | Quit einhirn (Read error: 54 (Connection reset by peer)) |
18:08:31 | | Join methangas [0] (methangas@0x50c61d43.virnxx10.adsl-dhcp.tele.dk) |
18:11:35 | | Join webguest75 [0] (~c7e73280@labb.contactor.se) |
18:11:45 | webguest75 | hello |
18:11:52 | | Quit elinenbe (" I love my HydraIRC -> http://www.hydrairc.com <-") |
18:12:25 | webguest75 | small question: why is the usb cable for the archos not standard? |
18:12:36 | webguest75 | is there any good tech reason? |
18:14:24 | | Join millow [0] (~millow@67.227.adsl.i4surf.net) |
18:25:06 | | Quit webguest75 ("CGI:IRC (EOF)") |
18:41:19 | | Part amiconn |
19:00 |
19:00:02 | *** | Saving seen data "./dancer.seen" |
19:24:36 | | Join ScrpWork [0] (~Naikel@naikel.ogangi.com) |
19:24:44 | ScrpWork | hi fellas |
19:25:41 | | Part millow |
19:40:46 | | Join _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
19:40:51 | _aLF | hi |
20:00 |
20:03:41 | | Join dropandhop [0] (~43646aab@labb.contactor.se) |
20:56:53 | | Join Farbrausch [0] (~d95871be@labb.contactor.se) |
20:58:43 | Farbrausch | hello |
21:00 |
21:00:04 | *** | Saving seen data "./dancer.seen" |
21:00:39 | | Quit Farbrausch (Client Quit) |
21:03:28 | ScrpWork | nobody ever talks here? |
21:16:20 | | Join PoDDaN^ [0] (~d9d111c6@labb.contactor.se) |
21:16:26 | PoDDaN^ | hi all |
21:16:40 | PoDDaN^ | can anyone help me out with one thing? |
21:26:42 | | Quit _Lucretia (Connection timed out) |
21:27:03 | | Join _Lucretia [0] (~munkee@abyss2.demon.co.uk) |
21:27:56 | | Quit PoDDaN^ ("CGI:IRC") |
21:34:28 | | Join kurzhaarrocker [0] (~none@c-134-121-140.d.dial.de.ignite.net) |
21:35:22 | kurzhaarrocker | My battery has burst. |
21:38:02 | Ka_ | anyone had an archos recorder 2.0 just not turn on or show any signs of life after leaving it sit around for a month .. (and after charging it to make sure it was dead batteries :) ) |
21:38:54 | kurzhaarrocker | Dead batteries are the most common cause for any hw fault of the thingies. |
21:39:36 | Ka_ | with the power adapter plugged in it should power on even without batteries.. it doesn't do that either.. |
21:41:05 | kurzhaarrocker | The adapter alone doesn't provide enough power to operate the jukebox. Without batteries it won't spin up even with the adapter connected. |
21:41:30 | Ka_ | but the screen lights up with the adapter plugged in |
21:41:50 | Ka_ | that doesn't require the batteries.. or at least so i've read |
21:41:54 | kurzhaarrocker | Yes, but probably there's not enough current to make the hd work. |
21:42:53 | kurzhaarrocker | The V2 unit is that thingie with the built in Lithium batteries, isn't it? |
21:43:12 | _aLF | yes |
21:43:13 | Ka_ | but i can't even get the screen to light up.. from what i've read it should at least do that.. |
21:43:21 | | Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
21:43:23 | Ka_ | it has 4 replaceable batteries |
21:44:29 | kurzhaarrocker | Have you tried another set of batteries? |
21:44:54 | Ka_ | i just found out this thing wasn't working like 2 hours ago.. i haven't opened it up yet to get to the batteries.. |
21:45:00 | Ka_ | i'm about to do that.. |
21:47:23 | ScrpWork | hi |
21:47:57 | kurzhaarrocker | hi |
21:48:06 | ScrpWork | how's it going over here |
21:48:31 | kurzhaarrocker | It's quite calm now |
21:50:22 | ScrpWork | what are the latest new on H120 unscramle |
21:50:24 | ScrpWork | unscramble |
22:00 |
22:01:50 | Ka_ | wouldn't you just know it?! i can't find a screwdriver small enough to fit these screws.. |
22:02:49 | Ka_ | now i could *probably* use a hammer to get it open but that may lead to *other* issues with the device |
22:05:12 | | Quit methangas (" I love my HydraIRC -> http://www.hydrairc.com <-") |
22:05:19 | scott666 | archoses are supprisingly hard to open with a hammer... |
22:06:02 | Ka_ | if this isn't working in the next few days i just may find out for myself just how hard.. |
22:08:48 | | Join njsges [0] (~njsges@adsl-18-121-126.sdf.bellsouth.net) |
22:08:57 | njsges | afternoon |
22:16:10 | | Quit kurzhaarrocker (Read error: 110 (Connection timed out)) |
22:19:38 | dropandhop | hey all! |
22:19:57 | dropandhop | any suggestions as to how i can help the crew with the iriver...i can't code |
22:22:36 | ScrpWork | give them an H120 for free |
22:22:43 | ScrpWork | that'll help them out a lot |
22:23:04 | Bagder | consider a donation |
22:23:20 | Bagder | to allow us to buy more hw to work with |
22:30:25 | njsges | anyone available to answer a few questions about archos and iriver pmp's? |
22:30:45 | ScrpWork | just shoot them, maybe somebody knows |
22:30:47 | Bagder | pmp? |
22:31:59 | Bagder | personal music player? |
22:33:49 | njsges | the personal media players |
22:34:14 | njsges | i'm looking to get one to use in conjunction with my digital camera and storing images |
22:34:34 | njsges | as well as use it to listen to music as well as to record meetings |
22:34:43 | njsges | any suggestions on what to get? |
22:35:01 | ScrpWork | how can yo use an mp3 player in conjuction with a digital camera? |
22:35:04 | Bagder | neither archos nor iriver will help you with the camera problem |
22:35:20 | Bagder | ScrpWork: if it could server as a usb host |
22:35:24 | Bagder | serve |
22:35:53 | njsges | will either one work as a direct storage device from my dig camera to the device? |
22:35:58 | njsges | via usb |
22:36:11 | njsges | or will one of the iriver h120 or h320 work? |
22:36:13 | Bagder | neither one |
22:36:21 | Bagder | no |
22:36:22 | Bagder | none |
22:36:39 | njsges | the archos i believe does have a card reader on tthe side |
22:36:42 | Bagder | they are slaves, and so is the camera |
22:37:06 | Bagder | oh, right some newer multimedia models have such |
22:37:15 | Bagder | I can't speak about them, as rockbox doesn't run on them |
22:37:33 | njsges | it runs on the earlier versions of the archos products |
22:37:37 | njsges | correct? |
22:37:52 | Bagder | yes |
22:38:11 | njsges | would any of the earlier models be a better fit for what i'm trying to do? |
22:38:43 | Bagder | just about every unit on the market can do the other things, hardly any can store images from a camera |
22:38:49 | Bagder | I mean directly over usb |
22:38:56 | njsges | ok |
22:40:17 | njsges | rockbox supports the early jukebox players |
22:40:25 | njsges | not the gmini or av's |
22:40:37 | Bagder | " Rockbox is an Open Source replacement firmware for the Archos Jukebox 5000, 6000, Studio, Recorder, FM Recorder and Recorder V2 MP3 players." |
22:40:59 | * | Bagder detects a lack of "Ondio" in there |
22:44:18 | Bagder | and here are the hard facts: http://www.rockbox.org/docs/devicechart.html |
22:44:24 | Bagder | on all supported models |
22:53:25 | njsges | cool |
22:53:28 | njsges | thank you |
22:54:12 | | Join iRiverMan [0] (~acbe7dfd@labb.contactor.se) |
22:54:17 | iRiverMan | hi |
22:56:30 | | Part njsges |
22:56:56 | ScrpWork | yo |
23:00 |
23:00:08 | *** | Saving seen data "./dancer.seen" |
23:08:01 | | Join Gamefreak [0] (~Gamefreak@pcp0010543349pcs.cnorth01.va.comcast.net) |
23:08:10 | Gamefreak | Heya. |
23:08:33 | ScrpWork | yo |
23:08:54 | | Quit gromit` (Read error: 104 (Connection reset by peer)) |
23:09:02 | Gamefreak | Just a tad curious, being the slave to the oppression that is iRiver, when I can expect to see the Rockbox port. |
23:09:18 | Gamefreak | And for that matter if I can help. |
23:09:31 | _Lucretia | Gamefreak, think yourself lucky, at least there's a port in progress for iRiver :-( |
23:09:38 | Gamefreak | lol |
23:09:52 | ScrpWork | I would just like a working simulator and some bit of documentation so I can make my own firmware |
23:09:57 | ScrpWork | I have to wait a lot for that as well heh |
23:10:36 | Bagder | the simulator works for iriver |
23:10:51 | | Join gromit` [0] (~gromit@ALagny-151-2-7-194.w82-121.abo.wanadoo.fr) |
23:11:06 | Bagder | or, at least is should |
23:11:09 | Bagder | it |
23:11:55 | Bagder | Gamefreak: there's basically only one developer working on iriver code, so it is gonna take a while before there will be anything reallt fun to see |
23:14:19 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
23:16:24 | ScrpWork | after all hardware functions are documented some people can code an Hxxx simulator :) |
23:17:39 | Bagder | we already have one |
23:17:39 | Bagder | read my words |
23:17:39 | Bagder | we have a set of APIs already |
23:18:55 | Bagder | docs/API is a basic embryo at some docs |
23:19:35 | ScrpWork | correct me if I'm wrong but I thought you had a Motorola 5249 emulator |
23:19:52 | ScrpWork | not a Hxxx simulator (simulates LCD, keyboard input, audio output, etc) |
23:20:06 | Bagder | we have a simulator |
23:20:11 | ScrpWork | of the whole thing? |
23:20:13 | Bagder | that simulates the lowlevel stuff |
23:20:16 | ScrpWork | oh |
23:20:21 | Bagder | and makes it possible to write code on host |
23:20:27 | Bagder | we've had it for years |
23:20:36 | Bagder | and it has been adjusted to simulate iriver as well |
23:20:38 | iRiverMan | what about the iRiver's remote? |
23:20:49 | Bagder | that is still left todo |
23:21:02 | iRiverMan | since the LCD on the remote mirrors the main LCD |
23:21:09 | Bagder | it doesn't |
23:21:16 | Bagder | it only does that with irivers fw |
23:21:22 | Bagder | we don't have to do that |
23:21:44 | iRiverMan | so does that mean the LCD on the remote becomes redundant? |
23:21:44 | Bagder | afaik |
23:21:47 | ScrpWork | well but it would be cool if it simulates the whole thing, so you can see a JPEG of a iRiver and use a directory of the HDD as the simulated HDD of the stuff |
23:21:49 | Bagder | uh? |
23:22:05 | ScrpWork | you put the original firmware and you could even get audio through your soundcard emulating the DACs |
23:22:09 | Bagder | ScrpWork: that is basically what we have |
23:22:27 | Bagder | ScrpWork: no, that makes it an emulator and that we don't have ;-) |
23:22:37 | Bagder | iRiverMan: why would that be? |
23:22:45 | iRiverMan | Bagder do u have an iriver? |
23:22:52 | Bagder | why? |
23:23:06 | iRiverMan | the iriver isn't very good at shuffling playlists |
23:23:11 | iRiverMan | always plays the same songs |
23:23:16 | ScrpWork | but that would be great :) if all the hardware functions are documented you can find some people interested in coding a full emulator |
23:23:17 | iRiverMan | No problem shuffling the HD though |
23:23:20 | Bagder | you make no sense iRiverMan |
23:23:26 | iRiverMan | why not? |
23:23:32 | ScrpWork | shuffling in an iRiver is just non existant. |
23:23:35 | ScrpWork | it doesn't have randomness |
23:23:39 | ScrpWork | since it doesn't have a clock |
23:23:39 | iRiverMan | it does |
23:23:41 | Bagder | so they say |
23:23:43 | Bagder | rockbox will |
23:23:53 | ScrpWork | I have an H120 that's why I'm here in this very channel :) |
23:23:55 | iRiverMan | iRiver does have a shuffle mode |
23:24:01 | iRiverMan | doesn't work very well on playlists though |
23:24:02 | ScrpWork | yeah but shuffle without randomness |
23:24:09 | ScrpWork | doesn't work very well on anything |
23:24:10 | iRiverMan | you have lost me |
23:24:12 | ScrpWork | not even on directories |
23:24:29 | ScrpWork | shuffle only put the songs in the same order and makes you think it randomize them |
23:24:44 | ScrpWork | but no, just changed the order and it will always be the same order until you delete or upload a new song |
23:25:00 | iRiverMan | well i found a way is to manually shuffle a playlist in Winamp |
23:25:02 | ScrpWork | so it's shuffling without randomness hehe |
23:25:05 | ScrpWork | yeah |
23:25:07 | ScrpWork | that's a workaround |
23:25:25 | iRiverMan | But i still think its a better machine than the archos |
23:25:28 | ScrpWork | people shuffle the playlists several times each and upload all the results to the H120 |
23:25:35 | ScrpWork | but that sucks |
23:25:41 | Bagder | it certainly is lame |
23:25:41 | ScrpWork | of course it's the best mp3 player ever |
23:25:52 | iRiverMan | i like the construction of the iriver |
23:25:57 | iRiverMan | much better than others |
23:27:36 | ScrpWork | yeah |
23:27:43 | ScrpWork | well an emulator would be great |
23:27:49 | ScrpWork | I could even help myself to code one |
23:27:49 | iRiverMan | i have an iriver ihp-120 |
23:28:01 | ScrpWork | then we can write our own firmwares based on the basic stuff |
23:28:19 | Bagder | so write one! |
23:28:49 | Bagder | it'll be a major job |
23:28:50 | ScrpWork | I would need a precise documentation of the functionality of all the hardware. An emulator has to emulate everything, not only the CPU, but all the other controllers |
23:29:05 | Bagder | work your way ahead |
23:29:10 | ScrpWork | I would suggest a subteam of volunteers to do that and not bother the core developers |
23:29:10 | Bagder | read the docs we have |
23:29:50 | ScrpWork | I have, but I'm still unsure heh |
23:29:56 | Bagder | so are we |
23:29:57 | ScrpWork | anyway I gotta go home maybe I'll connect from there |
23:30:03 | ScrpWork | cya :) |
23:30:04 | | Quit ScrpWork ("Scorpius MultiServer Script v0.1 for mIRC 6") |
23:30:12 | | Quit Gamefreak (Read error: 110 (Connection timed out)) |
23:30:30 | | Quit dropandhop ("CGI:IRC") |
23:37:30 | | Join gromit`` [0] (~gromit@ALagny-151-2-7-194.w82-121.abo.wanadoo.fr) |
23:37:31 | | Quit gromit` (Read error: 104 (Connection reset by peer)) |
23:40:32 | Bagder | time to sleep |
23:40:38 | iRiverMan | night |
23:46:34 | | Join Lucretia_ [0] (~munkee@abyss2.demon.co.uk) |
23:55:50 | | Quit _Lucretia (No route to host) |