| 00:00:19 | rasher | silly washer |
| 00:00:46 | Rick | hehe |
| 00:00:55 | Rick | I was thinking about the backlight for the remote |
| 00:01:05 | Rick | should it be synced with the main unit backlight, or should it have it's own thing? |
| 00:01:21 | Rick | (iriver has it synced, or whatever you want to call it) |
| 00:01:38 | preglow | sounds like a nice option |
| 00:01:52 | rasher | wait.. did I just manage to close the window and open again without getting thrown off irc? |
| 00:01:59 | Rick | No |
| 00:02:04 | Rick | [02:59:35 PM] * rasher (~3e4f4094@labb.contactor.se) Quit ("CGI:IRC") |
| 00:02:04 | Rick | [02:59:52 PM] * rasher (~3e4f4094@labb.contactor.se) has joined #rockbox |
| 00:02:07 | rasher | ah |
| 00:02:25 | rasher | just don't see it in the logs |
| 00:02:52 | rasher | I'd say let it be optional whether or not to sync |
| 00:02:57 | Rick | ah |
| 00:03:06 | Rick | from what I know there's a thread in the background that does the backlight stuff |
| 00:03:09 | Rick | for the main unit |
| 00:03:24 | rasher | I'd probably leave it unsynced, but I guess others won't |
| 00:03:39 | Rick | dunno, I personally would want it unsynced |
| 00:03:51 | Rick | waste of power to turn on the main unit's backlight if you're using the remote, and vice versa, no? |
| 00:04:12 | rasher | That's my thinking as well |
| 00:04:28 | Rick | how much power would the backlight use though? |
| 00:04:37 | rasher | absolutely no idea |
| 00:04:48 | Rick | Hehe |
| 00:05:00 | Rick | I guess it's back to figuring out how to turn on the lcd |
| 00:05:11 | Rick | I was thinking about it |
| 00:05:23 | Rick | I would think that the remote lcd would use the main unit's power right? |
| 00:05:24 | Rick | not internal? |
| 00:05:42 | rasher | Can't see how that'd work |
| 00:05:49 | Rick | not sure |
| 00:05:57 | Rick | from the spec, there's two power modes |
| 00:06:01 | Rick | internal, and external (basically) |
| 00:06:42 | Rick | then again I could be misunderstanding the spec and not doing the commands to the lcd correctly |
| 00:07:34 | rasher | Hrm, the scroll setting example texts need to be longer :) |
| 00:07:54 | preglow | Rick: backlight is one of the major power drains |
| 00:08:02 | Rick | preglow: ah |
| 00:08:25 | Rick | http://rick.gibbed.us/lcd-h100-remote.c |
| 00:08:30 | Rick | latest code... |
| 00:08:37 | preglow | Rick: i think this sounds like a fine setting, and i don't think it should be very hard to implement it as a setting |
| 00:08:42 | Rick | the stuff for init'ing the lcd is at the bottom |
| 00:08:49 | Rick | (commented out) |
| 00:08:50 | rasher | preglow: Speaking of power.. I had the backlight on during my battery tests as well |
| 00:08:56 | preglow | rasher: ouch.. |
| 00:09:06 | preglow | rasher: that probably shaved off an hour or who |
| 00:09:09 | rasher | well I wanted them to happen as fast as possible :) |
| 00:09:10 | preglow | two <- |
| 00:09:21 | rasher | goodie |
| 00:09:22 | preglow | well, yes, the drain is constant |
| 00:09:34 | preglow | so it would just be to add a constant to all the graphs |
| 00:09:36 | rasher | That's good news then |
| 00:09:43 | preglow | and you'd have graphs without backlight as well |
| 00:09:55 | rasher | no point |
| 00:09:58 | preglow | that is, scale the graphs with a constant |
| 00:09:59 | preglow | ehh |
| 00:10:15 | rasher | since it wasn't to test the battery life |
| 00:10:17 | preglow | surprises me greatly that you conclude there's no point :P |
| 00:10:22 | Rick | I thought the graphs were just to understand the value of the battery indicator... or whatever the proper name for it is |
| 00:10:31 | preglow | Rick: that's right |
| 00:10:31 | rasher | What Rick said |
| 00:10:32 | Rick | so you could properly indicate the status |
| 00:10:47 | rasher | the result would be the same with or without the backlight |
| 00:10:50 | preglow | then i really don't see why you did the no harddrive tests |
| 00:10:51 | Rick | right |
| 00:11:27 | rasher | Hrm |
| 00:11:31 | rasher | not sure |
| 00:11:42 | preglow | i'll answer it for you: because linus asked for them |
| 00:11:42 | preglow | heh |
| 00:11:47 | rasher | :) |
| 00:11:56 | rasher | I wonder if I told him that I had the LCD on |
| 00:12:02 | preglow | i don't think he cares |
| 00:12:04 | rasher | possibly not |
| 00:12:12 | preglow | the backlight might actually have had some impact |
| 00:12:14 | Rick | Any idea when LinusN will be getting back? :p |
| 00:12:25 | preglow | Rick: tomorrow, round 08:00 |
| 00:12:27 | rasher | he might not for another 7 hours |
| 00:12:30 | Rick | ah |
| 00:12:38 | Rick | I saw that he came on briefly around noon here |
| 00:12:44 | rasher | he occasionally drops in in the evening, but rarely |
| 00:12:48 | Rick | ah |
| 00:12:51 | rasher | (midnight here) |
| 00:12:59 | * | Rick nods |
| 00:13:10 | Rick | I don't have class tommorow so I'll probably be up still ;P |
| 00:13:13 | preglow | Rick: but he's widely available from about 07:00 to 15:30 gmt+1 weekdays |
| 00:13:17 | preglow | so shouldn't be a problem |
| 00:13:20 | * | Rick nods |
| 00:13:31 | Rick | He was giving me a lesson last night (in my timezone) |
| 00:13:37 | preglow | this morning, yes :) |
| 00:13:41 | * | Rick nods |
| 00:13:47 | Rick | very early morning for me ;) |
| 00:14:24 | Rick | I wonder if this spec is incorrect in the instruction table |
| 00:14:44 | rasher | Always blame the specs first :) |
| 00:14:49 | Rick | well |
| 00:15:00 | Rick | I was taking a look at the other lcd stuff (okay, they could be different) |
| 00:15:16 | Rick | but, some of the instructions, they send the instruction first, then the data afterwards |
| 00:15:21 | Rick | but this spec says to send it as a command |
| 00:15:22 | Rick | not data |
| 00:15:32 | rasher | grr.. hdd spin-up time is annoyingly long |
| 00:15:37 | Rick | At least that's how i'm interpreting it |
| 00:15:59 | rasher | I'll gladly be of no help at all :) |
| 00:16:02 | Rick | hehe |
| 00:16:05 | Tang_ | rick |
| 00:16:11 | Rick | yes Tang_? |
| 00:16:12 | Tang_ | youre rick la charité? |
| 00:16:16 | Rick | yes |
| 00:16:16 | Tang_ | (hello) |
| 00:16:21 | Rick | hello |
| 00:16:28 | Tang_ | thanks for the remote LCD driver |
| 00:16:29 | Tang_ | :) |
| 00:16:35 | Rick | hehe, it's not in working state yet |
| 00:16:39 | Rick | but i'm getting there |
| 00:18:00 | | Quit Aison` ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )") |
| 00:19:24 | Tang_ | :) |
| 00:21:47 | rasher | Tang_: the font is now in daily builds :) |
| 00:22:00 | Tang_ | :) |
| 00:22:03 | Tang_ | thanks rasher |
| 00:22:04 | Tang_ | :) |
| 00:25:02 | | Join ashridah [0] (ashridah@220-253-121-169.VIC.netspace.net.au) |
| 00:25:34 | rasher | hm, rockbox_default has a few holes |
| 00:25:42 | Rick | define hole? |
| 00:26:07 | rasher | Blank character |
| 00:26:20 | Rick | ah |
| 00:26:46 | rasher | or maybe these are just differences between iso8859-15 and -1 |
| 00:27:14 | rasher | oh, no |
| 00:27:23 | rasher | rockbox_default looks like -15 |
| 00:27:56 | rasher | has the euro-sign at least |
| 00:27:59 | rasher | oh well |
| 00:34:33 | | Quit gromit` (Read error: 104 (Connection reset by peer)) |
| 00:34:41 | preglow | only difference between -1 and -15 _is_ the euro sign |
| 00:36:41 | rasher | hm, I'm pretty sure there are a few other differences that you never notice |
| 00:36:45 | rasher | I.. think, at least |
| 00:37:58 | preglow | i'm pretty certain it's correct |
| 00:38:12 | rasher | hm, google agrees with you |
| 00:38:48 | preglow | well, i no longer agree with myself |
| 00:39:35 | preglow | wikipedia claims some other characters have been replaced as well |
| 00:39:41 | rasher | ah |
| 00:39:49 | rasher | so maybe I was right afterall |
| 00:39:55 | preglow | indeed |
| 00:40:53 | rasher | http://en.wikipedia.org/wiki/Latin-9 aha |
| 00:41:35 | rasher | Simpsons! |
| 00:43:06 | preglow | is boring... |
| 00:44:08 | rasher | well I was deprived as a kid |
| 00:44:53 | | Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
| 00:45:05 | preglow | nah, just newer episodes that are boring |
| 00:45:26 | rasher | no idea if these are new or old episodes |
| 00:45:56 | rasher | looks old |
| 00:46:13 | rasher | or maybe not |
| 00:47:07 | preglow | there's one here as well |
| 00:47:28 | preglow | old one |
| 00:48:36 | | Quit Harpy (Read error: 60 (Operation timed out)) |
| 00:48:36 | rasher | which one? |
| 00:48:43 | preglow | they just beat up a homer doll |
| 00:48:50 | Tang_ | bye all |
| 00:48:56 | preglow | Tang_: bye |
| 00:48:56 | Tang_ | i go to bed |
| 00:48:58 | Tang_ | :) |
| 00:49:10 | rasher | Ah, not the same. Thought it just might be |
| 00:49:11 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 00:49:13 | Tang_ | won't check Rbx site for a while since |
| 00:49:19 | Tang_ | i travel tomorrow |
| 00:49:24 | Tang_ | will be hard for me |
| 00:49:25 | rasher | Itchy & Scratchy 75 year jubilee |
| 00:49:25 | Tang_ | :D |
| 00:49:26 | Tang_ | ;) |
| 00:49:35 | preglow | Tang_: take it easy |
| 00:49:41 | Tang_ | :D |
| 00:49:45 | rasher | Have fun, wherever you're going |
| 00:49:51 | Tang_ | Bye all folks |
| 00:49:52 | Tang_ | :) |
| 00:49:54 | Tang_ | thnaks |
| 00:49:55 | Tang_ | :) |
| 00:50:04 | | Quit Tang_ ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]") |
| 00:50:16 | | Quit muesli- (Read error: 113 (No route to host)) |
| 00:51:02 | rasher | oh, this is the one where Bart helps some guy sue itchy & scratchy into oblivion |
| 00:54:00 | Rick | lol |
| 00:54:02 | Rick | i remember that one |
| 00:54:04 | Rick | the guy with the gold house |
| 00:54:05 | MoosCamaro | bye all |
| 00:54:07 | amiconn | http://amiconn.dyndns.org/m3.pdf Hope this is somewhat useful, it's certainly not perfect |
| 00:54:31 | | Part MoosCamaro |
| 00:55:31 | rasher | nice |
| 00:55:34 | Bagder | neat |
| 00:56:59 | Bagder | amiconn: you mind if I host your version on my site? |
| 00:57:18 | amiconn | No problem |
| 00:57:23 | preglow | ooh, ocr |
| 00:58:13 | rasher | ocr is extremely neat |
| 00:58:54 | stevenm | woohoo, clicking bug fixed |
| 00:59:09 | stevenm | back later.. now some wardriving to celebrate |
| 00:59:11 | | Quit stevenm ("Leaving") |
| 00:59:59 | rasher | Show us the code! |
| 01:00 |
| 01:00:19 | * | amiconn should finally get back to rockbox coding... |
| 01:00:24 | * | amiconn is lazy |
| 01:00:33 | | Join Bippy [0] (~5198270c@labb.contactor.se) |
| 01:01:05 | * | preglow has a fight to the death with linked lists |
| 01:01:25 | rasher | amiconn: you were the one who meant to look at the viewer, right? |
| 01:01:54 | amiconn | I'm meant to look at numerous things :-\ |
| 01:02:53 | | Quit Bippy (Client Quit) |
| 01:02:56 | rasher | Heh.. well.. if you could check out pillo's patch |
| 01:02:58 | | Join Biptoria [0] (~5198270c@labb.contactor.se) |
| 01:03:15 | rasher | it has a single bug in the new flow mode he added, but other than that, it seems quite stable |
| 01:03:50 | Biptoria | Heylo |
| 01:06:05 | Biptoria | :| |
| 01:07:31 | Rick | hi |
| 01:07:45 | Biptoria | Go rick go rick its your birthday |
| 01:07:57 | Rick | o...k... |
| 01:08:23 | Biptoria | Its not really your birthday, sorry to dissapoint you |
| 01:09:22 | preglow | but ok, seeing as everything is more fun than battling with linked lists, i'm forced to quit irc for good concentration |
| 01:09:25 | preglow | later, all |
| 01:09:35 | | Quit preglow ("floops") |
| 01:09:46 | amiconn | Bagder: In case you're interested, there are also slightly improved bitmap versions of the article (better contrast -> white background, no moire in the text boxes on page 2). http://amiconn.dyndns.org/m3-sida1.tif and http://amiconn.dyndns.org/m3-sida2.tif (attn: 3..4 MB each) |
| 01:10:30 | Biptoria | That preggers is a little work horse i tell ye |
| 01:14:24 | | Quit Sucka ("a bird in the bush is worth two in your house") |
| 01:17:05 | Biptoria | Will rockbox have that graphic equalizer thingy ? that bobs up and down |
| 01:18:39 | Bagder | if it gets one, it won't look like that ;-) |
| 01:19:30 | * | Biptoria hates rockbox |
| 01:19:33 | Biptoria | i mean |
| 01:19:39 | * | Biptoria hates iriver |
| 01:19:48 | Biptoria | Keep getting mixed up |
| 01:20:07 | Biptoria | Even there scrolling of the song title is poo compared to rockbox |
| 01:27:32 | | Join ferenczyx [0] (ferenczy@a5brn-219.dialup.vol.cz) |
| 01:31:26 | ferenczyx | hi there |
| 01:32:06 | ferenczyx | i'll repeat my questin> does anybody have the xclef mt-500 player??? ;) |
| 01:32:26 | Rick | never heard of it |
| 01:32:27 | Biptoria | Nay |
| 01:32:58 | ferenczyx | I'm going to reverse engeneering that ;) |
| 01:33:39 | Biptoria | Good Luck |
| 01:33:55 | | Join muz [0] (~54091420@labb.contactor.se) |
| 01:33:57 | ferenczyx | thanks ;) |
| 01:34:02 | ferenczyx | http://ferenczy.coex.cz/mt-500/ |
| 01:34:05 | ferenczyx | http://www.rockbox.org/twiki/bin/view/Main/XclefMT500 |
| 01:34:19 | muz | hey where can i get the convbdf tool |
| 01:34:54 | Rick | checkout rockbox-devel |
| 01:34:55 | Rick | methinks |
| 01:34:57 | Rick | or it should be in tools |
| 01:35:07 | rasher | yeah |
| 01:35:11 | muz | yeah i found the source code |
| 01:35:15 | muz | but wheres the exe |
| 01:35:20 | Rick | you need to build it |
| 01:35:34 | muz | ok i never built anythin before im scared :s |
| 01:35:44 | Rick | hm |
| 01:35:51 | Rick | maybe you can get it in one of the daily builds |
| 01:35:56 | Rick | but I don't know if it builds win32 exe's |
| 01:36:05 | *** | Saving seen data "./dancer.seen" |
| 01:36:32 | muz | how do i convert a font then? |
| 01:37:19 | Rick | no idea, i've never done so |
| 01:38:16 | muz | rasher: do you have the .fnt of snap.bdf? |
| 01:38:25 | Biptoria | You have to use 2 programs or somthing to convert a font, if i remember what rasher said |
| 01:40:30 | rasher | muz: rasher.dyndns.org/~rasher/snap.fnt |
| 01:40:47 | rasher | no.. bdf > fnt is done by convbdf |
| 01:41:30 | muz | thanks rasher |
| 01:42:50 | muz | omg i love this font |
| 01:45:43 | Biptoria | Ive never seen such emotion expressed for a font |
| 01:46:00 | muz | i wanna marry it and have its babies |
| 01:46:10 | Biptoria | :| |
| 01:46:47 | ferenczyx | lol ;) |
| 01:46:55 | Biptoria | Right im taking my iriver firmware, going to bed and listen to *mp3* somthing i cant wait to do with rockbox |
| 01:47:23 | muz | i love listening to my iriver in bed |
| 01:47:37 | Biptoria | Now that makes me sound like im having ago at rock box for not being fast |
| 01:47:56 | Biptoria | I typed more, but this IRC has a limit ? |
| 01:48:25 | Biptoria | Yes iriver in bed is a sexual experience |
| 01:48:36 | muz | it so is |
| 01:49:07 | muz | especially with otf playlists, this new sexy font, tag database and a gameboy emu |
| 01:49:08 | Biptoria | Anyhoooow time to go listen to the OC songs :D |
| 01:49:15 | muz | great choice |
| 01:49:21 | Biptoria | yup yup |
| 01:49:31 | muz | modest mouse, rooney and phantom planet are my favs |
| 01:49:35 | * | Biptoria waves to his little and large munkeys |
| 01:49:40 | Biptoria | Yep, i like all |
| 01:49:54 | Biptoria | Particularly, Alexi Murdoch - orange sky |
| 01:50:05 | Biptoria | From first series |
| 01:50:09 | muz | oh i have that but never bothered listening to it |
| 01:50:20 | muz | i will now |
| 01:50:41 | Biptoria | Make sure you have the long version, the short version is rubbish, you know its short because he |
| 01:50:50 | Biptoria | starts singin near straight away |
| 01:51:06 | muz | um ok |
| 01:51:25 | Biptoria | byeeeeeeeee |
| 01:51:27 | | Quit Biptoria ("CGI:IRC") |
| 01:53:41 | HCl | gah. |
| 01:53:46 | HCl | don't you hate it when you're like. |
| 01:53:54 | HCl | trying to sleep. and you just keep staying awake? :/ |
| 01:54:14 | muz | hey hc1 you know you build the greyscale thing ever now and then |
| 01:54:53 | muz | omg u built it today yay |
| 01:55:34 | | Nick ferenczyx is now known as _ferenczy (ferenczy@a5brn-219.dialup.vol.cz) |
| 01:55:44 | | Quit muz ("CGI:IRC") |
| 02:00 |
| 02:03:46 | ashridah | hrm. isn't snap.bdf supposed to be in the files added to the rockbox.zip ? |
| 02:08:28 | rasher | no, snap.fnt |
| 02:08:49 | | Nick tvelocity is now known as tvelocity[away] (~tony@ipa126.3.tellas.gr) |
| 02:09:30 | ashridah | ah. |
| 02:09:33 | ashridah | hm |
| 02:09:49 | ashridah | convbdf is reporting an error on that font here |
| 02:10:08 | ashridah | Error: no memory for font load Error reading font header |
| 02:11:35 | rasher | curious |
| 02:11:46 | rasher | it's totally working for me |
| 02:12:13 | rasher | oh, isn't |
| 02:12:17 | rasher | now what did I do |
| 02:12:21 | * | rasher sighs |
| 02:12:32 | ashridah | $ md5sum snap.bdf |
| 02:12:33 | ashridah | 6ae6bca607fc2889699f662fb88e99f3 snap.bdf |
| 02:12:38 | ashridah | that look okay? |
| 02:12:46 | rasher | yes |
| 02:13:05 | rasher | I guess I managed to screw the font up between fixing it and committing |
| 02:19:34 | rasher | let me see.. |
| 02:20:33 | rasher | now that is the most perplexing error message ever |
| 02:21:40 | rasher | hrm, one of the mallocs for loading the bitmaps is failing |
| 02:21:53 | rasher | I guess it's a bad font header or something |
| 02:24:33 | rasher | what the... |
| 02:26:29 | * | rasher prods convbdf |
| 02:29:54 | rasher | aha |
| 02:30:03 | rasher | pf->size: -65535 |
| 02:30:06 | rasher | can't malloc with that |
| 02:31:52 | rasher | what the.... |
| 02:32:31 | | Quit _ferenczy () |
| 02:34:42 | | Quit tvelocity[away] ("Leaving") |
| 02:35:50 | rasher | oh jesus christ |
| 02:36:01 | rasher | what the hell happened here |
| 02:37:20 | rasher | the font is indeed totally hosed |
| 02:40:45 | rasher | I'll fix and commit |
| 02:49:37 | ashridah | heh |
| 02:51:11 | | Join stevenm [0] (~steve@stevenm-router.student.umd.edu) |
| 02:59:40 | rasher | ah, almost done |
| 03:00 |
| 03:02:04 | | Quit lostlogic ("Client exiting") |
| 03:02:14 | rasher | excellent |
| 03:02:18 | rasher | it works now |
| 03:03:34 | rasher | committed |
| 03:12:15 | rasher | looks like the build system doesn't build when fonts have changed |
| 03:12:15 | | Quit thegeek (Read error: 131 (Connection reset by peer)) |
| 03:13:11 | | Join thegeek [0] (~thegeek@ti521110a080-1991.bb.online.no) |
| 03:13:24 | ashridah | nah, the only thing that processes them is the .pl file that creates the .zip |
| 03:13:42 | ashridah | and the rule for it isn't dependent on them, so make doesn't know to rebuild the zip file |
| 03:13:57 | rasher | oh well |
| 03:14:14 | ashridah | just 'make zip' should reprocess them all however |
| 03:16:19 | rasher | I think the font is good now |
| 03:16:45 | rasher | http://www.rockbox.org/viewcvs.cgi/fonts/snap.bdf.diff?r1=1.1&r2=1.2 < most boring thing in the world |
| 03:17:21 | rasher | I have absolutely no idea how they all ended up at -1 |
| 03:18:53 | | Quit DMJC ("Leaving") |
| 03:19:34 | * | ashridah resumes picking through bison docco |
| 03:25:36 | * | rasher prods stevenmn |
| 03:25:41 | rasher | stevenm |
| 03:29:32 | | Quit cYmen_ (Read error: 113 (No route to host)) |
| 03:36:06 | *** | Saving seen data "./dancer.seen" |
| 03:40:15 | | Join DMJC [0] (~James@220-245-171-89.tpgi.com.au) |
| 03:44:15 | Rick | hm |
| 03:44:21 | Rick | changed the remote lcd stuff to external power |
| 03:44:22 | Rick | didn't work |
| 03:44:23 | Rick | :/ |
| 03:46:16 | stevenm | rasher, yes ? |
| 03:46:48 | rasher | Just curious about midi :) |
| 03:47:18 | stevenm | the thing works on a simulator with writing to the sound card. I got rid of that stupid clicking too |
| 03:47:42 | stevenm | planning on going to get dinner, etc, then write xxx2wav stuff for it so it generates a real .wav file |
| 03:47:48 | stevenm | then hopefully get someone to rest it on target |
| 03:48:12 | stevenm | er test |
| 03:48:49 | * | rasher <- |
| 03:49:10 | stevenm | you feel like it ? |
| 03:49:12 | rasher | if I'm still here, at least.. I'll be happy to test |
| 03:49:26 | stevenm | do you want to test just the one that generates a raw file? |
| 03:49:50 | stevenm | then open it with goldwave or something, be like "import raw file, 48000Hz, 16 bit stereo signed" |
| 03:50:12 | rasher | sure |
| 03:50:20 | rasher | raw pcm? |
| 03:50:56 | stevenm | yea |
| 03:51:04 | stevenm | and it needs a 27 meg patchset |
| 03:51:09 | stevenm | you on broadband ? |
| 03:51:22 | rasher | yeah.. not that broad though :) |
| 03:51:32 | stevenm | hmmm... |
| 03:51:36 | stevenm | well here lemme put some things up |
| 03:53:29 | stevenm | rasher, http://wam.umd.edu/~stevenm/patchset.tbz2 |
| 03:53:47 | stevenm | that has to be decompressed into / |
| 03:53:51 | stevenm | it's only one dir |
| 03:54:31 | rasher | excellent |
| 03:54:31 | rasher | only 4mb compressed |
| 03:54:36 | stevenm | wow ! |
| 03:54:38 | stevenm | no way |
| 03:54:42 | stevenm | I must have run out of space.. |
| 03:55:10 | rasher | oh |
| 03:55:18 | stevenm | yea, hold on, lemme make space |
| 03:56:26 | stevenm | ok it's going up |
| 03:57:04 | stevenm | rasher, try that again |
| 03:57:13 | rasher | .tbz2 ? |
| 03:57:58 | rasher | ah, 23mb |
| 03:58:46 | stevenm | yes |
| 03:58:50 | stevenm | tar bz2 |
| 04:00 |
| 04:00:16 | rasher | never seen that before |
| 04:01:02 | stevenm | its a linux thing |
| 04:01:59 | rasher | I mean, I've never seen anyone use tbz2.. always tar.bz2 |
| 04:02:05 | stevenm | ah |
| 04:02:11 | stevenm | gentoo always has its packages as taht |
| 04:02:27 | stevenm | http://wam.umd.edu/~stevenm/midi2wav.tbz2 |
| 04:02:34 | stevenm | untar that into / also |
| 04:02:35 | rasher | they would |
| 04:02:47 | stevenm | it creates 2 .cfg files, the .rock file and test.mid |
| 04:02:58 | stevenm | then fire up the plugin |
| 04:03:15 | rasher | is this .rock build for iriver? |
| 04:03:21 | rasher | or sim? |
| 04:03:24 | stevenm | it will say MIDI... then when it hits the end of the file, it will be FINSIHED PLAYING |
| 04:03:30 | stevenm | no I rebuilt it for iriver |
| 04:03:47 | stevenm | then /dsp.raw is the output file |
| 04:03:51 | rasher | still waiting for the patchset :) |
| 04:03:56 | stevenm | oh |
| 04:04:19 | stevenm | it is quite a large patch set |
| 04:04:44 | rasher | 8 minutes left |
| 04:04:53 | stevenm | wow |
| 04:05:19 | rasher | I'm on 256/256 |
| 04:05:46 | stevenm | ah |
| 04:06:04 | | Join QT_ [0] (as@area51.users.madwifi) |
| 04:06:26 | stevenm | madwifi ? |
| 04:08:31 | rasher | Must've been snuck in through the backdoor when they approved .jobs |
| 04:08:47 | stevenm | wow |
| 04:08:55 | stevenm | madwifi is a linux driver for Atheros cards |
| 04:13:40 | rasher | hrm, where are iriver2.cfg expected to be? |
| 04:14:32 | Rick | agh |
| 04:14:37 | Rick | I think I figured out wtf I was doing wrong |
| 04:14:52 | stevenm | rasher, progress ? |
| 04:14:53 | rasher | \o/ |
| 04:14:54 | Rick | if this fixes it i'll fall over |
| 04:15:15 | rasher | yeah, it's downloaded.. but midi2wav just unzipped into the root |
| 04:15:46 | rasher | as in, all the files are now in the root |
| 04:15:55 | Rick | I hope this fixes it at least |
| 04:16:30 | stevenm | rasher, cool.. fire it up :-D |
| 04:16:43 | Rick | nope |
| 04:16:44 | Rick | :/ |
| 04:16:54 | rasher | well, where should I put the files? (.cfg especially) |
| 04:17:00 | rasher | also, is the .rock a viewer plugin? |
| 04:17:05 | Rick | although that's part of the problem |
| 04:17:22 | stevenm | rasher, all goes in / |
| 04:17:31 | | Quit QT (No route to host) |
| 04:17:57 | rasher | how about the .rock? viewer or regular plugin? |
| 04:18:14 | stevenm | just / |
| 04:18:19 | rasher | o.O |
| 04:18:26 | rasher | ah.. |
| 04:18:29 | stevenm | rasher, I dont think the rock will care... but I had it in / |
| 04:18:41 | rasher | yeah |
| 04:18:46 | stevenm | so / should coutain: patchset, test.mid, iriver2.cfg, drums.cfg, and the rock |
| 04:18:48 | rasher | regular plugin then |
| 04:18:57 | stevenm | yes |
| 04:19:05 | rasher | [MIDI] |
| 04:19:08 | rasher | IllInstr |
| 04:19:13 | rasher | >< |
| 04:19:24 | stevenm | IllInstr ? |
| 04:19:30 | stevenm | That's not good...... .. what's that mean ? |
| 04:19:32 | rasher | yup, error messgae |
| 04:19:38 | Rick | bad error messae |
| 04:19:40 | Rick | *message |
| 04:19:41 | Rick | hehe |
| 04:19:44 | rasher | I think it's because of differing versions |
| 04:19:44 | stevenm | oh rats |
| 04:19:50 | stevenm | probably |
| 04:19:56 | rasher | as in, your .rock doesn't fit my rockbox |
| 04:20:00 | stevenm | right |
| 04:20:08 | stevenm | mine is quite a bit old |
| 04:20:11 | rasher | do you have an entirely synced tree? |
| 04:20:13 | rasher | ah |
| 04:20:15 | stevenm | lemme get latest CVS adn rebuild |
| 04:20:17 | rasher | well there we go then |
| 04:20:23 | stevenm | yea didnt think of that |
| 04:20:28 | stevenm | hang on, lemme re-grab it |
| 04:20:34 | rasher | sure |
| 04:21:07 | | Quit DMJC ("Leaving") |
| 04:21:26 | Rick | I curse you, remote lCD! |
| 04:23:28 | stevenm | rasher, building.. |
| 04:24:27 | rasher | Excellent |
| 04:24:34 | stevenm | http://wam.umd.edu/~stevenm/midi2wav.rock |
| 04:26:23 | rasher | still :( |
| 04:26:37 | rasher | how annoying |
| 04:27:15 | stevenm | rasher, how is that possible? |
| 04:27:28 | stevenm | rasher, do you have Normal or Debug ? |
| 04:28:14 | stevenm | rasher, do you wanna try building it yourself? |
| 04:28:14 | rasher | Normail iirc |
| 04:28:42 | rasher | sure |
| 04:28:44 | rasher | send me a atch |
| 04:28:48 | rasher | patch |
| 04:29:41 | stevenm | http://wam.umd.edu/~stevenm/midi.tbz2 |
| 04:29:49 | stevenm | don't really know how to make patches .. .. |
| 04:30:13 | rasher | is this the entire tree ? |
| 04:30:16 | stevenm | you just untar that into apps/plugins and then add midi2wav.c to the SOURCES in apps/plugins in the software codec section |
| 04:30:28 | stevenm | no, just the midi.. a dir called midi and midi2wav.c |
| 04:30:43 | rasher | excellent |
| 04:32:14 | * | rasher builds |
| 04:33:16 | stevenm | does rasher see a [MIDI] on the screen ? |
| 04:33:59 | rasher | still the same :-| |
| 04:34:06 | rasher | now I'm confused |
| 04:34:22 | rasher | the [MIDI] appears for a second or so |
| 04:34:34 | rasher | did you change the plugin api? |
| 04:34:41 | stevenm | no.. |
| 04:34:47 | stevenm | [midi] does appear ? |
| 04:34:53 | rasher | yes |
| 04:34:56 | stevenm | lemme make that a little more informative |
| 04:35:04 | stevenm | i wonder how far it gets... |
| 04:35:09 | rasher | heh |
| 04:35:16 | stevenm | do you have patches in /patchset ? |
| 04:35:21 | stevenm | like, /patchset/*.pat |
| 04:35:25 | rasher | put a sleep after each message |
| 04:35:27 | rasher | yes |
| 04:35:59 | rasher | hm.. /PATCHSET/*.PAT, but that shouldn't matter |
| 04:37:05 | stevenm | is it case sensitive ? |
| 04:37:15 | rasher | I doubt it |
| 04:37:19 | rasher | it's fat afterall |
| 04:38:19 | stevenm | I have had problems with that on linux.. |
| 04:38:44 | stevenm | like, "patchset" != "PATCHSET" |
| 04:38:48 | stevenm | but we'll see what happens |
| 04:38:55 | thegeek | most linux fs's are case sensitive stevenm |
| 04:38:59 | stevenm | do you have a /test.mid ? |
| 04:39:02 | rasher | yeah well on most filesystems that's true |
| 04:39:18 | rasher | yes |
| 04:39:22 | rasher | (TEST.MID) |
| 04:40:35 | stevenm | rasher, may wanna rename that to test.mid ? |
| 04:40:42 | stevenm | well we'll see, I'm adding sleeps and some debugs |
| 04:41:32 | rasher | I could try... I'm not even sure I can |
| 04:42:23 | stevenm | rasher, here is new file |
| 04:43:10 | stevenm | http://wam.umd.edu/~stevenm/midi2wav.c |
| 04:44:12 | rasher | building |
| 04:44:24 | stevenm | rasher, there are debugs like every 3 sec |
| 04:45:03 | rasher | hrm, why oh why did I make clean |
| 04:45:06 | stevenm | it goes, MIDI, then Loading Midi, then Loaded Midi, then Loading Patches, then Start Playing |
| 04:45:11 | stevenm | eep |
| 04:46:37 | rasher | MIDI, OPENED DSP, LOADING MIDI > IllInstr |
| 04:47:27 | stevenm | rasher, try renaming it to TEST.MID |
| 04:47:33 | stevenm | or better yet change it in midi2wav.c |
| 04:47:38 | stevenm | er test.mid |
| 04:47:49 | stevenm | see if it cant see the file, or is it crashing on memory allocation |
| 04:48:02 | stevenm | if anything, it would probably be one of those |
| 04:48:07 | rasher | printf("\nHello.\n"); wah? |
| 04:48:14 | stevenm | yea printf is stubbed |
| 04:48:16 | stevenm | don't worry |
| 04:48:31 | rasher | heh |
| 04:49:04 | stevenm | you guys told me how to stub it.. funny enough, it's stubbed but it STILL prints to console in sim mode |
| 04:49:11 | stevenm | yet at the same time, it compiles for rockbox |
| 04:49:19 | stevenm | that shouldn't really matter, if it gets THAT far |
| 04:49:29 | stevenm | either it cant find the file or it can't load it |
| 04:49:31 | Rick | that's because printf gets defined in sim |
| 04:49:31 | rasher | nono, just wondering |
| 04:49:52 | rasher | well.. changing to TEST.MID didn't help |
| 04:50:11 | stevenm | rasher, then it is probably an issue with memory allocation |
| 04:50:24 | stevenm | I took malloc straight from rockboy.. probably incorrectly |
| 04:50:32 | rasher | fun fun fun |
| 04:50:46 | stevenm | if you wanna look at it, the malloc implementation is in midi/midiutil.c |
| 04:50:48 | rasher | well I'll be happy to test further |
| 04:51:04 | rasher | I doubt I could be of any help there :) |
| 04:52:22 | stevenm | I am sorry |
| 04:52:34 | stevenm | I do not own a device.. I don't really know how to make it work on there |
| 04:52:52 | rasher | no worries |
| 04:53:31 | rasher | might as well turn it into a viewer plugin |
| 04:53:44 | stevenm | i'd ask preglow or someone like that.. he'd probably know |
| 04:53:53 | stevenm | or maybe I gotta look at the malloc code some more |
| 04:54:44 | * | rasher tries turning it into a viewer plugin |
| 04:54:47 | rasher | for fun & profit |
| 04:55:31 | stevenm | heh |
| 04:57:00 | stevenm | rasher, I may not have set the malloc pointer right.. but I really don't really knoiw |
| 04:57:07 | stevenm | I have to go now, but we can try tomorrow |
| 04:57:25 | stevenm | byebye |
| 04:57:38 | | Quit stevenm ("Leaving") |
| 04:59:40 | | Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC for those that like to be different") |
| 05:00 |
| 05:12:42 | | Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) |
| 05:22:07 | | Join webguest05 [0] (~d441fc03@labb.contactor.se) |
| 05:27:17 | | Part webguest05 |
| 05:36:08 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:01:59 | | Join stevenm [0] (~steve@stevenm-router.student.umd.edu) |
| 06:05:53 | stevenm | rasher, do you want to try messing with midi2wav some more? I put in more debug calls |
| 06:10:54 | rasher | sure |
| 06:11:22 | stevenm | all right, I put in some more debug calls: |
| 06:11:29 | stevenm | http://wam.umd.edu/~stevenm/midi.tbz2 |
| 06:11:38 | stevenm | untar into apps/plugins/ and build |
| 06:11:43 | stevenm | and let's see how far it gets |
| 06:13:10 | | Join bobdbob [0] (~bobdbob@ics151-142.icsincorporated.com) |
| 06:13:35 | stevenm | and if it still dies, I have yet another thing to try |
| 06:13:48 | stevenm | (well it will die, but if it dies on the malloc, I may have a solution) |
| 06:13:53 | | Quit ashridah ("Leaving") |
| 06:14:56 | stevenm | rats.. I have to run to the food shop before it closes and buy dinner |
| 06:15:04 | stevenm | rasher, I will be back in 10 min or so hopefully |
| 06:15:49 | rasher | I'll have it tested the |
| 06:15:49 | rasher | n |
| 06:15:56 | stevenm | cool |
| 06:16:30 | rasher | dies after "memsetting".. now hurry up |
| 06:16:41 | stevenm | after MEMSETTING ? |
| 06:16:45 | stevenm | Interesting |
| 06:17:07 | stevenm | try changing the allocate() function in midiutil.c to: return codec_malloc(size); |
| 06:17:16 | stevenm | instead of my_malloc or whatever it is |
| 06:17:19 | stevenm | be back soon |
| 06:26:57 | stevenm | rasher, I am back |
| 06:27:33 | stevenm | rasher, any luck ? |
| 06:30:18 | rasher | hrm.. it hung earlier |
| 06:30:22 | rasher | think I'll try again |
| 06:30:37 | stevenm | rasher, also, in midifile.c on lines 31 and 179, memset needs to be rb->memset instead |
| 06:31:07 | rasher | calling alloc 1 |
| 06:31:23 | stevenm | then crashes ? |
| 06:31:30 | rasher | no |
| 06:31:33 | rasher | it hangs |
| 06:31:39 | rasher | apparenlty |
| 06:32:01 | | Quit rasher ("CGI:IRC (EOF)") |
| 06:32:28 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 06:33:51 | Rick | Greetings LinusN |
| 06:35:34 | stevenm | Hey guys.. Does anyone know how to allocate memory from the iriver's huge memory buffer / |
| 06:35:35 | stevenm | ? |
| 06:35:57 | Rick | stevenm: you'll have to do it manually, if you mean like malloc() |
| 06:36:13 | stevenm | Rick, yes, I need a malloc() exactly |
| 06:36:32 | Rick | one second |
| 06:36:41 | stevenm | I copied the code (or what I THOUGHT) was right from rockboy.. it works on Sim but I think it crashes on rasher's iriver |
| 06:36:52 | stevenm | or it could be my memset typo too. I don;t know |
| 06:37:05 | | Join rasher [0] (~3e4f4094@labb.contactor.se) |
| 06:37:46 | Rick | http://rick.gibbed.us/allocstuff.c |
| 06:37:47 | stevenm | hello rasher |
| 06:37:48 | Rick | there's mine |
| 06:37:50 | Rick | it's based on rockboy's |
| 06:37:59 | rasher | it hangs at "memsetting" now |
| 06:38:11 | rasher | also, I get "alloc 1 null" at one point |
| 06:38:20 | stevenm | rasher, I see... |
| 06:38:33 | stevenm | I am about to try Rick's code, see what happens. I put up a new file then |
| 06:38:38 | stevenm | Rick, what is ralloc ? |
| 06:38:44 | Rick | basically 'realloc' |
| 06:39:07 | Rick | if you need to resize a buffer |
| 06:39:28 | stevenm | Rick, ah I see. thanks |
| 06:39:41 | rasher | morning linus |
| 06:40:10 | Rick | stevenm: they *should* work fine |
| 06:40:13 | stevenm | rasher, try http://wam.umd.edu/~stevenm/midi.tbz2 |
| 06:40:26 | Rick | stevenm: they are used in my port of pinfocom |
| 06:40:32 | Rick | which I broke (unrelated to alloc) |
| 06:40:32 | Rick | hehe |
| 06:40:39 | stevenm | Rick, I see.. I think there may be something funky with my memsets.. I just go rb->memset |
| 06:40:51 | LinusN | morning all |
| 06:40:55 | Rick | heya LinusN |
| 06:40:56 | stevenm | Hello Linus |
| 06:41:00 | * | rasher builds |
| 06:41:14 | Rick | LinusN: you can ignore the memos I sent you ;P |
| 06:41:26 | LinusN | i never get any |
| 06:41:39 | rasher | woo |
| 06:41:41 | Rick | odd |
| 06:41:52 | rasher | I think it's working now |
| 06:42:00 | Rick | LinusN: been trying for hours to get the lcd initialized... no success :/ |
| 06:42:02 | rasher | yes |
| 06:42:29 | rasher | it totally is |
| 06:42:34 | Rick | rasher: what is? |
| 06:42:35 | LinusN | Rick: how does your current code look like? |
| 06:42:40 | Rick | http://rick.gibbed.us/lcd-h100-remote.c |
| 06:42:45 | stevenm | rasher, what is it saying > |
| 06:42:49 | rasher | oh dear |
| 06:42:51 | Rick | was trying various things |
| 06:42:57 | rasher | I look away, and BANG, IllInstr |
| 06:42:57 | Rick | so there is lots of weird code in there |
| 06:43:06 | Rick | Hehe |
| 06:43:10 | LinusN | Rick: the init is wrong |
| 06:43:17 | * | Rick nods |
| 06:43:19 | rasher | stevenm: it got way farther.. reading tracks and so on |
| 06:43:22 | Rick | I was trying all kinds of things |
| 06:43:29 | Rick | that is just how it was on what I tried the last time |
| 06:43:33 | stevenm | rasher, it may go thru a few readID / MTrks... hopefully after that it say LOADED FILE |
| 06:43:46 | stevenm | rasher, there aren't many tracks in there.. maybe 10 or so |
| 06:43:52 | rasher | let me pay more attention this time |
| 06:44:15 | Rick | LinusN: it's also noted that the write_command_ex is pretty useless for thislcd |
| 06:44:17 | Rick | *this lcd |
| 06:44:25 | Rick | the only thing data is used for is writing to the screen |
| 06:44:30 | Rick | everything else is command |
| 06:44:33 | LinusN | noticed that |
| 06:44:34 | Rick | at least from what i've seen |
| 06:45:15 | Rick | I was trying to go by what was said on 40 and 41 |
| 06:45:20 | Rick | I tried many combinations of things with no luck |
| 06:45:20 | rasher | stevenm: after load patches |
| 06:45:20 | LinusN | ok, first think to check is of course if our spi code works |
| 06:45:32 | stevenm | rasher, ah, I know what it is. I left an old-style memset in there |
| 06:45:32 | Rick | well, how can we check that? |
| 06:45:41 | LinusN | multimeter or oscilloscope |
| 06:45:53 | stevenm | rasher, lemme fix that.. and get rid of the splash in readtrack so it goes faster |
| 06:46:04 | Rick | LinusN: all I can say is 'what are those?' |
| 06:46:14 | rasher | stevenm: fine.. I'll go have a shower |
| 06:46:19 | LinusN | Rick: :-) |
| 06:46:43 | Rick | Hope it's not a dumb question ;P |
| 06:47:14 | LinusN | Rick: is the lcd *totally* dead? |
| 06:47:20 | Rick | I *think* so |
| 06:47:23 | Rick | It's hard to tell |
| 06:47:33 | Rick | which is why I did the backlight stuff |
| 06:47:35 | Rick | it makes it easier to tell |
| 06:47:39 | stevenm | rasher, here: http://wam.umd.edu/~stevenm/midi.tbz2 |
| 06:48:01 | Rick | LinusN: I also tried initializing it with a dark contrast |
| 06:48:01 | Rick | etc |
| 06:48:39 | LinusN | where did you put the lcd_remote_init() call? |
| 06:48:55 | Rick | after lcd_init(); in main.c |
| 06:49:01 | LinusN | ok |
| 06:49:14 | Rick | I figured that would be an appropriate spot to put it |
| 06:49:48 | Rick | hrm |
| 06:49:51 | Rick | could that be it? |
| 06:50:00 | * | Rick just noticed serial_setup() in an ifndef |
| 06:50:22 | LinusN | that's a completely different thing |
| 06:50:35 | Rick | okay |
| 06:51:35 | Rick | backlight works fine, just havn't managed to get the lcd to do anything. |
| 06:54:21 | rasher | stevenm: trying... |
| 06:54:30 | stevenm | rasher, sweet, thank you |
| 06:55:11 | rasher | start playing! |
| 06:55:24 | stevenm | rasher, woah, holy crap ! |
| 06:55:29 | rasher | :) |
| 06:55:34 | stevenm | awesome ! |
| 06:55:39 | Rick | what's going on? |
| 06:55:41 | rasher | I'll go get dressed while it finishes.. |
| 06:55:48 | | Join ashridah [0] (ashridah@220-253-120-244.VIC.netspace.net.au) |
| 06:55:55 | stevenm | rasher, I am not even sure how long it is going to take..... |
| 06:56:04 | stevenm | it will say FINISHED PLAYING then exit |
| 06:56:18 | stevenm | Rick, we think the MIDI codec is running on target |
| 06:56:25 | Rick | ah |
| 06:56:47 | stevenm | Rick, well.. it is running... hopefully it won't crash or anything, but produce an output file |
| 06:57:17 | LinusN | Rick: your power setting is wrong |
| 06:57:25 | Rick | LinusN: I tried various stuff |
| 06:57:34 | Rick | the default (mentioned in the spec) |
| 06:57:36 | Rick | and some others |
| 06:57:40 | LinusN | i see that you turn on each voltage like the data sheet says |
| 06:57:54 | rasher | stevenm: I should have set the cpu to 120mhz... |
| 06:58:00 | LinusN | but you must keep the voltages on |
| 06:58:10 | rasher | oops... |
| 06:58:13 | rasher | what happened now |
| 06:58:15 | rasher | may be battery |
| 06:58:20 | stevenm | rasher, what happen ? |
| 06:58:20 | Rick | oh? |
| 06:58:31 | Rick | I think I understand what you mean |
| 06:58:41 | LinusN | the first CNTL_POWER_CONTROL turns on the converter |
| 06:58:41 | rasher | stevenm: it turned off |
| 06:58:45 | stevenm | rasher, did it die or something? there should be a file, /dsp.raw .. |
| 06:58:53 | stevenm | rasher, turned off ?? |
| 06:58:55 | rasher | there is |
| 06:59:04 | rasher | stevenm: I think I ran out of battery :) |
| 06:59:15 | Rick | LinusN: basically you're saying I need to include the previous mask in with the next? |
| 06:59:16 | LinusN | then you turn the converter off in the next command, since you only set the regulator bit |
| 06:59:20 | Rick | ah |
| 06:59:40 | * | rasher tries again with cpu at 120mhz |
| 06:59:51 | Rick | so I need 0x4, 0x6, then 0x7 |
| 06:59:56 | LinusN | yes |
| 07:00 |
| 07:00:40 | Rick | Guess I misinterpreted how that command works |
| 07:00:40 | Rick | hehe |
| 07:00:50 | LinusN | then i'm not sure how to set the resistor value |
| 07:01:06 | LinusN | i.e which value to choose |
| 07:01:44 | Rick | well |
| 07:01:50 | Rick | the spec for the remote says 3V |
| 07:01:57 | Rick | so would it be proper to set to 3volts? |
| 07:02:09 | LinusN | guess so |
| 07:02:11 | stevenm | rasher, ah I see. whoops.. |
| 07:02:24 | Rick | which is how I have it now |
| 07:02:47 | stevenm | rasher, are they rechargible or do you have to replace them or what ? |
| 07:02:52 | LinusN | can you test right now? |
| 07:02:57 | Rick | yep |
| 07:03:03 | Rick | lemme find the usb cord |
| 07:03:19 | rasher | stevenm: charging.. and testing |
| 07:03:27 | stevenm | rasher, ah, cool |
| 07:03:50 | stevenm | from even a little bit you should have a dsp.raw.. unless rockbox doesn't save it on exit, or soemthing. |
| 07:04:06 | stevenm | if that file is there, it is 48Khz, Stereo, 16bit signed |
| 07:05:07 | rasher | it was |
| 07:05:18 | rasher | dammit, hurry up :) |
| 07:06:37 | rasher | the hdd led flashes, so it looks like things are happening correctly :) |
| 07:07:06 | Rick | LinusN: doesn't look like it's working. |
| 07:07:22 | stevenm | rasher, sweet.... I really do hope that file is coherent |
| 07:07:23 | LinusN | hehe |
| 07:08:09 | stevenm | rasher, also, the thing isn't optimized for Coldfire or anything... the assembly gurus here can probably optimize the synth part.. right now I just want it to run right |
| 07:08:49 | Rick | LinusN: i'll try turning the voltage to default |
| 07:08:59 | LinusN | do so |
| 07:09:07 | rasher | stevenm: sure, that's about what I expected |
| 07:09:13 | LinusN | how does the code look now? |
| 07:09:15 | rasher | I'll have to leave now |
| 07:09:23 | rasher | to catch my train |
| 07:09:43 | stevenm | rasher, ah, all right |
| 07:09:48 | stevenm | rasher, well thank you for all your testing |
| 07:09:59 | rasher | will test the file when I get there |
| 07:10:02 | rasher | (uni) |
| 07:10:05 | | Quit rasher ("bye") |
| 07:10:19 | Rick | IT works! |
| 07:10:23 | * | LinusN forgot his remote at home |
| 07:10:25 | Rick | *It |
| 07:10:26 | stevenm | Rick, woah, cool ! |
| 07:10:33 | Rick | screen turned black |
| 07:10:37 | LinusN | Rick: wow |
| 07:10:41 | Rick | (because of the reverse, no doubt) |
| 07:10:46 | LinusN | turn off reverse then |
| 07:10:50 | Rick | yes |
| 07:10:52 | * | Rick tries |
| 07:10:57 | * | LinusN does a little dance |
| 07:11:35 | Rick | (I also seem to have broken the "rockbox.iriver has changed. reboot?" thing when you disconnect usb cable) |
| 07:11:39 | stevenm | Woah, today is a good day for rockbox |
| 07:11:41 | stevenm | Hey LinusN, is there a way for me to get CVS space to put my codec there or something ? |
| 07:11:57 | LinusN | Rick: the detection is not 100% |
| 07:11:58 | Rick | haha |
| 07:11:59 | Rick | now it worked |
| 07:12:02 | * | Rick grins |
| 07:12:18 | Rick | yep |
| 07:12:22 | Rick | I can see the lcd coming on |
| 07:12:37 | Rick | :)! |
| 07:12:44 | LinusN | Rick: could you clean it up and put it up on your web? |
| 07:12:48 | Rick | sure. |
| 07:13:35 | Rick | Oh, what should I call the "reference voltage select" command? |
| 07:13:36 | Rick | for a define |
| 07:13:54 | Rick | LCD_REMOTE_CNTL_SELECT_VOLTAGE ? |
| 07:14:02 | Rick | or voltage_select ? |
| 07:15:04 | Rick | and i'm not sure what to call the bias stuff either |
| 07:15:53 | LinusN | the names don't matter that much |
| 07:16:00 | Rick | okay ;P |
| 07:16:08 | Rick | just trying to be tidy, hehe |
| 07:16:16 | Rick | I also just realized something |
| 07:16:22 | LinusN | just make sure it is easy to follow the data sheet |
| 07:16:27 | Rick | yeah |
| 07:16:34 | Rick | oh, nevermind |
| 07:16:40 | Rick | (about the realizing thing) |
| 07:16:44 | LinusN | :-) |
| 07:17:33 | Rick | okay |
| 07:17:36 | Rick | lcd inits without the reset |
| 07:17:40 | Rick | so it probably ignored that |
| 07:20:51 | Rick | okay |
| 07:20:58 | Rick | testing, if it works i'll update |
| 07:21:46 | Rick | works |
| 07:21:47 | Rick | updating |
| 07:22:03 | LinusN | great |
| 07:22:15 | Rick | http://rick.gibbed.us/lcd-h100-remote.c |
| 07:22:32 | LinusN | thx |
| 07:22:48 | LinusN | next is to implement lcd_remote_set_contrast() |
| 07:22:55 | LinusN | easy as pie |
| 07:22:55 | Rick | that shouldn't be too hard |
| 07:22:58 | Rick | yeah |
| 07:23:04 | Rick | it should just be the select voltage, I think |
| 07:23:43 | Rick | should I do it now? |
| 07:23:46 | LinusN | sure |
| 07:24:40 | Rick | done |
| 07:25:16 | * | Rick opens up lcd.h to see what stuff the normal lcd has defined |
| 07:26:30 | Rick | ah |
| 07:27:14 | Rick | lcd_remote_set_invert_display - done |
| 07:27:55 | Rick | nothing else quick & easy |
| 07:28:10 | Rick | I think |
| 07:29:26 | * | Rick tries writing to the display |
| 07:30:17 | Rick | hehe, nothing showed up |
| 07:31:01 | LinusN | i'd like to commit the working code |
| 07:31:06 | Rick | oh, sure |
| 07:31:31 | Rick | updated |
| 07:31:32 | * | Rick grins |
| 07:33:37 | amiconn | I don't know how severe such a spec violation is, but I just read the h1xx remote lcd needs a power-on sequence similar to the archos lcd (3 voltages in sequence). What I did for the player lcd was to change that into just the last step (switch all 3 voltages on at once). This is working. Linus? |
| 07:34:00 | LinusN | it just might work |
| 07:34:04 | Rick | well |
| 07:34:12 | Rick | Following the spec seems safer |
| 07:34:15 | * | Rick grins |
| 07:34:18 | Rick | I can try it for you if you want |
| 07:34:20 | LinusN | my feeling as well |
| 07:35:41 | Rick | it works |
| 07:35:46 | Rick | but I still think it's better to follow spec |
| 07:36:03 | Rick | oh, set_contrast works |
| 07:36:10 | Rick | I just tested it to make sure |
| 07:36:12 | *** | Saving seen data "./dancer.seen" |
| 07:36:46 | amiconn | There's probably another spec violation in the archos lcd driver, but I can't test. If the solomon specs are really the correct ones (is this confirmed meanwhile), we're driving too fast! |
| 07:37:09 | Rick | Is it possible to damage the remote by doing that? |
| 07:37:42 | LinusN | amiconn: it is confirmed to be an SSD1815 |
| 07:38:07 | LinusN | http://www.rockbox.org/twiki/pub/Main/DataSheets/g112064-30-3.pdf |
| 07:38:13 | Rick | oh |
| 07:38:17 | amiconn | The SSD1815 specs say max. clock 1 MHz, we're probably ~10% above that (if I counted the cycles correctly and didn't overlook a wait state) |
| 07:38:19 | Rick | I guess this means the port pin page can be updated |
| 07:38:22 | Rick | to (C) the remote stuff |
| 07:38:33 | LinusN | Rick: yup |
| 07:38:52 | amiconn | The SSD1800/1801 specs say 300 kHz, and we're probably above that as well |
| 07:38:58 | Rick | hrm |
| 07:38:58 | Rick | odd |
| 07:39:17 | Rick | my contrast is stuck on 61... |
| 07:39:18 | Rick | I think |
| 07:41:05 | Rick | hm |
| 07:41:05 | Rick | weird |
| 07:41:24 | Rick | fixed now |
| 07:41:27 | * | Rick wonders why it stuck that way |
| 07:41:38 | Rick | LinusN: so what's next? |
| 07:41:52 | Rick | i'm guessing we wait for that guy who had written high level stuff? |
| 07:42:26 | LinusN | sure, let's hope he did something useful |
| 07:42:34 | LinusN | let's commit what we have |
| 07:42:47 | Rick | okay |
| 07:43:37 | amiconn | LinusN: Is the newplayer lcd also confirmed to be a Solomon device? If at all, I'd rather guess it's an SSD1800 rather than SSD1801 (2 lines instead of 3 lines, otherwise identical) |
| 07:44:03 | dwihno | \o/ hej \o/ |
| 07:44:04 | LinusN | amiconn: no, we don't know fir sure which one it is |
| 07:44:04 | amiconn | Also, is there any info about the oldplayer lcd type? |
| 07:44:35 | Rick | portpin page updated |
| 07:44:37 | LinusN | i thought 1800 is old and 1801 is new...? |
| 07:46:00 | LinusN | not sure, that was a long time ago |
| 07:46:15 | LinusN | the character maps are the key, i think |
| 07:46:44 | amiconn | No, the oldplayer lcd has a different command set |
| 07:47:30 | amiconn | ...which is not verifiable since we don't have the specs. We know that the commands we know about are working, but we don't know whether there are more |
| 07:48:10 | Rick | how are they different? |
| 07:48:21 | amiconn | Maybe there is a cursor command as well (the new lcd has that). If yes, we could use the hardware cursor instead of flashing 'by hand' |
| 07:48:40 | amiconn | Rick: Completely different command values for the same action |
| 07:48:45 | Rick | well |
| 07:48:55 | Rick | but do they align the same way? |
| 07:49:05 | LinusN | Rick: they are character based |
| 07:49:12 | Rick | I mean the commands |
| 07:49:15 | Rick | not the characters |
| 07:49:33 | Rick | say A is 1, B is 3, on the other A is 2, B is 4 that would be aligned. |
| 07:50:08 | LinusN | we have a translation table for that |
| 07:50:38 | LinusN | sorry, i misunderstood |
| 07:50:50 | * | Rick nods |
| 07:50:53 | Rick | I'm referring to the commands |
| 07:50:56 | LinusN | yes |
| 07:51:07 | Rick | I'm just saying, if they align closely you might be able to guess where the other commands are |
| 07:51:30 | amiconn | They are ordered differently |
| 07:51:53 | Rick | :/ |
| 07:53:08 | Rick | is there a list of commands somewhere for both that I can take a look at? |
| 07:55:09 | amiconn | No, there isn't. We have what we believe is the correct spec for the newplayer lcd. At least the commands match Solomon SSD1800/1801. You can find that in the wiki |
| 07:55:32 | amiconn | However, we don't have the specs for the oldplayer lcd |
| 07:55:38 | Rick | well |
| 07:55:45 | Rick | I mean the known commands for oldplayer and a spec for the newplayer |
| 07:56:22 | amiconn | We know about a number of the commands, but since we don't know their names, the driver simply uses the hex values for most of them |
| 07:56:36 | Rick | ah |
| 07:57:06 | Rick | are the 'arguments' similar or the same? |
| 07:58:01 | | Join webguest65 [0] (~c31ce021@labb.contactor.se) |
| 07:59:43 | amiconn | Even the init sequence is different. See lcd-player.c, lines 493..630 |
| 08:00 |
| 08:00:27 | * | Rick looks |
| 08:02:11 | amiconn | LinusN: Slight correction - the Solomon specs allow switching on the voltages at once. Still, the archos firmware does it one-by-one |
| 08:02:40 | LinusN | amiconn: ok |
| 08:03:40 | | Join tvelocity [0] (~tony@ipa126.3.tellas.gr) |
| 08:04:02 | amiconn | This means one of 2 things. (1) It is a solomon controller, and the archos firmware is over-cautious here (2) It's not a solomon controller, and the sequence is necessary |
| 08:05:21 | amiconn | I wanted to check whether I find something on my player, but as already reported I didn't manage to unscrew the display/ button unit. Probably superglued :( |
| 08:05:56 | Rick | LinusN: What is 'static indicator'? |
| 08:06:01 | LinusN | ? |
| 08:06:12 | Rick | (if you know...) |
| 08:06:49 | Rick | I guess i'll just try it and see what it does |
| 08:07:23 | LinusN | where do you see it? |
| 08:07:39 | Rick | in the spec |
| 08:07:47 | Rick | page 37 |
| 08:07:48 | Rick | bottom |
| 08:07:51 | Rick | and the next page |
| 08:08:00 | Rick | it talks about blinking |
| 08:08:51 | Rick | doesn't do anything obvious, I think |
| 08:09:31 | LinusN | looks like a cursor to me |
| 08:09:47 | Rick | ah |
| 08:10:08 | Rick | well, I don't see anything |
| 08:10:09 | * | Rick hmms |
| 08:10:20 | LinusN | nah |
| 08:10:23 | LinusN | can't be |
| 08:10:37 | Rick | I send 0xAD and 1 (1 second blinks) |
| 08:10:57 | Rick | trying always on now |
| 08:11:39 | Rick | nothing |
| 08:11:39 | Rick | hmm |
| 08:11:58 | Rick | oh |
| 08:12:06 | Rick | it has something to do with power saving |
| 08:12:07 | Rick | too |
| 08:13:55 | LinusN | funny, they don't seem to mention anywhere wft static indicator really is :-) |
| 08:14:13 | Rick | earlier in the spec it says 4 flashing modes |
| 08:14:15 | * | Rick shrugs |
| 08:14:20 | LinusN | like it's common knowledge... |
| 08:14:36 | Rick | hehe |
| 08:14:43 | Rick | oh well |
| 08:15:30 | HCl | mrf |
| 08:15:32 | HCl | morning |
| 08:15:38 | Rick | googling 'lcd static indicator' gets a bunch of results |
| 08:15:40 | * | Rick looks through those |
| 08:15:52 | * | HCl has one of those fuzzy black and white alarm clocks with a tail, thats hyperactive this morning. |
| 08:16:15 | Rick | hehe |
| 08:16:34 | HCl | but at least my alarmclock cuddles me in the morning |
| 08:16:37 | HCl | sup? |
| 08:16:42 | HCl | hows remote lcd? |
| 08:16:48 | LinusN | Rick: looks like it is a general purpose output, for a separate lcd segment |
| 08:16:49 | Rick | working |
| 08:16:54 | Rick | LinusN: ah |
| 08:17:09 | LinusN | like the icons on the archos Studio |
| 08:17:15 | Rick | ah |
| 08:17:23 | LinusN | so we can forget it |
| 08:17:26 | * | Rick nods |
| 08:17:33 | Rick | test instructions don't do anything obvious |
| 08:17:36 | Rick | :( |
| 08:18:24 | LinusN | stay away from them |
| 08:18:45 | stevenm | I am going to sleep now, exam tomorrow.. prolly shove some studying in there somewhere too.. Good night all |
| 08:18:46 | HCl | any idea how fast the remote lcd is gonna be? |
| 08:18:49 | Rick | okay ;P |
| 08:18:52 | HCl | night steven |
| 08:18:53 | Rick | HCl: in what sense? |
| 08:19:01 | HCl | updating it quickly |
| 08:19:08 | | Quit stevenm ("Leaving") |
| 08:19:08 | HCl | video, games, etc. |
| 08:19:13 | Rick | dunno... |
| 08:19:18 | HCl | kay |
| 08:19:28 | Rick | I havn't gotten any display from writing to the lcd yet |
| 08:19:34 | HCl | okay |
| 08:19:36 | Rick | looking at how that's done now |
| 08:19:54 | HCl | sorry, i thought that was included when you said it was working :p |
| 08:20:14 | Rick | oh |
| 08:20:20 | Rick | we don't have lcd_remote_set_pixel etc yet |
| 08:20:23 | HCl | okay |
| 08:20:23 | Rick | but it turns on and stuff ;P |
| 08:20:27 | Rick | and we can set contrast ;) |
| 08:20:29 | * | HCl nods |
| 08:20:31 | HCl | i read :) |
| 08:20:35 | Rick | hehe |
| 08:20:45 | * | HCl is probably gonna go back to sleep if his alarmclock can calm down |
| 08:20:58 | Rick | from what I can see it should be as simple as writing data |
| 08:21:01 | Rick | no commands needed |
| 08:21:05 | Rick | I wonder why my test didn't work |
| 08:21:55 | * | Rick makes a quick&dirty for loop |
| 08:22:11 | HCl | whats the resolution of the thing/ |
| 08:22:12 | HCl | ? |
| 08:22:25 | Rick | 65xsomething |
| 08:22:26 | * | Rick checks |
| 08:23:01 | Rick | 65x132 |
| 08:23:02 | Rick | I think |
| 08:23:05 | HCl | kay |
| 08:23:14 | HCl | sounds a bit like archos lcd, heh |
| 08:23:15 | Rick | which should mean it's sitting on it's side |
| 08:23:41 | HCl | just a matter of altering the setpixel things to get it upright |
| 08:23:48 | Rick | yeah |
| 08:23:52 | HCl | uhoh, there's my alarmclock again |
| 08:23:55 | Rick | hmm |
| 08:23:57 | Rick | still not displaying |
| 08:24:19 | * | Rick looks at write code |
| 08:24:39 | HCl | he doesn't like my incense, heh :x |
| 08:26:09 | Rick | hmm |
| 08:26:10 | Rick | looks fine to me |
| 08:26:59 | amiconn | LinusN: Do you now agree that supporting some standard bitmap formats is a good thing? The remote lcd has a different native format than the main lcd. If we'd only support native format, how would this be handled? Having all bitmaps in 2 different formats? What about the fonts? .... |
| 08:28:00 | LinusN | it's a good thing but a slow thing |
| 08:28:24 | | Join rasher [0] (~82e1029f@labb.contactor.se) |
| 08:28:30 | HCl | you can easily re-render 2bit formats to 1bit.. |
| 08:29:02 | HCl | pixel=pixel&2; |
| 08:29:49 | amiconn | That's per pixel... certainly not fast enough for converting larger images |
| 08:30:08 | rasher | stevenm here still? |
| 08:30:38 | amiconn | LinusN: It's certainly slower than just blitting, but it's simply necessary on the iriver. And I still think it can be made rather fast (not in C though) |
| 08:30:52 | amiconn | Remember my 'geek' bitswap? |
| 08:31:00 | LinusN | yes |
| 08:31:32 | | Join Harpy [0] (sjkQSqNz8J@dsl-hkigw7wbb.dial.inet.fi) |
| 08:32:18 | Rick | hrm |
| 08:32:27 | * | Rick wonders why it doesn't work |
| 08:33:49 | rasher | stevenm: if you happen to read this later on - I have no program to play the file now.. got a 17mb dsp.raw.. here's the result: http://rasher.dk/dsp.raw.bz2 (still uploading) |
| 08:34:14 | LinusN | rasher: why not make it a wav? |
| 08:34:36 | rasher | don't ask me :) I'm just testing it |
| 08:34:54 | LinusN | the name midi2wav sort of implies it :-) |
| 08:35:02 | rasher | Truly |
| 08:35:03 | HCl | pixel=(pixel1&0xAA)>>1|pixel2&0xAA)? |
| 08:35:21 | * | HCl still thinks you can make it pretty fast.. |
| 08:35:27 | pabs | i wish work wasn't kicking my ass, you guys are talking about fun stuff and i want to contribute :( |
| 08:35:49 | rasher | (upload done.. it's a 48khz 16-bit raw pcm file I think) |
| 08:35:51 | rasher | bye |
| 08:35:56 | | Quit rasher ("CGI:IRC 0.5.4 (2004/01/29)") |
| 08:36:23 | HCl | hmm, my code is flawed :x |
| 08:36:33 | HCl | it'd mix up the pixel rows a bit xD |
| 08:36:34 | Rick | LinusN: what does MSB / LSB mean? |
| 08:36:50 | LinusN | most/least significant byte |
| 08:36:55 | Rick | aha |
| 08:37:02 | LinusN | i.e upper/lower part of a word |
| 08:37:06 | Rick | right |
| 08:37:16 | * | HCl goes back to sleep |
| 08:37:17 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
| 08:38:59 | Rick | I wonder why it's ignoring my write data then |
| 08:39:02 | Rick | everything seems fine |
| 08:40:05 | LinusN | show me the code |
| 08:40:24 | Rick | b = 255; |
| 08:40:26 | Rick | lcd_remote_write_data(&b, 1); |
| 08:41:31 | LinusN | try writing a whole chunk of data |
| 08:41:54 | Rick | okay, although I don't see how that'll make a difference ;P |
| 08:42:22 | LinusN | maybe not all segments are used |
| 08:42:27 | Rick | well |
| 08:42:35 | Rick | I had it try doing that single byte write 100 times |
| 08:42:37 | LinusN | and the line/column you selected isn't visible |
| 08:42:45 | LinusN | ok |
| 08:42:45 | Rick | setting 0/0 by default |
| 08:42:51 | Rick | from the spec |
| 08:42:55 | Rick | after the 8th page |
| 08:43:01 | Rick | its "invalid" |
| 08:43:08 | Rick | 9th page is special for the static indicator |
| 08:43:50 | Rick | lemme try setting to the 1st page |
| 08:43:51 | Rick | instead of 0 |
| 08:44:36 | LinusN | init line seems to be wrong |
| 08:44:56 | LinusN | should be 0x20, not 0x40 |
| 08:45:01 | LinusN | no |
| 08:45:04 | LinusN | me silly |
| 08:45:25 | Rick | hehe |
| 08:46:23 | Rick | still nothig |
| 08:46:30 | Rick | *nothing |
| 08:46:32 | Rick | with page 1 |
| 08:48:13 | LinusN | which contrast are you using? |
| 08:48:28 | Rick | 31 |
| 08:48:31 | Rick | er |
| 08:48:31 | Rick | 32 |
| 08:48:35 | LinusN | ok |
| 08:48:38 | Rick | which is default |
| 08:48:41 | Rick | so I assume that's fine |
| 08:49:20 | LinusN | hey, try ENTIRE_DISPLAY |
| 08:49:29 | Rick | okay |
| 08:51:13 | Rick | still nothing |
| 08:51:47 | LinusN | aha, so we must have done something wrong, since the pixels don't work |
| 08:51:54 | Rick | if you look at the example on 42 |
| 08:51:59 | Rick | what does it mean by write display on/off? |
| 08:52:06 | Rick | by instruction |
| 08:52:10 | Rick | because there is no command to do that |
| 08:52:42 | LinusN | page 30 |
| 08:52:58 | Rick | what about it? |
| 08:53:06 | LinusN | 6-4 diaplsy on/off |
| 08:53:09 | LinusN | display |
| 08:53:29 | Rick | so why does it say 'write display on/off' |
| 08:53:38 | Rick | then 'turn display on/off' |
| 08:53:49 | LinusN | "write" probably means "write command" |
| 08:54:34 | LinusN | i admit that it's confusing |
| 08:55:03 | * | Rick nods |
| 08:55:10 | LinusN | it may mean "write the data you want to display" |
| 08:58:34 | Rick | interesting |
| 08:58:43 | Rick | starting it in a higher voltage makes the screen go weird |
| 08:58:44 | Rick | ;p |
| 08:59:45 | LinusN | hehe |
| 09:00 |
| 09:00:07 | Rick | in 5.5 |
| 09:00:09 | Rick | screen is black |
| 09:00:11 | Rick | with white dots |
| 09:00:16 | Rick | strewn across it |
| 09:00:23 | Rick | which is odd |
| 09:00:28 | Rick | because I get that with 5.0 in bias 1 |
| 09:00:49 | LinusN | maybe we should check what the iriver firmware does |
| 09:00:58 | Rick | I thought about that |
| 09:00:59 | Rick | but |
| 09:01:08 | Rick | I don't have a disassembler that works with the coldfire |
| 09:01:21 | LinusN | yes you do |
| 09:01:25 | Rick | I do? |
| 09:01:36 | LinusN | m68k-elf-objdump |
| 09:01:50 | Rick | command not found |
| 09:02:04 | LinusN | how do you build rockbox then? |
| 09:02:10 | Rick | in cygwin |
| 09:02:17 | LinusN | with the "devkit"? |
| 09:02:20 | * | Rick nods |
| 09:02:27 | LinusN | damn bluechip |
| 09:02:31 | Rick | hehe |
| 09:02:36 | Rick | I stripped most of his junk out though |
| 09:02:47 | LinusN | junk? |
| 09:02:58 | Rick | the stupid headers and hotkeys |
| 09:03:03 | Rick | s/headers/banners/ |
| 09:03:27 | LinusN | i must admit that i never tried the devkit |
| 09:03:37 | Rick | it's basically a stripped down cygwin |
| 09:03:44 | Rick | that only provides exactly what's needed to build rockbox |
| 09:03:48 | Rick | makes everything really easy |
| 09:04:16 | Rick | compared to using vmware it's much faster to dev in |
| 09:04:41 | LinusN | but dead slow compared to linux |
| 09:04:49 | * | Rick nods |
| 09:04:56 | Rick | but vmware is slower than cygwin |
| 09:05:01 | Rick | which is why I opted for the devkit |
| 09:06:46 | LinusN | so we might have to tweak the voltage / bias |
| 09:06:58 | pabs | i'd just like to add that i live my h120, i'd never get any work done if it wasn't for it :D |
| 09:07:01 | Rick | yeah, that's why I started playing with it |
| 09:07:07 | LinusN | you should create a debug menu for this |
| 09:07:08 | pabs | s/li/lo/ |
| 09:07:27 | pabs | and all of you bastards better save something fun for me to work on |
| 09:07:33 | Rick | hmm, that's a good idea LinusN |
| 09:07:37 | pabs | because i'm almost through my deadlines |
| 09:07:41 | Rick | but can you set the voltage after it's already set? |
| 09:07:46 | * | pabs goes back to lurking |
| 09:07:58 | Bagder | pabs: we'll save some sweet spots for you |
| 09:08:03 | pabs | cool thanks |
| 09:08:06 | LinusN | Rick: i use to add stuff to the dbg_ports() function |
| 09:08:22 | LinusN | Rick: i think you can do that |
| 09:08:27 | Rick | okay |
| 09:08:56 | LinusN | hi Bagder |
| 09:09:01 | Bagder | morning |
| 09:09:12 | Rick | hrm |
| 09:09:15 | Rick | what am I looking to add? |
| 09:09:41 | | Nick Lynx_awy is now known as Lynx_ (HydraIRC@134.95.189.59) |
| 09:09:43 | LinusN | stuff like using the joystick to increas/decrease voltage etc |
| 09:11:07 | LinusN | just to decrease the turnaround time for testing |
| 09:11:14 | Rick | right |
| 09:11:23 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 09:11:37 | LinusN | let's hope that we can't kill the display with high voltage :-) |
| 09:11:40 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
| 09:11:52 | Rick | well |
| 09:11:55 | Rick | I set it to the highest |
| 09:11:58 | Rick | and the screen was completely black |
| 09:16:12 | | Join bobTHC [0] (~foo@l06v-7-200.d1.club-internet.fr) |
| 09:16:19 | bobTHC | hi folks ! |
| 09:16:50 | Rick | hi |
| 09:20:44 | ashridah | gah. damned mindless habits. |
| 09:21:04 | Rick | k |
| 09:21:06 | Rick | got the basic thing in |
| 09:21:07 | ashridah | first thing i do after running make? make clean, without even thinking :( |
| 09:22:40 | Rick | hahaha |
| 09:22:46 | Rick | that's gotta suck |
| 09:22:56 | ashridah | fortunately compiling rockbox doesn't take too long |
| 09:23:08 | Rick | hehe |
| 09:23:48 | ashridah | hrm. okay. when rolo asks me if i want to load a new rockbox after copying one on, does 'press PLAY' actually mean the play button? because it doesn't seem to do anything... :) |
| 09:23:55 | Rick | LinusN: doesn't seem to be helping at all |
| 09:23:58 | Rick | I just went through all voltages |
| 09:23:59 | ashridah | or is it bound to navi or something |
| 09:24:00 | Rick | on both bias |
| 09:24:12 | Rick | none of them displayed the line I should have drawn |
| 09:24:17 | Bagder | ashridah: I believe you should click the navi button, yes |
| 09:24:37 | Rick | select, not play |
| 09:24:37 | Rick | ;p |
| 09:25:09 | Rick | everything after 4 is really dark |
| 09:25:26 | Rick | everything before 4 is barely visible |
| 09:25:34 | Rick | (4 = 5.0 volt) |
| 09:27:35 | Rick | made a thing to play with the contrast |
| 09:27:43 | * | HCl decides to wake up, make coffee, and start to look at a proper id3 db thing for rockbox, probably itunesdb |
| 09:29:42 | ashridah | HCl: can i take another short browse through your rom collection? :) |
| 09:31:32 | Rick | hrm |
| 09:31:34 | Rick | interesting |
| 09:31:58 | | Nick QT_ is now known as QT (as@area51.users.madwifi) |
| 09:36:13 | *** | Saving seen data "./dancer.seen" |
| 09:39:13 | Rick | LinusN: how do you prepare the firmware to work with m68k-elf-objdump? |
| 09:40:51 | | Join austriancoder [0] (~austrianc@80.120.117.30) |
| 09:41:01 | austriancoder | good morning all |
| 09:41:07 | Rick | austriancoder! |
| 09:41:10 | Rick | just the person we need |
| 09:41:12 | Rick | ;) |
| 09:41:15 | Rick | well, soonish |
| 09:41:21 | Rick | austriancoder: we've nearly got the lcd working |
| 09:41:26 | Rick | just having trouble with pixel stuff |
| 09:41:43 | austriancoder | ah fine |
| 09:42:16 | austriancoder | is the crunnet cvs version your version? |
| 09:42:19 | austriancoder | current |
| 09:42:29 | Rick | yes, but it's out of date |
| 09:42:34 | austriancoder | hmmm |
| 09:42:38 | austriancoder | update it :) |
| 09:42:42 | Rick | or maybe not |
| 09:42:47 | Rick | i didn't see linus updated it |
| 09:43:01 | Rick | yes |
| 09:43:03 | Rick | that one works |
| 09:43:07 | austriancoder | i also have cvs write access |
| 09:43:53 | Rick | the one in cvs is latest 'stable' so to speak ;P |
| 09:43:56 | Rick | should work fine |
| 09:44:00 | Rick | it turns on lcd and does nothing else |
| 09:44:01 | Rick | hehe |
| 09:44:30 | austriancoder | LinusN: what do you think about a #define HAVE_REMOTE_LCD in config-h100.h? |
| 09:45:02 | austriancoder | Rick: lets compile me the cureent cvs |
| 09:45:17 | Rick | :) |
| 09:47:45 | austriancoder | Rick: have you thought about how to integrate the remote lcd in rockbox's core? |
| 09:48:19 | Rick | howso? |
| 09:48:49 | austriancoder | current cvs does nothing on my remote lcd |
| 09:48:56 | Rick | oh |
| 09:48:58 | Rick | open up main.c |
| 09:49:04 | Rick | find lcd_init() (not the one in sim) |
| 09:49:07 | Rick | add lcd_remote_init(); |
| 09:49:09 | Rick | afte rit |
| 09:49:11 | Rick | *after it |
| 09:49:14 | austriancoder | ah.. ok :) |
| 09:49:29 | * | Rick pokes LinusN |
| 09:50:56 | austriancoder | ok.. runs now |
| 09:51:25 | LinusN | back |
| 09:51:47 | austriancoder | i will expand the plugin api to try make test easier for testing the remote lcd - thats ok? |
| 09:51:55 | LinusN | HCl: what do you mean with "proper" id3 database? |
| 09:52:18 | Rick | austriancoder: sure, just don't commit that |
| 09:52:18 | Rick | ;P |
| 09:53:01 | austriancoder | some time we need it in the plugin api... but i will wait until we got it |
| 09:53:04 | Rick | LinusN: how do you prepare the firmware for objdump? |
| 09:53:12 | LinusN | unscramble it |
| 09:53:15 | Rick | did tht |
| 09:53:16 | Rick | *that |
| 09:53:21 | LinusN | then you're set |
| 09:53:39 | Rick | 'File format not recognized' |
| 09:54:29 | Rick | (tried with -d) |
| 09:56:25 | LinusN | m68k-elf-objdump -b binary -m m5200 -D ihp120.bin |
| 09:56:30 | austriancoder | LinusN: can i commit this changes? http://nopaste.php-q.net/127919 |
| 09:56:55 | Rick | ah |
| 09:56:58 | Rick | there it goes, thanks LinusN |
| 09:57:00 | | Nick tvelocity is now known as tvelocity[away] (~tony@ipa126.3.tellas.gr) |
| 09:57:01 | LinusN | austriancoder: sure |
| 09:57:05 | austriancoder | fine |
| 09:57:11 | austriancoder | more changes will follow :) |
| 09:57:24 | LinusN | Rick: m68k-elf-objdump −−help |
| 09:57:41 | Rick | yeah, I was looking through that |
| 09:57:42 | LinusN | −−start-address is probably interesting |
| 09:57:47 | Rick | ah |
| 09:57:56 | Rick | eek |
| 09:57:59 | Rick | 26mb of disassembly |
| 09:58:00 | * | Rick grins |
| 09:58:10 | LinusN | have fun |
| 09:58:17 | Rick | Hehe |
| 09:59:37 | HCl | LinusN: one that would allow on the fly playlists of "all songs of the 90's of more than 3 minutes long", among other things. |
| 10:00 |
| 10:00:03 | LinusN | what makes you think itunesdb helps you with that? |
| 10:00:59 | LinusN | the itunes database format sucks |
| 10:01:24 | LinusN | i suggest you read up on how the rockbox format works and extend it |
| 10:01:40 | LinusN | it wasn't conceived over night |
| 10:03:11 | LinusN | the rockbox format is basically a relational database |
| 10:03:47 | LinusN | so it should be fairly straightforward to add more tables |
| 10:04:10 | LinusN | did you have a look at the itunes database format? |
| 10:06:17 | HCl | yes, i did |
| 10:06:42 | HCl | and the reason for me to think that, is cause ipods are capable of doing what i just said :) |
| 10:06:50 | amiconn | Rick: VMware isn't slower than cygwin, it's actually way faster, at least for me |
| 10:07:28 | amiconn | Compiling a sim on cygwin takes ~3 minutes, while compiling on debian under VMware takes ~1 minute |
| 10:07:42 | amiconn | ...on the same machine of course. |
| 10:07:53 | HCl | but i can make a list of things that are lacking from the rockbox database, i guess. |
| 10:07:55 | bobTHC | it can, for the price to be faster : |
| 10:08:04 | Rick | amiconn: I'm referring to botting up linux compared to running cygwin console ;P |
| 10:08:09 | Rick | *booting |
| 10:08:13 | austriancoder | basic version of remotelcd plugin works |
| 10:08:20 | austriancoder | backlight on/off |
| 10:08:37 | austriancoder | now i want something to draw ;) |
| 10:08:37 | amiconn | Rick: Then leave it running :P |
| 10:08:54 | Rick | boo :p |
| 10:08:56 | LinusN | austriancoder: that's the problem |
| 10:09:17 | LinusN | or did i miss something? |
| 10:09:30 | austriancoder | LinusN; why? sure there are some functions missing, but i will try to use mine |
| 10:09:54 | Rick | I can't get it to display written data |
| 10:09:59 | Rick | i've tried a bunch of stuff |
| 10:10:01 | LinusN | so far we haven't been able to make the lcd draw anything |
| 10:10:07 | | Quit webguest65 ("CGI:IRC (EOF)") |
| 10:10:18 | HCl | the ipod format seems great, seriously o.o |
| 10:10:19 | austriancoder | hmmm.. lets see what we can do |
| 10:10:31 | austriancoder | rick: can you show me your drawing source? |
| 10:10:44 | HCl | it may not be suitable for archos, but i'm talking iriver only here |
| 10:11:33 | LinusN | and i'm talking both |
| 10:11:43 | Rick | austriancoder: define drawing source? |
| 10:11:49 | Rick | i'm just trying to write four bytes |
| 10:11:49 | LinusN | source code |
| 10:11:59 | Rick | char buf[] = "\xFF\xFF\xFF\xFF"; |
| 10:12:03 | Rick | lcd_remote_write_data(buf, 4); |
| 10:12:04 | HCl | sorry, but i seriously think that the current format is *not* suitable for anything advanced :/ |
| 10:12:08 | bobTHC | it's a duty to make it work on all device imho |
| 10:12:13 | LinusN | Rick: you should use 0x55 btw |
| 10:12:16 | HCl | it doesn't even keep track of playcount, year, genre etc. |
| 10:12:20 | Rick | LinusN: for? |
| 10:12:26 | HCl | rating |
| 10:12:34 | HCl | bitrate, length of the track |
| 10:12:40 | HCl | volume adjustment |
| 10:12:45 | HCl | last time played |
| 10:12:48 | LinusN | Rick: then you won't be bitten by thing like inverted pixels etc |
| 10:12:51 | HCl | and i can go on and on and on |
| 10:13:02 | Rick | ah |
| 10:13:08 | HCl | about stuff that at least i would seriously want into an id3 db |
| 10:13:09 | Bagder | HCl: as usual, we are open to improvements |
| 10:13:14 | LinusN | HCl: why should that be in the id3 database? |
| 10:13:22 | HCl | Bagder: that was what i was going to do :P |
| 10:13:38 | LinusN | no, you wanted to use itunesdb |
| 10:13:44 | HCl | LinusN: cause you want to create playlists concerning conditions of that? |
| 10:13:56 | HCl | yes, itunesdb seems like a good format to use. |
| 10:14:04 | HCl | since there are already plenty of tools that can create it. |
| 10:14:04 | LinusN | yes, but that whould not be in the same database imho |
| 10:14:32 | HCl | wouldn't you want a database with all data about 1 song, rather than having to open multiple databases? |
| 10:14:33 | Bagder | I agree that the run-time based info should probably be kept separate |
| 10:14:46 | Rick | whoa |
| 10:14:47 | Rick | it drew |
| 10:14:48 | Rick | I think |
| 10:14:54 | Bagder | since then it could be stored even *without* an initial db |
| 10:14:56 | austriancoder | :) |
| 10:15:00 | Rick | in the bottom right corner |
| 10:15:17 | HCl | okay, so then you'd still have volume adjustment, year, genre |
| 10:15:18 | Bagder | what is the resolution of the remote lcd? |
| 10:15:22 | HCl | rating |
| 10:15:26 | HCl | okay, not rating :) |
| 10:15:29 | Rick | 65x134 |
| 10:15:31 | HCl | shall i just start on a second database then |
| 10:15:34 | HCl | for runtime info? |
| 10:15:36 | Bagder | thanks |
| 10:15:40 | LinusN | HCl: yes |
| 10:15:42 | austriancoder | Rick: so we will make now a framebuffer for the remote lcd :) |
| 10:15:43 | Bagder | HCl: I think so |
| 10:16:00 | HCl | i'll start a wiki topic on it.. |
| 10:16:07 | LinusN | HCl: the rockbox database format is optimized for partial loading and fast indexing |
| 10:16:16 | HCl | i know |
| 10:16:17 | HCl | cause of archos. |
| 10:16:35 | Bagder | not only |
| 10:16:42 | Bagder | it is made to require little ram |
| 10:16:47 | bobTHC | cause of battery saving too |
| 10:16:48 | Bagder | that is good for iriver too |
| 10:16:49 | LinusN | common sense |
| 10:17:23 | Bagder | waste disk space to gain cpu cycles and ram |
| 10:18:30 | HCl | out of sheer curiousity. in the current rockbox format |
| 10:18:44 | HCl | if its optimized for speed and stuff, why aren't filenames linked to song structures? |
| 10:19:31 | Bagder | song structures? |
| 10:19:48 | HCl | "name of song1" "pointer to artist" "pointer to album" "pointer to filename" |
| 10:20:06 | Rick | hrm |
| 10:20:09 | Rick | I wonder what voltag it sets it to |
| 10:20:31 | HCl | cause now we have to check each pointer in order to find the actual name of a song? or am i completely wrong. |
| 10:20:51 | Bagder | feel free to improve |
| 10:20:57 | HCl | heh. |
| 10:21:09 | HCl | i'm tempted to overhaul the wiki, but i'll start with a runtime database.. |
| 10:21:09 | Bagder | but storing everything everywhere might bloat it a bit too much |
| 10:21:30 | Bagder | remember we have 120GB disks these days |
| 10:22:15 | amiconn | Bagder: pls also remember that we support flash based devices as well. |
| 10:22:25 | Bagder | indeed |
| 10:22:47 | amiconn | I just got a 2 GB MMC, but these are quite expensive... |
| 10:23:09 | Bagder | so we mustn't bloat too much |
| 10:23:32 | * | HCl doesn't see much of a problem in having seperate database types for limited machines and less limited machines. |
| 10:23:50 | HCl | all it has to do is create a playlist, after that it doesn't even have to access the database anymore |
| 10:23:56 | Bagder | other than that we need to maintain more code |
| 10:24:13 | LinusN | HCl: we *browse* the database too |
| 10:24:13 | Bagder | and document more differences |
| 10:24:32 | Bagder | browsing is an important part |
| 10:24:40 | HCl | LinusN: i'm not planning on adding browse support for the runtime database. should it? |
| 10:24:56 | HCl | i'm more planning to "create me a playlist of all rocksongs of the 80's and 90's that last longer than 3 minutes" |
| 10:24:58 | Bagder | people will ask for it ;-) |
| 10:25:00 | LinusN | i thought you meant the id3 databse |
| 10:25:09 | HCl | the id3 database is part of it, really. |
| 10:25:19 | HCl | cause you need to be able to search on id3 data as well as runtime data |
| 10:30:03 | Bagder | I'll read your suggestion when you've written it! ;-) |
| 10:30:25 | HCl | i'd probably go ahead and make it as a hack or plugin if you wouldn't approve anyways ;p |
| 10:30:32 | HCl | but not commit it into main cvs |
| 10:31:19 | bobTHC | how much cpu for extracting id3 info on the fly for an archos ? |
| 10:31:38 | bobTHC | just for one file |
| 10:32:00 | Bagder | who's christian? |
| 10:32:20 | bobTHC | not me ;) |
| 10:34:04 | LinusN | bobTHC: cpu time isn't the issue, disk access time is |
| 10:34:36 | bobTHC | it's a long seek ? |
| 10:34:49 | HCl | why can't we load it into ram like iriver and ipod seem to do? |
| 10:34:51 | Bagder | spinning up the disk takes ages |
| 10:36:03 | Bagder | HCl: and how much space would you want to waste on that? |
| 10:36:38 | HCl | somewhere between 4-1mb |
| 10:36:40 | HCl | o.o |
| 10:36:58 | Bagder | wow |
| 10:37:01 | HCl | i don't see why we would need 28mb of ram just to decode music. |
| 10:37:27 | Bagder | to save batteries |
| 10:37:37 | HCl | does it cost batteries to store stuff in ram? |
| 10:37:39 | bobTHC | why not make the first and big sort with already done database and add for more refine querry just extracting missing id3 info of the presearch files |
| 10:37:47 | Bagder | HCl: yes, since we need to spin up the disk more often |
| 10:37:57 | HCl | no, you just spin it up once at bootup |
| 10:37:58 | HCl | o.o |
| 10:38:10 | Bagder | HCl: sure, but we get less buffer to use for music buffering |
| 10:38:12 | HCl | and unlike iriver, you run the database loading in the background. |
| 10:38:26 | Bagder | ls -l songdb |
| 10:38:26 | Bagder | -rw-r−−r−− 1 daniel daniel 1400796 Apr 15 10:38 songdb |
| 10:38:26 | HCl | yes, i fail to see how we would need 28mb of ram for that |
| 10:38:26 | HCl | o.o |
| 10:38:42 | HCl | we'll see |
| 10:38:45 | * | HCl shrugs |
| 10:38:49 | LinusN | HCl: i use my player to play music |
| 10:38:59 | HCl | same, but i'd want a good interface with it. |
| 10:39:00 | LinusN | that's what i want my RAM to be used for |
| 10:39:05 | austriancoder | LinusN: would it be a good idea to have an own lcd-remote.h in the exort folder? |
| 10:39:11 | HCl | and i'll sacrifice that any day for song loading time |
| 10:39:19 | LinusN | austriancoder: perhaps |
| 10:39:40 | Bagder | HCl: it needs to be a good compromise. If you'll waste 4MB, I would disable the feature and I wouldn't use it |
| 10:39:43 | LinusN | "song loading time"? |
| 10:39:46 | austriancoder | ok... than we will do it |
| 10:39:47 | Bagder | if it used less, I could use it |
| 10:39:53 | HCl | Bagder: then disable it :p |
| 10:40:03 | HCl | i'm not forcing anyone. |
| 10:40:05 | Bagder | HCl: I wouldn't be alone thinking like this |
| 10:40:12 | Bagder | I just think it would be a pity |
| 10:40:13 | HCl | i don't care XD |
| 10:40:22 | HCl | i just want to have a nice access to my music. |
| 10:40:23 | Bagder | so why do you ask at all? |
| 10:40:36 | HCl | so i'm gonna work on making it happen :) |
| 10:40:46 | HCl | no matter how many people don't want it, heh. |
| 10:40:53 | Bagder | we want it |
| 10:40:56 | Bagder | we just want it done good |
| 10:41:05 | HCl | its gonna be on the wiki, heh. |
| 10:41:10 | Bagder | :-) |
| 10:41:11 | HCl | you're free to add suggestions |
| 10:41:17 | bobTHC | it's the rockbox principle ! |
| 10:41:27 | HCl | i'm pretty much going from the itunesdb, what that can do |
| 10:41:39 | HCl | and i'm splitting it up into stuff that should go into the tagdatabase and the runtime database at the moment. |
| 10:43:07 | HCl | hmm.... |
| 10:43:09 | HCl | i'm wondering. |
| 10:43:18 | HCl | would it be possible to add a FAT file with a certain date. |
| 10:43:24 | HCl | count the time that passes when rockbox runs |
| 10:43:30 | HCl | hm, nm. |
| 10:43:39 | HCl | Last played time is gonna be difficultish :/ |
| 10:43:48 | Bagder | yes |
| 10:43:50 | HCl | unless we make it relative or something. |
| 10:43:56 | HCl | count the total amount of time the player has been on |
| 10:44:01 | LinusN | not on the archos :-) |
| 10:44:19 | LinusN | the recorder has a real time clock |
| 10:44:24 | HCl | mhm |
| 10:44:32 | HCl | but i don't think you'll want to run this runtime database on an archos, heh. |
| 10:44:41 | LinusN | why not? |
| 10:44:46 | HCl | too big? |
| 10:45:02 | LinusN | why would you make it that big? |
| 10:45:09 | HCl | lots of features :) |
| 10:45:18 | LinusN | you're missing the point here |
| 10:45:34 | HCl | no, we just have different goalsets |
| 10:45:35 | HCl | :) |
| 10:45:47 | Bagder | not different goals |
| 10:45:54 | HCl | mmm? |
| 10:45:56 | Bagder | just different approaches of solving the problems |
| 10:46:00 | | Quit edx (Read error: 60 (Operation timed out)) |
| 10:46:04 | HCl | maybe |
| 10:46:08 | Bagder | I agree with that you want to achieve |
| 10:46:13 | HCl | so far the runtime database isn't that big yet. |
| 10:46:18 | Bagder | I just don't want to waste megabytes on it |
| 10:46:42 | HCl | it might be possible to have it in a format like the current binary format. |
| 10:46:57 | Bagder | and it shouldn't need to keep the whole thing in ram |
| 10:47:03 | HCl | but i still prefer it to be loaded in memory for easy searching. |
| 10:47:30 | LinusN | then load it when you search |
| 10:47:43 | HCl | thats inefficient for multiple searches over a day |
| 10:48:22 | LinusN | so you want to waste 4Mb of music buffer to do fast searches "several times a day" |
| 10:48:24 | Bagder | and remember we don't have malloc |
| 10:48:31 | HCl | yup o.o |
| 10:48:37 | HCl | i don't see why we would need 28mb of ram |
| 10:48:40 | Bagder | you'd need to use a fixed size |
| 10:48:58 | Bagder | HCl: for battery saving |
| 10:49:00 | HCl | i'm aware of that |
| 10:49:14 | HCl | i still don't see how spinning up the disk every time for runtime data |
| 10:49:17 | HCl | is more efficient |
| 10:49:19 | HCl | than having it into ram |
| 10:49:22 | HCl | and altering it there |
| 10:49:26 | HCl | and writing it to disk on shutdown |
| 10:49:28 | Bagder | not every time, and how often would you do it? |
| 10:49:39 | amiconn | Embedded programming is not windows programming. On windows you may waste memory, on embedded devices you shouldn't... |
| 10:49:39 | HCl | for runtime stats, after every time a song is played. |
| 10:49:47 | LinusN | HCl: you don't need the entire database in ram to store playback data |
| 10:49:56 | Bagder | HCl: you could easily cache N songs' of data |
| 10:50:05 | HCl | LinusN: no, we don't, but we do for searching easily. |
| 10:50:09 | LinusN | and save it the next time the disk spins up |
| 10:50:09 | Bagder | and save them when the disk is spinning for other reasons |
| 10:50:21 | Bagder | hehe |
| 10:50:35 | LinusN | seems we don't speak the same language |
| 10:54:51 | Bagder | HCl: thing is, everyone can think of features that could use 4MB ram. So if everyone tries *hard* to limit the usage, we can cram in more features |
| 10:55:03 | Bagder | rather than everyone spending 4MB each |
| 10:55:09 | Rick | seems we'll be able to copy most of the lcd functions over |
| 10:55:14 | HCl | Bagder: i realize that, i'll try to keep it as small as possible. |
| 10:55:15 | Rick | I just tested lcd_remote_drawrrect |
| 10:55:16 | Rick | works fine |
| 10:55:27 | Bagder | Rick: rocking! |
| 10:56:33 | Rick | the only problem is it draws from the bottom right corner |
| 10:56:55 | Bagder | up-side-down? |
| 10:57:00 | Rick | and flipped |
| 10:57:16 | Bagder | sounds like you should modify the update function then |
| 10:57:22 | Rick | indeed |
| 10:57:35 | Bagder | having switched coordinates will be... crazy ;-) |
| 10:59:46 | Rick | oh wait |
| 10:59:49 | Rick | I have a better idea |
| 11:00 |
| 11:00:02 | Rick | i'll init the stuff to read backwards |
| 11:00:05 | Rick | the hardware |
| 11:00:58 | Rick | nearly works |
| 11:01:40 | LinusN | Rick: great |
| 11:02:11 | Rick | it seems one pixel line is missing |
| 11:02:13 | Rick | on the edge |
| 11:02:37 | HCl | hmmm. |
| 11:02:58 | * | HCl has daydreams of a "Best Rated" playlist on iriver |
| 11:03:02 | LinusN | Rick: what did we do wrong when it didn't display anything? |
| 11:03:03 | HCl | anyways. |
| 11:03:06 | * | HCl lags. |
| 11:03:08 | Rick | ugh... |
| 11:03:09 | Rick | too tired |
| 11:03:11 | Rick | good night |
| 11:03:15 | LinusN | Rick: stop |
| 11:03:28 | HCl | i added the first version of the runtimedatabase proposal on the wiki |
| 11:03:41 | LinusN | Rick: upload what you have, so i can commit |
| 11:03:42 | HCl | grab your butcherknifes and go butcher it :P |
| 11:03:42 | Rick | stop? |
| 11:03:45 | Rick | yes |
| 11:03:47 | Rick | i'm doing that no |
| 11:03:48 | Rick | w |
| 11:03:50 | LinusN | good |
| 11:03:54 | Rick | but it's probably going to break something |
| 11:04:25 | Rick | so be warned, or something |
| 11:04:48 | HCl | projected runtime database size with 4000 songs:2124000 |
| 11:05:04 | Rick | http://rick.gibbed.us/lcd-h100-remote.c |
| 11:05:07 | ashridah | holy crap |
| 11:05:17 | Rick | http://rick.gibbed.us/lcd-remote.h |
| 11:05:27 | HCl | mostly due to the filename bit. |
| 11:05:28 | Bagder | HCl: I have 6000 |
| 11:05:45 | LinusN | HCl: filename can be limited to MAX_PATH |
| 11:05:48 | HCl | 60000 if you leave out filenames completed |
| 11:05:53 | HCl | LinusN: whats max_path? |
| 11:05:57 | Bagder | 260 |
| 11:05:58 | LinusN | which is 260 iirc |
| 11:05:58 | HCl | i assumed them to be 512bytes |
| 11:05:59 | HCl | okay |
| 11:05:59 | Rick | I think that's the changes |
| 11:06:02 | HCl | i'll change that. |
| 11:06:13 | LinusN | Rick: great |
| 11:07:07 | HCl | heh |
| 11:07:14 | HCl | exactly 1100000 bytes, with 4000 songs |
| 11:07:18 | | Join amiconn_ [0] (~jens@pD9E7ED40.dip.t-dialin.net) |
| 11:07:19 | HCl | now |
| 11:07:24 | Rick | austriancoder: see urls I gave up |
| 11:07:27 | Rick | I'm off to bed |
| 11:07:33 | HCl | night |
| 11:07:37 | LinusN | Rick: sleep tight |
| 11:07:47 | Rick | :) |
| 11:07:58 | austriancoder | good night |
| 11:08:02 | HCl | oh wait, i forgot to add the 4 bytes for the track item pointer :) |
| 11:08:19 | Bagder | that's the space used on disk, no need to have all that in ram... |
| 11:08:27 | austriancoder | Rick: i will take your work and try to finish it |
| 11:08:27 | * | Bagder repeats himself |
| 11:08:52 | ashridah | it's not like the iriver's firmware doesn't load an entire list of the directory structure anyway :) |
| 11:09:22 | ashridah | this can only be faster, if you only generate it once, not every startup/disconnect |
| 11:10:27 | | Quit amiconn (Nick collision from services.) |
| 11:10:28 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7ED40.dip.t-dialin.net) |
| 11:11:09 | HCl | feel free to add suggestions to the runtimedatabase wiki topic |
| 11:11:14 | Bagder | HCl: what is 'file ID' going to be? and index into the tagdatabase? |
| 11:11:24 | Bagder | an index |
| 11:11:31 | HCl | Bagder: index back to the file item. |
| 11:11:34 | | Quit Lynx_ (" rebooting...") |
| 11:11:52 | Bagder | in the tagdatabse? |
| 11:11:53 | HCl | in theory, it would be better to link the tagdatabase to the runtime database, or have a similar format in the tagdatabase. |
| 11:12:04 | HCl | so we'd only have to store files once at one spot |
| 11:12:22 | HCl | and we really want to not have to dereference every pointer, but a pointer to the structure from the filename |
| 11:12:27 | Bagder | oh right, you store the file name in this too... |
| 11:12:30 | | Join webguest58 [0] (~c31ce021@labb.contactor.se) |
| 11:13:02 | Bagder | I guess one vitual q is: should this work without an initially generated tagdb? |
| 11:13:13 | Bagder | I guess it should |
| 11:13:39 | | Join rasher [0] (~82e1029f@labb.contactor.se) |
| 11:13:57 | HCl | it should, the only problem is shifting all the track items on disk when you add a new file |
| 11:14:06 | HCl | we could just make one big record |
| 11:14:11 | Bagder | shifting? |
| 11:14:21 | HCl | like, when you add a file |
| 11:14:28 | HCl | you need to add a File Item and a Track Item. |
| 11:14:28 | Bagder | they are ordered in a particular order? |
| 11:14:31 | HCl | yes. |
| 11:14:42 | HCl | see the database bit |
| 11:15:00 | Bagder | I don't see any mention of it |
| 11:15:02 | HCl | i guess the format can be easily adapted by just merging file items and track items. |
| 11:15:15 | HCl | sorry, it was a bit without explanation, let me paste |
| 11:15:36 | HCl | 1 Header |
| 11:15:36 | HCl | # amount of File Items (File Table) |
| 11:15:36 | HCl | # amount of Track Items (Track Table) |
| 11:15:36 | HCl | EOF |
| 11:15:52 | HCl | but if we could make the tagdatabase link to the file items |
| 11:15:54 | HCl | it would be better |
| 11:16:00 | Bagder | but it doesn't mention any particular order |
| 11:16:00 | HCl | maybe we should just have a seperate file database |
| 11:16:02 | | Join Lynx_ [0] (HydraIRC@134.95.189.59) |
| 11:16:04 | LinusN | or the other way around |
| 11:16:28 | HCl | i found the tagdatabase's format inflexible since it uses raw file offsets. |
| 11:16:30 | LinusN | the runtime database points to the tag database file itmes |
| 11:16:40 | Bagder | my thinking as well |
| 11:16:42 | LinusN | HCl: that's the beauty of it |
| 11:16:48 | HCl | i vote for a seperate file database with pointers to the tagdatabase and the runtime database. |
| 11:16:54 | Bagder | but it fails if the db is updated or this runs without db |
| 11:17:02 | HCl | i don't see why you would need to use raw file offsets when they can be easily calculated. |
| 11:17:21 | HCl | hence i vote for a seperate file database |
| 11:17:23 | Bagder | to reduce searching |
| 11:17:30 | HCl | Bagder: it wouldn't be searching |
| 11:17:31 | Bagder | an offset is just a seek and *done* |
| 11:17:33 | HCl | if you have the filename |
| 11:17:36 | HCl | and you have a record id |
| 11:17:45 | HCl | then an offset is as simple as record_id * sizeof(record) |
| 11:17:49 | Bagder | and what is a record id? |
| 11:17:54 | Bagder | an index |
| 11:17:57 | HCl | yea. |
| 11:18:02 | Bagder | == offset |
| 11:18:13 | HCl | not a raw one though. |
| 11:18:23 | HCl | just the number of the structure to access. |
| 11:18:26 | LinusN | HCl: we use file offsets because the records aren't fixed size |
| 11:18:27 | Bagder | I don't see the difference |
| 11:18:36 | HCl | then we need to make them fixed size. |
| 11:18:40 | Bagder | aaarrgh |
| 11:18:45 | Bagder | no no no |
| 11:18:52 | Bagder | the header defines the size |
| 11:18:53 | HCl | O.o. |
| 11:19:05 | rasher | aren't they fixed at max-size? |
| 11:19:14 | LinusN | rasher: no |
| 11:19:28 | rasher | hm.. I could've sworn.. |
| 11:19:28 | Bagder | yes, the run-time found max-size |
| 11:19:33 | rasher | yes, that |
| 11:19:35 | rasher | at generation time |
| 11:19:37 | Bagder | and the size is stored in the header and used |
| 11:20:02 | rasher | so I was right.. sortof |
| 11:20:06 | HCl | what are we talking about? a variable size determined by the longest songname? |
| 11:20:11 | HCl | or what? |
| 11:20:12 | rasher | yes |
| 11:20:13 | Bagder | HCl: yes |
| 11:20:18 | rasher | well, longest string of that type |
| 11:20:22 | HCl | okay, well. that may be okay for the tagdatabase. |
| 11:20:24 | Bagder | for all names, rather |
| 11:20:28 | rasher | goes for path, album etc as well |
| 11:20:29 | HCl | but if you want to add a song to the runtime database |
| 11:20:33 | HCl | it can be living hell. |
| 11:20:41 | HCl | and i'd really sacrifice the few bytes for that. |
| 11:20:41 | Bagder | HCl: I disagree |
| 11:20:47 | HCl | um. |
| 11:20:48 | HCl | okay. |
| 11:20:55 | HCl | say we want a new file added to the runtime database. |
| 11:20:56 | rasher | don't you just store a pointer into the tag-db? |
| 11:21:00 | Bagder | since I don't want the whole runtimedb in ram anyway |
| 11:21:07 | HCl | which is longer than the max filename so far. |
| 11:21:14 | HCl | we'd have to update EVERY filename |
| 11:21:17 | HCl | to the new maxsize |
| 11:21:30 | Bagder | not necessarily |
| 11:21:33 | * | rasher blinks |
| 11:21:38 | HCl | explain, heh. |
| 11:21:40 | * | HCl lags |
| 11:21:40 | LinusN | the tag database is supposed to contain all songs on the disk, isn't it? |
| 11:21:41 | Bagder | but if not, we need a way to "refresh" the db |
| 11:22:04 | Bagder | LinusN: yes, but we cannot depend on that imo |
| 11:22:07 | HCl | surely it will not contain all songs on disk, when someone quickly copies a song, etc. |
| 11:22:10 | HCl | yea. |
| 11:22:23 | rasher | can't you just ignore those songs for the runtimedb then? |
| 11:22:30 | HCl | plus we want the runtime database to work regardless of having a tagdatabase. |
| 11:22:36 | rasher | oh.. right |
| 11:22:43 | * | LinusN imagines a separate file for filenames |
| 11:22:44 | rasher | guess not then |
| 11:22:46 | HCl | i really vote for 3 databases, one storing filenames with record pointers t |
| 11:22:46 | HCl | yes |
| 11:22:49 | HCl | my thoughts exactly |
| 11:22:57 | HCl | pointers to tagdatabase , and runtime database |
| 11:22:59 | austriancoder | will there be the whish to support more then 2 lcds (lcd on player, remote lcd)? |
| 11:23:03 | rasher | Let's create a NEW file.. with hookers and blackjack |
| 11:23:04 | HCl | and -1 if there's no tagdatabase entry |
| 11:23:08 | LinusN | austriancoder: not yet |
| 11:23:14 | austriancoder | ok |
| 11:23:29 | austriancoder | so i will chage the setting menu to add support for ONE remote lcd |
| 11:23:33 | austriancoder | thats ok? |
| 11:23:36 | HCl | then we could easily add and work all 3 databases |
| 11:23:51 | LinusN | austriancoder: yes |
| 11:24:00 | HCl | and avoid storing things multiple times, like filenames. |
| 11:24:27 | LinusN | i think the file name "database" should contain nothing but file names |
| 11:24:51 | HCl | well, then you can't easily link filenames to tags and runtime data. |
| 11:24:52 | * | rasher manages to import the output of midi2wav into .... audacity |
| 11:25:02 | HCl | which imho is something you want. |
| 11:25:06 | LinusN | and the other two databased uses indexes/search offset into that file |
| 11:25:16 | rasher | woo, sounds fine |
| 11:25:19 | HCl | but we want to link from filename to tags and runtime info. |
| 11:25:20 | HCl | x.x; |
| 11:25:23 | HCl | not the other way around |
| 11:25:31 | HCl | most searches will be from filename-> metadata |
| 11:25:34 | HCl | not metadata->filename |
| 11:25:37 | rasher | MONKEY ISLAND! |
| 11:25:39 | LinusN | HCl: that's relational tables, which should be in the other two |
| 11:26:05 | HCl | then we'd have to search two databases to find the info |
| 11:26:06 | HCl | rather than 1 |
| 11:26:10 | LinusN | the filename is _only_ needed when you want to load the actual file from disk |
| 11:26:10 | rasher | (sorry, listening to midi from the iriver :) |
| 11:26:19 | HCl | how do we identify songs then? |
| 11:26:23 | LinusN | tags |
| 11:26:31 | HCl | unique id or what? |
| 11:26:38 | * | austriancoder makes a break |
| 11:26:41 | | Quit austriancoder ("using sirc version 2.211+KSIRC/1.3.11") |
| 11:26:51 | HCl | what if multiple songs have the same id3 tag? |
| 11:26:58 | rasher | then it's the same song anyway :) |
| 11:27:05 | HCl | not necessairily? |
| 11:27:11 | rasher | or people have their tags wrong... in which case, THEIR PROBLEM |
| 11:27:13 | * | rasher ducks |
| 11:27:15 | HCl | i disagree.. |
| 11:27:29 | HCl | i don't think we can trust id3 data to be unique. |
| 11:27:33 | Bagder | I agree |
| 11:27:37 | HCl | filename however, is. |
| 11:27:48 | rasher | is it? |
| 11:27:53 | HCl | yes. |
| 11:27:54 | LinusN | so you want to search the filename database |
| 11:27:54 | Bagder | assuming with never support CUE stuff |
| 11:27:58 | Bagder | we never |
| 11:27:59 | rasher | I mean, we can rename songs |
| 11:28:09 | HCl | with a rename, the database would get updated. |
| 11:28:15 | HCl | LinusN: yes. |
| 11:28:19 | rasher | >< |
| 11:28:23 | LinusN | omg |
| 11:28:29 | HCl | i want to search the filename database, and have it contain links to the tag databases and runtime database. |
| 11:28:33 | LinusN | no wonder you want that sucker in ram |
| 11:28:41 | rasher | Haha |
| 11:29:00 | HCl | mm? |
| 11:31:02 | LinusN | so when we play a file, we need to search the filename database to look up the record for the playtime info? |
| 11:31:09 | HCl | pretty much. |
| 11:31:20 | | Join mico [0] (mico@80.178.206.242.adsl.012.net.il) |
| 11:31:33 | HCl | we might be able to do a nasty trick with FAT records maybe |
| 11:32:11 | HCl | if we sort the filename database |
| 11:32:16 | HCl | searching it shouldn't be too hard. |
| 11:32:24 | HCl | but yea |
| 11:32:29 | HCl | thats just an option |
| 11:32:33 | HCl | and really something you want in ram, heh. |
| 11:33:12 | rasher | I like how the irssi mailing list gets around one mail/month |
| 11:33:21 | * | rasher rambles |
| 11:33:33 | rasher | ignore me. |
| 11:33:51 | | Quit webguest58 ("CGI:IRC (EOF)") |
| 11:34:09 | LinusN | my thinking is this: i would append the playtime info to a flat file, and then have a separate "rebuild database" function |
| 11:34:10 | rasher | Bad hobbit, I keep forgetting that there's actually such a thing as on and off topic here.. |
| 11:34:40 | LinusN | but that's me |
| 11:35:01 | HCl | we could ofcourse have something ugly like a copy of the entire tree structure on disk, with seperate tag and runtime data for each file |
| 11:35:14 | HCl | nasty. but it would work. |
| 11:35:32 | HCl | and fast too. |
| 11:35:41 | LinusN | but then you would still need a rebuild when you add a file to the disk |
| 11:35:57 | HCl | new files can be added on the fly |
| 11:36:04 | LinusN | when? |
| 11:36:05 | HCl | by creating the directory and the runtime data file |
| 11:36:16 | *** | Saving seen data "./dancer.seen" |
| 11:36:19 | HCl | when a file is played, a tagdatabase update would add the tag file for that file. |
| 11:36:50 | HCl | ofcourse, if you want to search through the data |
| 11:36:53 | HCl | it'll be a living hell. |
| 11:36:59 | HCl | which destroys our entire point :P |
| 11:37:03 | LinusN | exactly |
| 11:37:07 | Bagder | just playing it could simply keep data in ram |
| 11:37:21 | HCl | what do you mean with a flat file? |
| 11:37:22 | Bagder | and then flush it every once in a while |
| 11:37:35 | Bagder | then when you want to use it, you can refresh the db |
| 11:37:53 | LinusN | HCl: flat file = an unsorted file where you append file names/records |
| 11:37:59 | HCl | ah |
| 11:38:11 | HCl | sounds okish |
| 11:38:18 | HCl | then we would have a sorted filename database, i presume? |
| 11:38:25 | HCl | and we'd be able to binary search through it |
| 11:39:19 | LinusN | after the database update, that is |
| 11:39:21 | HCl | so we'd have a file database, a tag database, a runtime database, and a flatfile of things that need to get put into the database. |
| 11:39:39 | LinusN | basically, yes |
| 11:39:42 | HCl | but the flatfile would contain only new files and their respective records, correct? |
| 11:39:47 | LinusN | yes |
| 11:39:50 | HCl | and we'd have the filename database sorted. |
| 11:39:52 | HCl | okay. |
| 11:40:11 | HCl | shall i write it in the wiki? |
| 11:40:15 | LinusN | sure |
| 11:40:37 | HCl | i'll just put everything in the runtimedatabase topic for now.. |
| 11:42:27 | LinusN | do that |
| 11:45:25 | rasher | I wonder where my pr0n is hiding. My windows partition is full, and this usually means pr0n, music or something like that.. but I can find none of that (on that partition). What's up with that? |
| 11:47:32 | ashridah | lost clusters. yay! |
| 11:47:41 | LinusN | huge swap file |
| 11:48:07 | * | rasher pokes around |
| 11:49:24 | rasher | But yes, midi2wav produced a nice raw pcm file (48kHz, 16 bit signed) |
| 11:50:45 | rasher | Am I alone in thinking that the RPSL is gpl incompatible? |
| 11:51:54 | ashridah | RPSL? |
| 11:52:03 | Bagder | https://helixcommunity.org/content/rpsl |
| 11:52:06 | rasher | Real Public Source License.. or something like that |
| 11:52:09 | rasher | or that |
| 11:52:44 | ashridah | ah. probably not. what OSI think about it? |
| 11:52:57 | rasher | It's OSI approved |
| 11:53:00 | rasher | but that means squat |
| 11:53:17 | rasher | More or less, it just means that you can view and modify the code |
| 11:53:20 | Bagder | no, they approve GPL-incompatible ones too |
| 11:53:30 | rasher | Yes indeed |
| 11:53:41 | rasher | That's what I was trying to say :) |
| 11:53:43 | ashridah | hrm. wait a sec. did OSI approve sun's crappy license? |
| 11:54:02 | Bagder | rasher: anything particular in that license you think is unfitting for GPL? |
| 11:54:21 | rasher | Hrm.. I can't remember now :) |
| 11:54:27 | HCl | preglow asked ipodlinux about it yesterday. |
| 11:54:30 | Bagder | there's a lot of text |
| 11:54:33 | HCl | let me try to find what they replied. |
| 11:54:38 | HCl | i'm lagging a lot >.< |
| 11:55:35 | rasher | "In addition, you agree to the terms of this License by clicking the Accept button or downloading the software." |
| 11:55:41 | rasher | I think that does it really ? |
| 11:55:47 | Bagder | uhu |
| 11:55:57 | Bagder | yes, that cannot be compliant |
| 11:56:11 | rasher | no need to read past section 1 then |
| 11:56:13 | HCl | 21:39 < coob> you cna't relicense it under GPL, all modifications have to RPSL, |
| 11:56:17 | HCl | I don't really see the issue with that |
| 11:56:17 | HCl | 21:39 < coob> seeing how it's perpetual |
| 11:56:17 | HCl | 21:39 < coob> Note: because this license contains certain reciprocal licensing |
| 11:56:17 | HCl | terms that purport to extend to independently developed code, You |
| 11:56:17 | HCl | may be prohibited under the terms of these otherwise compatible |
| 11:56:19 | HCl | licenses from using code licensed under their terms with Covered |
| 11:56:21 | HCl | Code because Covered Code may only be licensed under the |
| 11:56:24 | HCl | RealNetworks Public Source License. Any attempt to apply non RPSL |
| 11:56:26 | HCl | license terms, including without limitation the GPL, to Covered |
| 11:56:29 | HCl | >.< |
| 11:56:31 | * | HCl slaps irssi |
| 11:56:36 | HCl | why can't it copy paste single lined pastes properly |
| 11:56:36 | HCl | sorry :( |
| 11:56:39 | Bagder | HCl: that's a mere quote from the web page basically |
| 11:56:55 | HCl | yea, look at the top.. |
| 11:57:06 | rasher | well it wouldn't be a problem |
| 11:57:12 | Bagder | but I agree with rasher |
| 11:57:14 | * | HCl goes to make coffee and do something about this darn lag |
| 11:57:18 | rasher | except some of the restrictions of rpsl are more restrictive than the gpl |
| 11:57:21 | Bagder | the click to accecpt is bad |
| 11:57:27 | rasher | which makes it incompatible |
| 11:57:41 | rasher | but the part he quoted isn't the problem |
| 11:57:47 | HCl | we can't relicense it as gpl |
| 11:57:51 | HCl | and as long as we don't modify it |
| 11:57:54 | | Quit ferenczy (Read error: 113 (No route to host)) |
| 11:57:57 | HCl | our code won't be under rpsl |
| 11:58:04 | HCl | as far as i understand |
| 11:58:05 | Bagder | we can't relicense it at all |
| 11:58:12 | HCl | indeed |
| 11:58:16 | Bagder | only the original author(s) can |
| 11:58:20 | rasher | The GPL restricts us from including it, not the rpsl |
| 11:58:29 | HCl | mk |
| 11:58:30 | Bagder | indeed |
| 11:58:39 | * | HCl doesn't understand most licensing stuff, will take your word for it :P |
| 11:58:41 | rasher | But it does so because of the rpsl :) |
| 11:58:44 | * | HCl goes to make coffee |
| 11:58:53 | HCl | oh, please read the updated runtimedatabase wiki topic |
| 11:58:56 | HCl | request for comments |
| 11:59:32 | HCl | haven't finished the flatfile description, not 100% sure how we're gonna want the tagdatabase yet, since we still want author/album tables |
| 12:00 |
| 12:00:05 | * | rasher hugs his usb->miniusb/charger thingy |
| 12:00:12 | Bagder | http://lists.helixcommunity.org/pipermail/open-licensing/2004-May/000278.html |
| 12:00:18 | rasher | I'll have a charged iRiver in the train on my way home ^_^ |
| 12:00:25 | Bagder | contradicts the license in my eyes |
| 12:00:49 | rasher | They can say that all they want |
| 12:00:52 | Bagder | yes |
| 12:00:56 | rasher | as long as the license says something else |
| 12:00:58 | Bagder | but the license still says so |
| 12:01:22 | rasher | The license also tries to give the impression of being gpl compatible.. quite deviously so |
| 12:01:49 | Bagder | yes |
| 12:01:56 | rasher | In the list of "compatible licenses" .. I have a feeling they created that section only to give that impression |
| 12:02:47 | rasher | interestingly, I couldn't find anything about it on debian-legal, last I looked |
| 12:02:56 | Bagder | "You may be prohibited under the terms of this otherwise compatible license" is a very odd way of putting things |
| 12:03:13 | rasher | Heh, quite |
| 12:03:17 | Bagder | "otherwise compatible" |
| 12:03:24 | rasher | "This license would be compatible, except it's not" |
| 12:03:28 | Bagder | yeps |
| 12:03:39 | Bagder | "but we list it here anyway with a footnote" |
| 12:04:07 | Bagder | "because we try hard to look better than we are" |
| 12:04:09 | Bagder | :-) |
| 12:04:47 | rasher | Something like that |
| 12:07:38 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 12:08:15 | rasher | hola, preglow |
| 12:08:46 | HCl | hmorning |
| 12:09:10 | HCl | m/me smacks lag. |
| 12:09:18 | | Nick tvelocity[away] is now known as tvelocity (~tony@ipa126.3.tellas.gr) |
| 12:09:20 | HCl | ugh. you get the point |
| 12:09:21 | HCl | anyways. |
| 12:09:34 | preglow | yo |
| 12:10:01 | HCl | how goes? |
| 12:10:07 | HCl | remote lcd is working |
| 12:11:09 | rasher | how working? |
| 12:11:26 | LinusN | we can draw stuff on it |
| 12:11:55 | rasher | \o/ |
| 12:12:09 | rasher | heh, gnu.org hasn't even bothered commenting on rpsl |
| 12:13:26 | | Join Zagor [0] (foobar@h14n2fls31o265.telia.com) |
| 12:13:40 | Bagder | howdy ho Zagor |
| 12:13:43 | Zagor | hi |
| 12:15:04 | LinusN | Zagor: back from the dead! |
| 12:15:17 | rasher | uh-oh.. prof's dimming the lights now.. |
| 12:15:22 | HCl | igh |
| 12:15:22 | rasher | I'll be fast asleep soon |
| 12:15:59 | HCl | how do i stop the wiki from auto enumerating? |
| 12:16:08 | Zagor | HCl: read the docs :) |
| 12:16:29 | Bagder | there are docs? B) |
| 12:16:42 | * | HCl sighs, is in the middle of an edit, was hoping someone could tell quickly :/ |
| 12:16:47 | HCl | but ok |
| 12:16:49 | LinusN | so you stop it by just reading the docs? wow! |
| 12:17:04 | Zagor | yeah, it's a very sensitive program |
| 12:17:32 | Zagor | HCl: of course, "rftm" just means "I don't remember" |
| 12:17:46 | HCl | ah P |
| 12:17:47 | HCl | :P |
| 12:17:58 | rasher | I usually find opening the "GoodStyle" link in a new tab works wonders |
| 12:18:05 | rasher | or whatever that link is |
| 12:20:28 | HCl | okay |
| 12:20:31 | HCl | verbatim thing worked |
| 12:20:39 | HCl | request for comments: http://www.rockbox.org/twiki/bin/view/Main/RuntimeDatabase |
| 12:26:51 | * | HCl really needs some comments before proceeding :x |
| 12:27:51 | Bagder | I think you need to add some thinking to it, and not only the db format |
| 12:27:57 | Bagder | I don't understand |
| 12:28:10 | HCl | okay, what don't you understand, sorry, i can be rather bad at documenting |
| 12:28:26 | HCl | i need questions to answer so i can add them to the wiki :x |
| 12:28:27 | Bagder | you start a single song, what happens? |
| 12:28:49 | Bagder | what does it load, what does it update |
| 12:29:06 | Bagder | when does it store to disk |
| 12:29:07 | HCl | the song gets looked up in the file database with a binary search, if it finds a record, it checks for tag data |
| 12:29:15 | | Join ferenczy [0] (~ferenczy@fw.qcm.cz) |
| 12:29:18 | HCl | if there is tag data, it displays it |
| 12:29:46 | Bagder | tag data? |
| 12:29:57 | HCl | not described yet, it would be in the tag database. |
| 12:30:06 | HCl | i'll go start a general description |
| 12:30:09 | HCl | on how its supposed to work |
| 12:30:41 | Zagor | i'm not sure I understand the purpose. you say it's for recording play frequency etc. then why do you need all those tags? |
| 12:31:05 | HCl | its to be able to create on the fly playlists by runtime and tag data |
| 12:31:23 | HCl | the tag data will be created by an indexer, like our current tagdatabase |
| 12:31:41 | HCl | it might write the song length to the tag database, if its not there. |
| 12:32:08 | * | HCl starts on an how its supposed to work section |
| 12:32:16 | Bagder | goodie |
| 12:32:18 | rasher | but all these things are static data |
| 12:32:28 | rasher | why not just extend the static db? |
| 12:32:33 | HCl | rasher: not the runtime data. |
| 12:32:43 | HCl | |Rating|1|Track Rating| |
| 12:32:43 | HCl | |Play Count|4|Play count of the track.| |
| 12:32:43 | HCl | |Last time played|4|Last time this track was played, probably in some relative format.| |
| 12:32:44 | rasher | but how much is runtime data? |
| 12:32:46 | HCl | |Volume adjustment|2|Volume adjustment, applied to track on playback| |
| 12:32:56 | HCl | the rest is gonna be a static db o.o |
| 12:33:09 | rasher | right... why a new static db? |
| 12:33:18 | HCl | aside from the filedatabase being related to the runtime data, and if runtime data is to be added for a file thats not in the filedatabase, it would have to be added |
| 12:33:22 | | Join Bipper [0] (~5198276f@labb.contactor.se) |
| 12:33:23 | Zagor | to avoid modifying the tag db runtime |
| 12:33:37 | Bagder | and to avoid having a tag db in the first place! |
| 12:33:45 | Zagor | ? |
| 12:33:50 | rasher | huh |
| 12:33:52 | HCl | um. mostly because the old format is completely incompatible with what i have so far o.o |
| 12:33:55 | Bagder | the runtimedb could work without tagdb |
| 12:34:03 | HCl | yes. |
| 12:34:05 | | Join webguest58 [0] (~c31ce021@labb.contactor.se) |
| 12:34:06 | rasher | I understand the need for the runtimedb |
| 12:34:08 | Zagor | Bagder: yeah, but the question is "why" |
| 12:34:18 | HCl | and because the runtime db and the tag db share data |
| 12:34:19 | Bagder | Zagor: for stats like most played and recently played etc |
| 12:34:22 | HCl | the filedatabase was created. |
| 12:34:23 | rasher | but "[12:33] <HCl> the rest is gonna be a static db o.o" |
| 12:34:29 | rasher | why a new one? |
| 12:34:45 | ashridah | cool. so what' |
| 12:34:47 | ashridah | s getting drawn on the lcd atm? |
| 12:34:49 | Bagder | one reason would be that the tagdb is very hard to update runtime |
| 12:34:53 | ashridah | (remote lcd i mean) |
| 12:34:54 | HCl | redesign, i guess. because the old tagdatabase can't store anything imho.. |
| 12:34:58 | Zagor | ah right,so we don't link tagdb with runtimedb |
| 12:35:02 | rasher | bagder: you wouldn't have to |
| 12:35:06 | HCl | we link tagdb with filedatabase |
| 12:35:11 | HCl | and we link runtimedb with filedatabase |
| 12:35:21 | rasher | but I'm talking about the static things hcl wants to store (like playtime) |
| 12:35:22 | HCl | and runtimedb and tagdb are only linked through the filedatabase |
| 12:35:22 | Bagder | rasher: what if we play a song that isn't in the tagdb |
| 12:35:45 | Zagor | HCl: THREE databases? we only have two datasets: tags and runtime info |
| 12:35:46 | Bagder | that has a longer name than any existing song... |
| 12:35:59 | HCl | Zagor: yes, three databases, as well as a flatfile, so 4 in total. |
| 12:36:01 | rasher | bagder: that's the need for the filename db |
| 12:36:06 | rasher | why 4?! |
| 12:36:08 | Zagor | why? |
| 12:36:11 | Bagder | 4? |
| 12:36:14 | HCl | the flatfile is for adding new records |
| 12:36:29 | HCl | and just temporarily till the data in it gets put in the proper position in the "static" db |
| 12:36:45 | HCl | the filedatabase is sorted to allow a fairly fast binary search. |
| 12:36:58 | Zagor | the tagdb is sorted already |
| 12:37:07 | | Join edx [0] (edx@pD9EAA858.dip.t-dialin.net) |
| 12:37:07 | | Quit Bipper (Client Quit) |
| 12:37:26 | * | HCl sighs and stares a bit, realizes why it needs to be documented to why its designed the way it is at the moment o.o |
| 12:37:27 | Bagder | I'm not quite seeing how we need three dbs |
| 12:37:33 | Zagor | :-) |
| 12:37:50 | rasher | HCl: write some more then :) |
| 12:37:52 | HCl | Bagder: because runtime db and tagdb share filenames, it would be a waste to store them twice, also, with 1 filename search, you'd get both tag and runtime db. |
| 12:38:02 | HCl | rasher: i'm working on it :P |
| 12:38:14 | HCl | i'm tempted to grab the irc logs and paste whats been explained so far and rewrite it a bit |
| 12:38:17 | Zagor | HCl: i think perhaps you may want to start from another angle: a) what do we want (function), b) what data does that require c) how do we store it |
| 12:38:28 | HCl | already have that. |
| 12:38:45 | Zagor | ok, then I just don't understand it :) |
| 12:38:49 | HCl | read the basic goal thing on the wiki.. |
| 12:38:58 | HCl | yea yea |
| 12:39:07 | HCl | i'll get on explaining it on the wiki, give me some time :) |
| 12:39:11 | Bagder | hehe |
| 12:39:12 | Zagor | sure |
| 12:39:17 | Bagder | please do |
| 12:39:49 | rasher | much easier to do it there probably |
| 12:40:01 | HCl | maybe. |
| 12:40:20 | rasher | easier to keep track of comments etc |
| 12:55:30 | HCl | i don't like wiki's font. but okay. |
| 12:55:39 | HCl | updated |
| 12:55:45 | HCl | please read the how its supposed to work section |
| 12:55:54 | HCl | and ask any questions you might have so i can add them |
| 12:57:53 | HCl | i'm not too good at documenting, but i tried :/ |
| 12:59:45 | | Join Lost-ash [0] (ashridah@220-253-123-84.VIC.netspace.net.au) |
| 12:59:45 | preglow | the wiki font? what font is that? |
| 12:59:51 | HCl | i have no idea. |
| 12:59:52 | HCl | but its small |
| 13:00 |
| 13:00:02 | HCl | and not too nice to read on my internet explorer |
| 13:00:16 | LinusN | it's not small here |
| 13:00:25 | HCl | probably just my ie.. |
| 13:00:29 | preglow | ie... |
| 13:00:32 | preglow | it's not small here either |
| 13:00:38 | HCl | request for comments |
| 13:00:39 | preglow | but the font is ugly, yes, but that's more the fault of ubuntu |
| 13:01:07 | rasher | Looks fine here |
| 13:01:18 | * | rasher has firefox set up to use the bitstream vera fonts |
| 13:01:20 | HCl | anyways, thats not the point! xD |
| 13:01:53 | preglow | proper unique identifier is a filename? |
| 13:01:56 | preglow | hell no |
| 13:02:01 | preglow | i've got lots of 01-Untitled.ogg |
| 13:02:07 | HCl | sorry |
| 13:02:11 | rasher | path |
| 13:02:12 | HCl | i'll change that to full path filename. |
| 13:02:17 | preglow | that's better |
| 13:03:04 | Zagor | the font is "sans-serif", which means your browser gets to choose which one to use. so blame your browser :-) |
| 13:03:24 | HCl | hit refresh |
| 13:03:29 | Zagor | yup, reading... |
| 13:04:02 | rasher | can't set which font ie uses for sans-serif >< |
| 13:04:29 | Lost-ash | HCl: yeah, uh.most browsers allow you to change what 'sans-serif' is rendered as :) |
| 13:04:41 | HCl | kay.. |
| 13:05:07 | Lost-ash | firefox is under edit->prefs->general->fonts & colours |
| 13:05:11 | | Quit ashridah (Nick collision from services.) |
| 13:05:17 | | Nick Lost-ash is now known as ashridah (ashridah@220-253-123-84.VIC.netspace.net.au) |
| 13:05:43 | ashridah | you could probably force an override using CSS too, if you're handy with html/css. |
| 13:06:09 | | Join DMJC [0] (~James@220-245-171-89.tpgi.com.au) |
| 13:06:17 | Zagor | HCl: call me dense, but I still don't understand the need for FileDatabase |
| 13:06:44 | Lynx_ | Zagor: how would you do it without? |
| 13:06:56 | HCl | Zagor: if we didn't have filedatabase, we'd have to store the filename twice, in the tagdatabase as well as the runtimedatabase |
| 13:07:16 | HCl | then, in order to look up metadata, we'd have to search for a filename twice, rather than once |
| 13:07:26 | Zagor | why? we already have the filename in the tagdb. use it instead of a new fildb |
| 13:07:33 | HCl | additionally, we'd have to do a filename search if we wanted tag data with the runtime data we have, and vice versa |
| 13:07:43 | Zagor | no |
| 13:07:54 | Lynx_ | Zagor: but then there could not be runtime data for a file with no tagdata? |
| 13:07:57 | HCl | we're adding a runtime database, it needs to be linked to the filename as well. |
| 13:07:57 | rasher | zagor: tagdb is not always expected to be up to date, or even present |
| 13:08:25 | Zagor | bah, why not? redundancy by complexity is not a rockbox design mark... |
| 13:08:48 | Zagor | it all needs offline indexing anyway, so why not require the tagdb? |
| 13:09:15 | HCl | it does not need offline indexing, a database sync could be done on the player |
| 13:09:39 | Zagor | "Because the FileDatabase? has to be sorted, we can't add to this database on the fly," |
| 13:09:49 | HCl | not without loading it entirely into ram. |
| 13:10:11 | HCl | which we can. but aren't gonna do unless you want to create a new playlist on the fly. |
| 13:10:34 | HCl | (and there is a flatfile) |
| 13:10:56 | Zagor | again, why this added complexity? |
| 13:11:18 | HCl | because it enables to have runtimedata without having tagdata. |
| 13:11:26 | Zagor | ...and the point of that is? |
| 13:11:29 | HCl | and keeps us from storing filenames twice. |
| 13:11:33 | HCl | that we don't have to have a tagdatabase. |
| 13:11:40 | * | HCl sighs. |
| 13:11:41 | Zagor | tagdb will always store filenames |
| 13:11:47 | HCl | no it won't.. heh.. |
| 13:12:08 | Zagor | otherwise tagdb is depending on filedb. and you didn't want to link them? |
| 13:12:16 | HCl | um. they are linked o.o; |
| 13:12:20 | rasher | I'm sortof with Zagor.. keep your songs in tagdb and keep it up to date, and you get all the benefits |
| 13:12:32 | rasher | which'll make it infinately simpler |
| 13:12:47 | HCl | i don't see how much extra "complexity" it would add |
| 13:12:56 | Zagor | we're not removing filenames from tagdb just to enable runtimdb to work without tagdb. that's nonsense imho, |
| 13:13:27 | rasher | for the while between adding a song and updating the tagdb, you just don't get runtime data for that file |
| 13:13:37 | HCl | so you're wanting to store filenames for runtime data as well as tag database? |
| 13:13:50 | HCl | rasher, i don't update the tagdb that often, and i often add files i come across. |
| 13:14:04 | HCl | say we have two databases |
| 13:14:06 | rasher | Why don't you? |
| 13:14:08 | HCl | tagdatabase and runtimedatabase |
| 13:14:14 | preglow | well, it shouldn't be that hard to have your unit sync on usb access? |
| 13:14:34 | HCl | both store filenames in order to keep track of what file's where. |
| 13:14:40 | rasher | and even so, the couple of times you play a file before updating tagdb, is it really that great a loss not to have that info stored? |
| 13:14:58 | HCl | yes o.o; |
| 13:15:03 | HCl | i don't understand whats against it, heh. |
| 13:15:04 | rasher | does it warrant the added complexity though? |
| 13:15:08 | HCl | yes? |
| 13:15:08 | HCl | o.o; |
| 13:15:13 | HCl | its really not that complex o.o |
| 13:15:22 | HCl | its just a very simple database o.o |
| 13:15:37 | HCl | never done sql? ;x |
| 13:15:42 | rasher | Sure |
| 13:15:52 | HCl | then surely you know about relational databases |
| 13:15:55 | HCl | which is exactly what this is o.o |
| 13:15:57 | rasher | But it seems slightly overkill |
| 13:16:05 | HCl | why? consider the alternative. |
| 13:16:10 | HCl | we have a tagdatabase |
| 13:16:10 | rasher | I did |
| 13:16:13 | HCl | with a filename |
| 13:16:19 | HCl | to keep track of tags with filenames |
| 13:16:26 | HCl | and we have a runtimedatabase |
| 13:16:28 | HCl | also with filenames |
| 13:16:34 | HCl | to keep track of runtimedata with filenames |
| 13:16:37 | Zagor | except you are not relating to existing data... :-) |
| 13:16:51 | HCl | say we want to create a playlist |
| 13:17:04 | rasher | why not just have runtimedb, which links to tagdb offsets |
| 13:17:04 | HCl | "all songs from the 80's played at least 5 times" |
| 13:17:25 | HCl | then we'd have to do a filename search |
| 13:17:28 | HCl | for *each* and *every* file |
| 13:17:35 | HCl | to link them against their runtime/tagdb counterpart |
| 13:17:44 | HCl | and then to be able to search on that data |
| 13:17:50 | rasher | well not each and every |
| 13:17:51 | LinusN | not if the search is done from the tag database |
| 13:18:00 | HCl | what do you mean linus? |
| 13:18:05 | rasher | anyway, why not have the runtimedb link into the tagdb? |
| 13:18:12 | Zagor | the tag database doesn't search filenames, it looks it up |
| 13:18:24 | HCl | because i can't stand raw file offsets o.o its ugly. |
| 13:18:34 | LinusN | the tag database know which songs are from the 80's |
| 13:18:37 | rasher | Now you're just whining |
| 13:18:47 | rasher | :) |
| 13:18:47 | preglow | yes, but not which are played at least five times |
| 13:18:56 | HCl | LinusN: ah, you mean doing the tag part first, and then the runtime part |
| 13:19:06 | LinusN | yes |
| 13:19:09 | HCl | then you would still need a filename search |
| 13:19:13 | HCl | for every file you found of the 80s |
| 13:19:15 | HCl | into the runtime db |
| 13:19:25 | * | rasher cries and cries |
| 13:19:27 | HCl | when with my proposal, you just check the file ID in the tagdatabase |
| 13:19:30 | LinusN | not if the runtime db is linked to the tagdb |
| 13:19:32 | HCl | look it up in the filedatabase |
| 13:19:37 | HCl | and then you have the runtime iD |
| 13:19:42 | HCl | which you look up in the runtime db |
| 13:19:56 | HCl | and then again, we can't have runtime info without a tagdb |
| 13:20:01 | HCl | if we were to do that. |
| 13:20:05 | LinusN | true |
| 13:20:08 | rasher | I don't get your irrational fear of file offsets |
| 13:20:15 | LinusN | me neither |
| 13:20:17 | HCl | and i don't get your irrational fear of databases :) |
| 13:20:23 | | Quit DMJC ("Leaving") |
| 13:20:31 | rasher | it's totally not irrational.. it's way over-complex |
| 13:20:32 | Zagor | file offset is the same thing as your "file id" |
| 13:20:37 | HCl | the runtime / tag / file ID's are really just an calculated offset |
| 13:21:09 | HCl | if you want you can just multiply them with the record size when you write them |
| 13:21:12 | HCl | then you'd have your offsets |
| 13:21:22 | LinusN | so why not just have them precalculated? |
| 13:21:30 | HCl | i guess we could |
| 13:21:37 | rasher | but that'd be file offsets! |
| 13:21:39 | LinusN | there we have the offsets |
| 13:21:41 | rasher | which is ... bad |
| 13:21:42 | Zagor | ...as the tagdb does |
| 13:21:51 | * | rasher grins |
| 13:21:56 | rasher | hcl is outnumbered |
| 13:21:59 | HCl | hm? |
| 13:22:01 | HCl | how so? |
| 13:22:07 | LinusN | however, we still have one "problem" |
| 13:22:16 | HCl | i just think a record number is cleaner than a direct offset |
| 13:22:24 | HCl | because they're easier to update, for one |
| 13:22:31 | HCl | i think, anyways o.o |
| 13:22:32 | preglow | not if they're the same thing, to a multiplied constant |
| 13:22:46 | rasher | well if the constant changes |
| 13:22:47 | HCl | preglow: yea, i guess you can calculate them back into record numbers. |
| 13:22:48 | LinusN | we will not be able to keep the runtime of a file if it is played from the dir browser |
| 13:23:01 | HCl | how so linus? |
| 13:23:06 | Zagor | LinusN: not without searching for it |
| 13:23:08 | rasher | but then, that'll happen when building the tag-db, in which case we have more than enough power to recalculate |
| 13:23:11 | LinusN | Zagor: right |
| 13:23:25 | HCl | yes, indeed we can't |
| 13:23:27 | HCl | but a binary search is fast. |
| 13:23:30 | LinusN | that's where the separate filedatabase comes in |
| 13:23:32 | HCl | log(N) |
| 13:23:36 | HCl | yup |
| 13:23:48 | Zagor | LinusN: why? the file database is just a copy of the first section of the tagdb |
| 13:23:55 | LinusN | Zagor: me silly |
| 13:24:08 | HCl | so what it comes down to |
| 13:24:17 | HCl | is that we're gonna add empty tagentries in the tagdatabase |
| 13:24:25 | HCl | when we want to add a runtime database for a file that doesn't exist. |
| 13:24:35 | LinusN | no, we won't add anything |
| 13:24:43 | rasher | that'd be costly |
| 13:24:45 | Zagor | no, we don't modify the tagdb runtime |
| 13:24:46 | HCl | then how will we do runtime data without a tagdatabase |
| 13:24:48 | LinusN | we will ignore the file until it is added by tagdb |
| 13:24:56 | | Join austriancoder [0] (~austrianc@80.120.117.30) |
| 13:24:59 | austriancoder | hi all |
| 13:25:08 | HCl | and the tagdb will be sorted then? |
| 13:25:13 | LinusN | it is sorted |
| 13:25:18 | Zagor | either that, or a crude log that the indexer can grab and integrate the next time it runs |
| 13:25:33 | rasher | I think that was the idea already |
| 13:25:34 | HCl | yea, thats what the flatfile was gonna be. |
| 13:25:35 | LinusN | austriancoder: hi |
| 13:25:44 | Zagor | ok. i'm fine with that. |
| 13:25:57 | rasher | that could even be parsed when performing searches |
| 13:26:02 | rasher | since it's likely to be quite short |
| 13:26:13 | HCl | then i wonder what the tagdb is gonna look like |
| 13:26:24 | HCl | since it needs to have *a lot* of fields added |
| 13:26:24 | Zagor | ? |
| 13:26:33 | * | austriancoder codes on setting menu for remote lcd |
| 13:26:36 | Zagor | yeah, all fields you want to search for |
| 13:26:38 | rasher | a lot? |
| 13:26:46 | HCl | check the tagdatabase section rasher. |
| 13:26:52 | HCl | i made a list of stuff. |
| 13:26:55 | Zagor | however I don't think we need to search for sample rate, disk number etc. |
| 13:27:00 | rasher | URL?! |
| 13:27:02 | HCl | gee, i even forgot genre |
| 13:27:09 | HCl | rasher: i just took a peek at id3v2 :P |
| 13:27:15 | HCl | we don't have to adopt all of them |
| 13:27:23 | rasher | I'd hope not |
| 13:27:24 | HCl | its just how much flexibility you want. |
| 13:27:28 | Zagor | yeah |
| 13:27:43 | rasher | total number of tracks? |
| 13:27:54 | rasher | "I want songs from cds with 13 tracks on them" seems a bit silly |
| 13:28:03 | HCl | yes, it can be very nice when having an entire cd album. |
| 13:28:10 | HCl | so you actually know on which track out of how many you are. |
| 13:28:19 | rasher | well I understand the tag |
| 13:28:23 | HCl | i mostly copied whats supported by various tags so far. |
| 13:28:24 | Zagor | HCl: we already know that, it doesn't need to be in the tagdb |
| 13:28:28 | rasher | but why would you want to search for it |
| 13:28:34 | preglow | HCl: pretty please, let genre be a string |
| 13:28:34 | HCl | i think we should be as flexible as possible |
| 13:28:53 | Zagor | i think we should start simple and expand as we feel necessary |
| 13:29:02 | LinusN | HCl: flexible in my world means "we can add it whenever we want" |
| 13:29:05 | HCl | are we currently reading displayed metadata from the file itself or the tag db? |
| 13:29:07 | HCl | i'm lagging, again |
| 13:29:09 | rasher | HCl: but total number of tracks is completely useless as a search term |
| 13:29:13 | Zagor | the file |
| 13:29:18 | HCl | LinusN: in my mind, it means, "it allows you to do nearly anything" |
| 13:29:29 | rasher | tagdb is only for browsing/searching |
| 13:29:34 | HCl | rasher: it depends, i'd want it to be possible to be displayed. |
| 13:29:49 | Zagor | tagdb has nothing to do with the display |
| 13:29:52 | LinusN | i mean, when you find that it will be useful to search for max tracks, then we add it to the db |
| 13:29:52 | HCl | but if we read most metadata from the song itself |
| 13:29:54 | HCl | then we can remove it |
| 13:30:04 | HCl | yea |
| 13:30:19 | HCl | if we read our display data from the tag of the file itself, then we can remove those. |
| 13:30:29 | LinusN | we reaqd *all* metadata from the track |
| 13:30:33 | HCl | its really just a list of possibilities |
| 13:31:10 | rasher | well if you wanted the tagdb browser to display songs as "title [#/#n]" I guess |
| 13:31:25 | HCl | mhm |
| 13:31:37 | Zagor | i'd say start coding for the current tagdb. there's plenty of work to be done before expanding it... |
| 13:31:49 | HCl | i would if i would understand its format? :P |
| 13:32:00 | Zagor | it's a relational db :-) |
| 13:32:05 | HCl | i noticed that. |
| 13:32:15 | HCl | i also barely saw any metadata whatsoever except relations ;/ |
| 13:32:30 | Zagor | hehe, there's only names currently |
| 13:32:33 | rasher | it only keeps artist, album title |
| 13:32:45 | rasher | sorts by tracknumber if possible though |
| 13:32:50 | HCl | i want at least year, genre, track |
| 13:32:57 | HCl | then comment, file type |
| 13:33:08 | Zagor | sure, we'll add that later. |
| 13:33:16 | HCl | but first |
| 13:33:22 | Zagor | but it's not the right end to begin |
| 13:33:25 | HCl | i'd like some explanation about how tagdb will work with runtime db |
| 13:34:33 | HCl | anyone? zagor? rasher? |
| 13:34:39 | Zagor | how do you mean? |
| 13:34:50 | HCl | how are they gonna work together by fileoffsets? |
| 13:35:20 | | Join MoosCamaro [0] (MoosCamaro@m214.net81-66-158.noos.fr) |
| 13:35:28 | MoosCamaro | hi all |
| 13:35:34 | Zagor | each record in runtimedb stores a pointer to a song record in tagdb |
| 13:35:40 | HCl | the tagdb can't have a link to the runtime db, so if we have a song |
| 13:35:45 | HCl | we'd have to search the entire runtime db? |
| 13:35:52 | rasher | nono |
| 13:36:01 | Zagor | we could have a lookup index at the start, sorted |
| 13:36:04 | rasher | we'd have to look it up in the first part of the tagdb |
| 13:36:12 | rasher | don't we? |
| 13:36:19 | *** | Saving seen data "./dancer.seen" |
| 13:36:22 | HCl | elaborate, heh. |
| 13:36:25 | Zagor | rasher: if we have filename, yes |
| 13:36:37 | rasher | What else would we have? |
| 13:36:40 | HCl | well, assuming we have a tagdb record. |
| 13:36:50 | HCl | and we just played the file and want its runtime record. |
| 13:37:01 | rasher | ah, like that |
| 13:37:28 | Zagor | there are several ways to handle it. one way would be to have a lookup table at the start of runtimedb, storing tagdb offset and corresponding runtimedb offset |
| 13:38:07 | HCl | that would be very alike the filedatabase, heh. |
| 13:38:14 | Zagor | we could also have the offset directly in tagdb, since it will never change runtime |
| 13:38:35 | rasher | ah, assuming a statically sized runtimedb? |
| 13:38:38 | rasher | silly me |
| 13:38:40 | Zagor | that makes a lot more sense |
| 13:38:47 | HCl | eh. |
| 13:38:48 | Zagor | rasher: yes |
| 13:38:57 | HCl | and just how would you want to update the runtimedb.. just add to it.? |
| 13:39:06 | HCl | you can't just overwrite it |
| 13:39:08 | HCl | like the tagdb |
| 13:39:13 | Zagor | why not? |
| 13:39:20 | HCl | because it would wipe all runtime data? O.o; |
| 13:39:36 | rasher | well you'd load it first.. remember this is done on your pc |
| 13:39:53 | Zagor | :-) well the db is read out, then created anew |
| 13:40:02 | HCl | heh... i'm not gonna be the guy who writes the pc tool.. i'll tell you that.. |
| 13:40:19 | Zagor | we already have a perl script to make the tagdb. this shouldn't be much different. |
| 13:40:42 | HCl | so. how would we get from tag to runtime data |
| 13:40:44 | Zagor | i'm happy if you are the guy who writes the search gui ;-) |
| 13:40:57 | rasher | that perl script is like the perl script of death |
| 13:40:59 | HCl | i think i can manage that, if at least the database is workable |
| 13:41:08 | austriancoder | setting remote contrast via config menu works :) |
| 13:41:10 | Zagor | i say we add a pointer in the tagdb to the runtime db. simplest solution. |
| 13:41:19 | HCl | so a static sized runtime db? |
| 13:41:25 | Zagor | rasher: wimp ;) |
| 13:41:26 | HCl | then you wouldn't even need a pointer |
| 13:41:36 | HCl | you could just have the same what i call record id |
| 13:41:46 | Zagor | same thing |
| 13:42:00 | HCl | well, no. cause you wouldn't have to store a pointer in the tagdb |
| 13:42:06 | HCl | but just calculate it |
| 13:42:09 | Zagor | using offset just saves a few multiplications |
| 13:42:20 | HCl | are we really that cpu needy? |
| 13:42:22 | Zagor | saving id or offset makes no difference |
| 13:42:24 | LinusN | austriancoder: great |
| 13:42:28 | rasher | Zagor: I tried modifying it... no matter what I changed in it, something else relied on that, creating horrible side-effects - it was great :) |
| 13:42:34 | HCl | well, i meant not saving the id either. |
| 13:42:44 | Zagor | oh. how do you mean then? |
| 13:42:46 | HCl | cause with static sizes, you can keep the id the same. |
| 13:42:56 | Zagor | the same as..? |
| 13:42:57 | HCl | say you have file number 2538 in the tagdb |
| 13:42:58 | austriancoder | LinusN: But the settings are keept.. if i restart it.. contrast is back to normal |
| 13:43:16 | Zagor | right, that's a good point |
| 13:43:16 | HCl | then you would look up the runtime record number 2538 in the runtimedb |
| 13:43:43 | HCl | i seriously don't want to be the person who codes the pc tool, heh. |
| 13:43:48 | Zagor | however it could get tricky when we add new files to it. but not undoable. |
| 13:43:55 | LinusN | austriancoder: you need to update settings_apply() |
| 13:43:56 | HCl | yea, thats what i'm saying |
| 13:43:57 | HCl | :P |
| 13:44:14 | austriancoder | ah.. ok.. and where must i call it? |
| 13:44:15 | Zagor | the real magic is detecting moved files :-) |
| 13:44:26 | LinusN | austriancoder: it is called when the settings are loaded |
| 13:44:32 | * | HCl shivers. |
| 13:44:38 | rasher | Zagor: md5 hash! |
| 13:44:39 | HCl | we'd have to have a flatfile for that. |
| 13:44:39 | LinusN | but you must add a call to lcd_remote_contrast() in it |
| 13:44:50 | Zagor | rasher: hah, yeah that'd speed things up... |
| 13:44:52 | HCl | or md5 :P |
| 13:44:58 | HCl | xD |
| 13:45:11 | HCl | i still vote for a filedatabase :/ |
| 13:45:13 | rasher | hash the first 10kb then :) |
| 13:45:17 | LinusN | austriancoder: settings.c |
| 13:45:18 | HCl | a moving file would be no harder than changing the filename in it |
| 13:45:20 | HCl | and resorting |
| 13:45:21 | HCl | done. |
| 13:45:37 | austriancoder | LinusN: will try it... thanks |
| 13:45:42 | rasher | you'd still need to detect that it's the same file |
| 13:45:49 | rasher | which is.. voodoo |
| 13:45:50 | Zagor | the difficult thing is finding out the new file is the same as an old one, not what to do once you know it. |
| 13:46:14 | HCl | well, thats a thing for the pc tool, really. |
| 13:46:17 | rasher | find the first mpeg-header, md5 the first 10 frames |
| 13:46:19 | HCl | the pc tool could md5sum the files. |
| 13:46:32 | HCl | and check md5sums when building a new db, would make indexing slow |
| 13:46:34 | rasher | nevermind non-mpeg files :) |
| 13:46:38 | Zagor | md5 is way too slow |
| 13:46:43 | HCl | crc? |
| 13:46:52 | Zagor | same thing, it requires reading the entire files |
| 13:47:02 | HCl | i guess. |
| 13:47:02 | rasher | why entire files? |
| 13:47:15 | ashridah | HCl: or you could just assume that the id3 tag hasn't changed, and update the index without rewriting the entire file. |
| 13:47:17 | HCl | because otherwise you can't determine whether they're the same. |
| 13:47:26 | ashridah | then tack new ones in as appropriate. |
| 13:47:29 | LinusN | i'd say a sum of the first kbyte would be adequate |
| 13:47:34 | HCl | what..? |
| 13:47:42 | rasher | first last kbyte perhaps |
| 13:47:49 | HCl | middle kbyte :P |
| 13:47:51 | LinusN | rasher: yes |
| 13:47:51 | rasher | first PLUS last |
| 13:48:01 | Zagor | if that's accurate, we could try it. we need to test it first though. |
| 13:48:05 | LinusN | the key is to sum the tag data |
| 13:48:17 | LinusN | which can be in the beginning and the end |
| 13:48:40 | Zagor | you assume the tag contains useful data. LOTS of songs on people's drives have empty tags. |
| 13:48:46 | austriancoder | LinusN: works now fine.. will add now other options and then i will commit everything |
| 13:48:55 | HCl | anyways. |
| 13:48:55 | LinusN | austriancoder: great |
| 13:49:01 | rasher | a kbyte would get more than the tag though |
| 13:49:04 | rasher | so it's fine |
| 13:49:24 | Zagor | rasher: we could try it |
| 13:49:28 | HCl | i'd appreciate it if either of you would be able to write a new runtimedb layout, i'm not 100% sure how to do it anymore with the new proposal, heh. |
| 13:49:54 | rasher | I could try doing it on my music collection (6000 files) and see how little I can hash before I get two identical hashes |
| 13:50:09 | Zagor | rasher: that would be great |
| 13:50:36 | HCl | or someone clearifying the current tagdb structure, i don't really get the wiki at all |
| 13:50:40 | Zagor | try with crc32 |
| 13:51:07 | rasher | faster/more likely to be different? |
| 13:51:11 | HCl | faster. |
| 13:51:11 | Zagor | smaller |
| 13:51:24 | LinusN | scooter |
| 13:51:27 | HCl | :P |
| 13:51:30 | rasher | hahaha |
| 13:51:33 | austriancoder | LinusN: should we add a HAVE_REMOTE_LCD_BITMAP ?? |
| 13:51:55 | LinusN | not until we have a remote with a character lcd |
| 13:52:03 | HCl | Zagor / rasher: can either of you clearify the binary format section a bit? maybe in the style that i did on runtimedatabase..? |
| 13:52:06 | austriancoder | ok.. |
| 13:52:06 | Zagor | HCl: the tagdb is split into five sections: header, files, songs, albums, artists |
| 13:52:33 | HCl | mhm, shouldn't the file table be sorted? |
| 13:52:38 | Zagor | it is |
| 13:52:43 | HCl | it says its unsorted on the wiki |
| 13:52:43 | HCl | :X |
| 13:52:48 | LinusN | aaah, the libmad stream interface is not my friend |
| 13:52:59 | Zagor | hmm, am I or the wiki wrong... :-) |
| 13:53:14 | * | Zagor checks the perl |
| 13:53:15 | LinusN | the wiki should be wrong...i think |
| 13:53:25 | Zagor | i think so too, just verifying |
| 13:53:31 | rasher | I think Zagor'd bettter explain this.. |
| 13:53:43 | rasher | plus I''m about to jump on a train home |
| 13:53:55 | HCl | i think i'll rewrite the binary format section a bit, any objections? i find it not very readable.. wanting to split it into 5 sections describing the binary format of all the structures |
| 13:54:19 | Zagor | HCl: go ahead |
| 13:55:00 | Zagor | the file table is sorted |
| 13:55:00 | HCl | k |
| 13:55:04 | HCl | i'll update that too. |
| 13:55:35 | Zagor | may I suggest you only add the new formatting, saving the old? just to be safe. |
| 13:56:00 | mico | does anybody have the gmini 400? |
| 13:56:17 | rasher | Loads of people do, I bet |
| 13:56:20 | * | rasher ducks |
| 13:56:24 | HCl | oh. ok. |
| 13:57:09 | mico | then why nobady tried to hack it ? :\ |
| 13:57:14 | mico | tries* |
| 13:57:33 | rasher | They're the wrong people I guess :) |
| 13:57:44 | mico | :\ |
| 13:58:10 | Zagor | the 400 has a TI chip, like the multimedias. TI == no docs == no fun. |
| 13:59:56 | rasher | Lecture over, bus and train leaving soon.. bye bye! |
| 14:00 |
| 14:01:02 | preglow | it uses a ti dsp? |
| 14:01:09 | | Quit rasher ("going home") |
| 14:01:17 | LinusN | yes |
| 14:01:32 | preglow | will not be easy to get a compiler either |
| 14:02:53 | austriancoder | if i added a new string to english.lang, who can i update all other langs? |
| 14:03:13 | HCl | the file table has an unfixed field length, correct? |
| 14:03:39 | LinusN | austriancoder: that is the job of the translators |
| 14:04:01 | LinusN | you only need to update english.lang for now |
| 14:04:22 | austriancoder | and german.lang :) |
| 14:04:29 | LinusN | HCl: correct |
| 14:04:42 | LinusN | (as far as i know) |
| 14:05:36 | preglow | any of you guys have any idea if we can implement an aac decoder with no legal troubles? |
| 14:05:44 | LinusN | not sure |
| 14:05:53 | preglow | or for that sake: an mp3 decoder |
| 14:06:05 | preglow | that again depends on whether it's iriver or the user who has the mp3 license |
| 14:06:33 | mico | does anybody have an idea for key combos for the gmini 400 to get into the fw debug functions screen? |
| 14:06:43 | LinusN | mico: i have no idea |
| 14:06:47 | preglow | i don't expect we'll see any trouble for having an mp3 decoder, but i'm not at all sure about aac |
| 14:06:51 | mico | :\ |
| 14:07:09 | LinusN | aac might be hot, yes |
| 14:07:25 | mico | it's not ON+F1+F2 as in the av300 |
| 14:07:27 | mico | :\ |
| 14:07:35 | preglow | i'm thinking about getting faad2 up and going |
| 14:09:22 | austriancoder | commited my changes to support some remote lcd settings |
| 14:09:33 | Zagor | there's no risk implementing it. the only risk is in distribution. and the laws on that are being decided as we speak. |
| 14:09:34 | LinusN | austriancoder: nice |
| 14:09:41 | austriancoder | next step is to include remote lcd calls into rockbox core |
| 14:10:33 | austriancoder | a nice logo on remote when starting would be a nice thing |
| 14:10:53 | Zagor | austriancoder: have you thought about solutions to the different screen size problem? (except the huge do-it-right solution) |
| 14:12:06 | ashridah | zagor: heh. let me guess. the 'do-it-right' solution is to rewrite all of the lcd drawing code so that it's size-independent so it can be called twice on an update, one targetting the main lcd, the other targetting the remote? :) |
| 14:12:26 | LinusN | ashridah: it's even worse than that |
| 14:12:32 | austriancoder | Zagor: no.. but time will solve this problem |
| 14:12:50 | ashridah | LinusN: well, yeah, i imagine you'd need to abstract out the hardware manipulation too |
| 14:12:56 | HCl | pheew. |
| 14:12:57 | HCl | okay |
| 14:13:02 | LinusN | the cursor position in the browser is also a problem |
| 14:13:04 | Zagor | ashridah: we also need to have dual variables for things like position in menus and file browser etc. |
| 14:13:10 | HCl | Zagor: take a peek at the tagdatabase wiki? |
| 14:13:11 | Zagor | it hurts just thinking about it... |
| 14:13:20 | HCl | at least i think that its at least somewhat more readable.. |
| 14:13:33 | bobTHC | :) |
| 14:13:38 | * | HCl actually partly understands the database now and knows what to add where :P |
| 14:14:42 | Zagor | does "#" mean "record" or "number" in that text? |
| 14:14:47 | HCl | number |
| 14:14:51 | austriancoder | will there alos be a wsp for the remote lcd? |
| 14:15:21 | ashridah | zagor: indeed. since you'd be inclined to reduce the amount of entries in a menu, instead of shrinking it, you need to build a bunch of menu/drawing type functions that automatically deal with it. joy :) |
| 14:15:49 | Zagor | austriancoder: yes |
| 14:16:19 | Zagor | in fact that may be the simplest solution at first: only show wps on the remote, not navigation and menus |
| 14:17:17 | austriancoder | so we will have 2 wsp's. one for normal lcd and one for remote lcd?! |
| 14:17:35 | Zagor | HCl: "Offset to song #" is a bit confusing, but not outright wrong :-) it's not really an offset to the song number, of course. |
| 14:17:39 | Zagor | austriancoder: yes |
| 14:18:26 | HCl | Zagor: i'm kind of referring to the number from earlier |
| 14:18:30 | austriancoder | Zagor: ok.. will look in source to see, what must be done |
| 14:18:37 | HCl | how would i be able to express it in a better way? |
| 14:19:02 | Zagor | i don't know. maybe "song x"? |
| 14:19:07 | HCl | lol, okay |
| 14:19:16 | HCl | # meant as much as X to me, but i'll change it :) |
| 14:19:25 | Zagor | not much better, but at least the meta-confusion is a little less i think |
| 14:19:56 | Zagor | HCl: replace "#" with the word "number" and you see the confusion i'm thinking of |
| 14:20:09 | HCl | yea, i guess.. |
| 14:20:19 | HCl | i'm just mostly worried that people will start seeing the X as something static |
| 14:20:38 | Zagor | yeah... did I say documentation is not my strongest skill? ;) |
| 14:20:42 | HCl | :P |
| 14:20:47 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 14:21:08 | HCl | i'll just remove the space before the # till we can think of something better |
| 14:23:02 | HCl | will we calculate the offset in the runtimedb or will we just add it in the song structure? |
| 14:24:23 | Zagor | i think we should use your idea, using the record tagdb number as rundb record number. thus not storing it anywhere. |
| 14:24:28 | HCl | ok. |
| 14:24:34 | HCl | calculate then |
| 14:24:38 | Zagor | right |
| 14:25:29 | * | HCl goes to do a little math to get the function to calculate an rundb offset from an tagdb offset |
| 14:26:47 | HCl | ((number-(song table offset))/(12+songnamelength))*sizeof(rundbrecord) |
| 14:27:01 | HCl | where number is the offset of the start of the current song, i think. |
| 14:27:09 | HCl | i suck at math ;p |
| 14:27:46 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 14:28:06 | Zagor | looks good |
| 14:28:17 | ashridah | okay. latest set of checkins broke the build here :) |
| 14:28:22 | HCl | would we still need a flatfile? |
| 14:28:24 | HCl | no, right? |
| 14:28:42 | Zagor | only for unindexed files |
| 14:28:44 | HCl | okay |
| 14:28:48 | austriancoder | how my last commit's doesn't break anything |
| 14:28:56 | Zagor | but I think we should start without that. start simple. |
| 14:29:37 | * | HCl nods |
| 14:29:40 | ashridah | austriancoder: got a bunch of implicit declarations in settings.c and a few undeclared's in setting_menu.c |
| 14:29:46 | ashridah | settings_menu.c even |
| 14:29:51 | LinusN | austriancoder: http://www.rockbox.org/showlog.cgi?date=2005-04-15%2012%3A09%3A02&type=iRiver%20H100%20-%20Normal |
| 14:30:18 | austriancoder | oha |
| 14:30:21 | austriancoder | will fix it |
| 14:31:08 | austriancoder | hmmm |
| 14:31:09 | austriancoder | #ifdef HAVE_REMOTE_LCD |
| 14:31:10 | austriancoder | static bool remote_contrast(void) |
| 14:33:04 | austriancoder | strange... for me it compiles and works |
| 14:33:42 | austriancoder | found mistake |
| 14:36:15 | austriancoder | fixed now |
| 14:39:56 | HCl | Zagor: check the RuntimeDatabase wiki |
| 14:40:47 | austriancoder | so.. with the current cvs you can set contrast of the remote lcd and you be able to invert the remote lcd |
| 14:41:08 | HCl | hmm. |
| 14:41:10 | ashridah | heh. well. the backlight on the remote turns on. |
| 14:41:15 | * | HCl suddenly remembers he was making coffee. 3 hours ago. |
| 14:41:46 | austriancoder | next step will be to expand the plugin api with some remote lcd functions |
| 14:44:48 | Zagor | HCl: just curious, why is volume adjustment 2 bytes? |
| 14:45:10 | | Join Querty_mob [0] (~Querty_mo@213.194.63.249) |
| 14:45:58 | HCl | well, partly silly, but different left and right adjustment :P |
| 14:46:03 | HCl | feel free to change it to 1 byte |
| 14:46:17 | Querty_mob | Hi all |
| 14:46:22 | austriancoder | hi |
| 14:46:25 | HCl | mmm, thunderstorms |
| 14:46:26 | HCl | hello |
| 14:46:33 | Zagor | also, when do we determine that? at the end of the track? |
| 14:47:14 | Querty_mob | w00t irc on my mobile :-) |
| 14:47:28 | HCl | Zagor: its a user-adjustable per-song setting |
| 14:47:58 | Zagor | HCl: right, but how does it work for the user? |
| 14:48:02 | HCl | say you have a song, and you find out its actually playing way too soft or too loud compared with the rest |
| 14:48:21 | HCl | during playback, you'd be able to change that modifier, and have it saved for when you play it again |
| 14:48:38 | | Quit lostlogic ("Going to the moon") |
| 14:48:39 | Zagor | a function in the menu somewhere? |
| 14:48:45 | HCl | probably |
| 14:48:47 | Zagor | ok |
| 14:48:49 | HCl | same with rating |
| 14:48:54 | Zagor | right |
| 14:50:21 | * | Zagor goes to paint a wall |
| 14:54:02 | | Join Shagnar [0] (~tester@p54A0D732.dip.t-dialin.net) |
| 14:56:32 | austriancoder | plugin api is uptodate |
| 14:59:21 | austriancoder | can somebody build a rockbox logo (132x65) ? |
| 15:00 |
| 15:00:09 | Shagnar | just something? ^^ |
| 15:02:52 | HCl | hehe :P |
| 15:03:01 | * | HCl has no copy of the rockbox logo.. |
| 15:03:33 | Shagnar | perhaps make a screen dumb? (dunno if that works?) |
| 15:04:12 | HCl | austriancoder: i think the archos version of the logo should fit. |
| 15:04:18 | HCl | the archos screen is 112x64 iirc |
| 15:08:05 | austriancoder | ah fine |
| 15:08:44 | austriancoder | could you tell me, where to loge is stored? |
| 15:10:12 | Shagnar | lol. just found when searching for "rockbox" on ebay: http://merchnow.com/store/graphics/00000013/rockbox.T.jpg |
| 15:10:53 | | Join redcow [0] (~redcow@host111-44.pool8250.interbusiness.it) |
| 15:10:59 | HCl | austriancoder: unfortunately, i have no clue :/ |
| 15:11:05 | HCl | *somewhere* in the code :/ |
| 15:11:17 | HCl | its there somewhere though |
| 15:12:10 | austriancoder | +g+ ok.. i will go for logo hunting |
| 15:13:00 | | Join rasher [0] (~3e4f4094@labb.contactor.se) |
| 15:13:03 | redcow | hi, have a question, i tried out a new bootloader with 1.65EU firmware did everything like always but now i get only a "white" screen at the boot and no more actions, if i reset the unit or press the record button/remote button it boots the original 1.65 iriver firmware, some known bug ? should i go back? |
| 15:14:36 | Shagnar | dunno this bug, but mod. 1.65 is not good at this point, on my H, some files couldn't be played anymore |
| 15:14:36 | | Quit webguest58 ("CGI:IRC (EOF)") |
| 15:14:51 | redcow | k than i go back |
| 15:15:15 | bobTHC | you can reflash with original firmware |
| 15:15:18 | Shagnar | 1.63 works fine |
| 15:15:45 | HCl | Shagnar: did your md5sum match the wiki? |
| 15:16:12 | redcow | i had 1.63 since the begining but wanted to have the newest firmware ;) |
| 15:16:24 | amiconn | austriancoder: firmware/drivers/lcd-recorder.c |
| 15:16:31 | amiconn | Ah, wrong |
| 15:16:32 | HCl | i heard ogg breaks when you try the bootloader with 1.65.. |
| 15:16:40 | Shagnar | öh yes, got it from someone of the river forum, extracted from a rar so i think this should have been ok. (many had this bug, see@h140thread) |
| 15:17:11 | HCl | well, you should still check md5sum |
| 15:17:28 | amiconn | austriancoder: apps/recorder/icons.c |
| 15:17:32 | Shagnar | i know.... but i don't have a tool for that yet... ^^ |
| 15:17:37 | Shagnar | http://www.misticriver.net/boards/showthread.php?t=12991&page=27&pp=20 <= there |
| 15:17:47 | austriancoder | amiconn: merci |
| 15:18:11 | LinusN | or even from the horse's mouth: http://www.rockbox.org/twiki/bin/view/Main/IriverBoot |
| 15:21:33 | redcow | argh with 1.63 firmware same error , wtf |
| 15:21:46 | preglow | ehh? |
| 15:21:47 | HCl | m? |
| 15:21:50 | | Quit bobdbob (Read error: 110 (Connection timed out)) |
| 15:22:14 | redcow | so it could only be a bad bootloader.bin |
| 15:22:24 | redcow | i build it from the todays cvs source |
| 15:22:30 | HCl | there's a working ihp_120.hex on my ftp that you can use.. |
| 15:22:39 | HCl | ftp://titania.student.utwente.nl/ |
| 15:22:43 | HCl | its on your own risk though. |
| 15:22:44 | preglow | i somewhat doubt the bootloader.bin is bad |
| 15:22:48 | preglow | it hasn't been changed in ages |
| 15:22:50 | HCl | i don't guarantee that it'll blow up in your face |
| 15:23:04 | HCl | preglow: actually, linus said that he changed the library calls that it used, and its safer to use the one on the wiki |
| 15:23:08 | HCl | (as far as i know) |
| 15:23:12 | redcow | at least i can revive my unit with a reset =) |
| 15:23:12 | HCl | *looks at LinusN* |
| 15:23:14 | Shagnar | redcow perhaps try ftp://titania.student.utwente.nl/ihp_120.hex |
| 15:23:38 | redcow | ye i do |
| 15:23:42 | Shagnar | no warranty ^^ |
| 15:23:50 | Shagnar | i used this one, and it works fine :) |
| 15:24:12 | HCl | its the one that i used to flash my h140 |
| 15:24:20 | bobTHC | it's alpha version be aware |
| 15:24:39 | HCl | anything i compile for my iriver has to pass through my ftp, so it automatically winds up there :P |
| 15:24:45 | LinusN | redcow: are you insane???????????????? |
| 15:24:56 | bobTHC | lol |
| 15:24:58 | Shagnar | huh? |
| 15:25:17 | redcow | why? |
| 15:25:26 | LinusN | From the iRiverBoot page: "Be careful! Do NOT attempt to build your own bootloader from CVS unless you know for sure what you're doing." |
| 15:25:41 | Shagnar | ;D |
| 15:25:53 | preglow | nice advice |
| 15:25:58 | HCl | xD |
| 15:26:06 | preglow | we change the code semi-daily and almost never verify if the bootloader still works |
| 15:26:13 | HCl | yup |
| 15:26:17 | LinusN | i wouldn't dare to try it myself |
| 15:26:26 | preglow | i haven't flashed my player in yonks |
| 15:26:30 | LinusN | except on my BDM-enabled player |
| 15:26:36 | redcow | uh |
| 15:26:40 | HCl | well, redcow did, i guess he's lucky you added the cookie thing :P |
| 15:26:47 | LinusN | :-) |
| 15:26:47 | HCl | since it seems to have saved his player |
| 15:26:57 | LinusN | good thing i added it then |
| 15:27:00 | HCl | yup |
| 15:27:01 | redcow | yeah the reset->boot original firmware saved my ass |
| 15:27:15 | * | LinusN updates the wiki page |
| 15:27:19 | HCl | redcow: use the .hex on my ftp, and next time, be more careful :P |
| 15:28:06 | redcow | well i saw a few 1.65 in the md5 reports list so i thought it works "normal" |
| 15:28:18 | HCl | using the bootloader on the wiki... |
| 15:28:26 | HCl | not built from cvs.. |
| 15:28:30 | redcow | ah |
| 15:28:59 | * | preglow prods bagder |
| 15:29:12 | austriancoder | rockbox logo on my remote lcd ;) |
| 15:29:44 | rasher | woo |
| 15:30:07 | austriancoder | will make a photo |
| 15:30:08 | redcow | thanks HCl rockbox is revived =) |
| 15:30:29 | LinusN | redcow: phew |
| 15:30:38 | bobTHC | :) |
| 15:30:53 | preglow | anyone know what windres is called on a mingw cross compiler? |
| 15:31:01 | rasher | Same thing I did.. except I did it when it was still working |
| 15:31:41 | preglow | or what do you use to compile win32 stuff on your daily build box? |
| 15:32:17 | rasher | Remember my file-hash experiment? Well I got duplicates |
| 15:32:26 | redcow | LinusN: your safety bootloader functions rocks =) |
| 15:32:29 | austriancoder | ohh.. my gentoo box cant handle my ir :( |
| 15:32:30 | rasher | But they were real duplicates as well, that I didn't know I had :) |
| 15:32:45 | * | rasher saves some space |
| 15:32:48 | preglow | rasher: what hash function do you use? |
| 15:33:00 | austriancoder | photo must wait.. will add logo start up of rockbox ;) |
| 15:33:03 | amiconn | Bagder: I saw that you did some channel stats. I wonder which rank I've 'achieved'... |
| 15:33:05 | rasher | md5 of the first and last kb |
| 15:33:17 | | Quit Querty_mob (Read error: 110 (Connection timed out)) |
| 15:33:25 | * | rasher remembers he was told to try crc |
| 15:33:45 | redcow | thanks, later |
| 15:33:46 | | Quit redcow ("quork!") |
| 15:34:24 | rasher | Close call :-\ |
| 15:34:38 | LinusN | :-) |
| 15:34:58 | * | LinusN removed the building instructions from IriverBoot |
| 15:35:09 | preglow | clever |
| 15:35:11 | preglow | but yes |
| 15:35:12 | rasher | Yeah, I was thinking about doing that a few days ago |
| 15:35:18 | preglow | i'm thinking about this build tool of mine |
| 15:35:38 | preglow | shall i just commit it with no makefile? 'cause i have no idea have to build win32 programs with cross compilers |
| 15:36:18 | rasher | It's too soon to release it... but if we wait much longer it just might end up being too late |
| 15:36:22 | *** | Saving seen data "./dancer.seen" |
| 15:36:32 | LinusN | preglow: it should be windres.exe |
| 15:36:32 | rasher | Damn curious users |
| 15:36:37 | preglow | i'm not talking about releasing it, i'm talking about silently putting it in cvs |
| 15:36:42 | | Join Querty_mob [0] (~Querty_mo@213.194.63.249) |
| 15:36:45 | rasher | Ah, alright :) |
| 15:36:53 | preglow | LinusN: eh? it's called windres.exe on unix boxes as well? |
| 15:37:19 | LinusN | the mingw cross compiler should have windres as well |
| 15:37:29 | preglow | i thought it had some kind of prefix |
| 15:37:35 | preglow | like the mingw gcc command will have |
| 15:38:37 | LinusN | i386-mingw32msvc-windres |
| 15:38:47 | preglow | excellent |
| 15:39:29 | preglow | what about the unicode filenames issue? should i just build two exes, one for win98 and one for nt/2k/xp ? |
| 15:40:09 | austriancoder | try all the new remotelcd plugin |
| 15:40:12 | LinusN | the what? |
| 15:40:22 | LinusN | (preglow) |
| 15:40:46 | austriancoder | button up ->bacllight off, button down -> backlight one.. and it looks so nice :) |
| 15:41:08 | LinusN | austriancoder: better look at firmware/backlight.c |
| 15:41:13 | preglow | LinusN: win98 and below only supports 8 bit filenames, nt and above supports unicode, the exe has to be compiled with different options for the two |
| 15:41:17 | austriancoder | if someone could make a photo of it?! |
| 15:41:35 | austriancoder | LinusN: its only for testing of the dirver.. i will change it later ;) |
| 15:41:39 | | Join Aison [0] (~hans@zux166-181.adsl.green.ch) |
| 15:41:39 | LinusN | preglow: why would you want unicode in the first place? |
| 15:41:51 | preglow | LinusN: so one can access directories with unicode names? |
| 15:42:01 | amiconn | preglow: Win95/98 also support unicode filenames. They just not support all of the unicode api function variants |
| 15:42:22 | LinusN | preglow: i get it, it's for the file requester? |
| 15:42:27 | preglow | LinusN: indeed |
| 15:42:32 | | Quit Querty_mob ("used WLIrc") |
| 15:42:41 | preglow | amiconn: i intermingle winapi and libc functions pretty much, it doesn't work as intended |
| 15:42:52 | LinusN | i'm not used to using gui tools for such simple tasks :-) |
| 15:43:25 | preglow | amiconn: if you use pure winapi file functions all the way, it should work fine even if it's not unicode aware, but i had to reuse a lot of code from mkboot.c and iriver.c |
| 15:43:31 | preglow | LinusN: i bet most people are :P |
| 15:43:38 | preglow | the intended audience, at least |
| 15:44:18 | LinusN | i'm afraid so :-) |
| 15:46:31 | austriancoder | LinusN: shouldn't there be 2 backlight threads? one for normal lcd and one for remote lcd?! |
| 15:46:47 | preglow | why can't the same thread work with both? |
| 15:46:59 | LinusN | austriancoder: should be enough with one thread imho |
| 15:47:08 | austriancoder | ok.. |
| 15:47:12 | austriancoder | will do it in one thread |
| 15:47:22 | LinusN | we want to keep the number of threads as low as possible |
| 15:47:23 | HCl | do we have a picture yet? |
| 15:47:24 | preglow | agreed, i think adding one thread for each light source is a bit wasteful |
| 15:48:21 | preglow | LinusN: does the build box have xp64 a xp64 capable gcc yet? :P |
| 15:48:31 | preglow | remove one "have xp64"... |
| 15:48:38 | Shagnar | hm, did you notice that the remote makes a very high sound? (not loud, but i can hear it good) |
| 15:48:40 | LinusN | no |
| 15:48:52 | LinusN | sound? |
| 15:48:59 | rasher | Shagnar: that's a defect in some remotes afaik |
| 15:49:07 | rasher | clicking |
| 15:49:12 | Shagnar | no clicking ;) |
| 15:49:17 | Shagnar | with the original FW thats not |
| 15:49:21 | rasher | when you use the buttons? |
| 15:49:22 | austriancoder | have somebody tried the new plugin? i am proud of it |
| 15:49:47 | Shagnar | it's a kind a "whistle"... very high frequency |
| 15:49:53 | * | HCl will checkout and try once he's back :) |
| 15:49:56 | HCl | nice work :) |
| 15:49:59 | rasher | austriancoder: very faint |
| 15:50:41 | austriancoder | backlight support will be commited in about 10 sec ;) |
| 15:50:52 | rasher | oh here we go |
| 15:51:32 | Shagnar | sorry for asking, but do you have a link for the newest build? just d/l but no changes within the remote ... :-| |
| 15:51:34 | rasher | the "default" remote contrast appears to be around 40 |
| 15:51:39 | rasher | possibly even 42 |
| 15:51:46 | austriancoder | could be |
| 15:51:51 | austriancoder | it should be 32 |
| 15:51:54 | rasher | now if only I had a camera |
| 15:51:54 | austriancoder | lets check it |
| 15:52:34 | austriancoder | it is set default to 32 |
| 15:52:56 | austriancoder | lets integrate the logo into rockbox starting screen ;) |
| 15:53:03 | rasher | yeah I meant that the level where it looks "natural" seems to be around 42 |
| 15:53:12 | austriancoder | ah |
| 15:53:18 | austriancoder | so i will change default to 42 |
| 15:54:37 | austriancoder | fixed |
| 15:54:40 | rasher | Where would a picture of this go? |
| 15:54:41 | preglow | but i'm out of here, alter |
| 15:54:43 | preglow | later <- |
| 15:54:51 | * | rasher alters preglow |
| 15:55:00 | preglow | it tickles! |
| 15:56:07 | austriancoder | where is the call to show the startup-logo? |
| 15:57:51 | rasher | http://www.rockbox.org/twiki/pub/Main/IriverPort/remote_lcd.jpg |
| 15:58:12 | austriancoder | thanks |
| 15:58:12 | Shagnar | :D |
| 15:58:16 | bobTHC | :)) |
| 16:00 |
| 16:01:05 | austriancoder | as i dont find where the startup logo is displayed, i will wirte some more lcd functions |
| 16:01:29 | rasher | austriancoder: And what, pray tell is your name? |
| 16:01:44 | rasher | (writing on misticriver and wanting to credit) |
| 16:01:58 | austriancoder | Christian Gmeiner |
| 16:02:12 | Bagder | austriancoder: apps/main_menu.c:show_logo() |
| 16:02:27 | LinusN | austriancoder: you cheated in backlight.c :-) |
| 16:02:45 | austriancoder | Bagder.. thanks |
| 16:02:59 | austriancoder | LinusN: it works.. ;) |
| 16:03:02 | ashridah | god. you people have gotten more done in the past few days than in a few months ;) |
| 16:03:14 | LinusN | the timers for the two backlights should be independent |
| 16:03:30 | * | Bagder agrees with LinusN |
| 16:03:42 | rasher | Didn't we agree on that already? |
| 16:03:42 | LinusN | that requires a change in button.c as well |
| 16:03:56 | rasher | or was that Rick perhaps.. |
| 16:04:00 | amiconn | ..and the remote backlight should probably only react on remote buttons |
| 16:04:13 | austriancoder | LinusN: could you do this change? |
| 16:04:16 | Bagder | rasher: we did but the commits done didn't do it |
| 16:04:18 | rasher | Or possibly a setting to make it react on both? |
| 16:04:22 | LinusN | austriancoder: sure |
| 16:04:30 | rasher | Bagder: Ah.. right |
| 16:04:47 | LinusN | amiconn: that's what the change in button.c is supposed to do |
| 16:05:24 | amiconn | Likewise the main backlight should only react on main unit buttons, correct? |
| 16:05:37 | LinusN | yes |
| 16:06:08 | rasher | Could there be two settings for this? Link remote light to main buttons and link main light to remote buttons yes/no ? |
| 16:06:10 | | Quit ashridah ("Leaving") |
| 16:06:28 | * | LinusN goes to debug a life support machine |
| 16:06:29 | rasher | Because I can imagine hitting the remote to get light in the main lcd.. but not the opposite |
| 16:06:36 | rasher | erp |
| 16:06:50 | rasher | better clear out *all* the bugs :) |
| 16:07:50 | austriancoder | rasher: sounds like a nice idea |
| 16:07:52 | * | Bagder runs away again |
| 16:08:09 | rasher | of course, that's in no way necessary |
| 16:08:12 | rasher | for now at least |
| 16:09:19 | elinenbe | remote is looking N-I-C-E! |
| 16:09:20 | elinenbe | :-) |
| 16:11:49 | bobTHC | it looking so nice that's look like a fake ;) |
| 16:12:06 | austriancoder | try it at your own.. its in cvs.. remotelcd plugin |
| 16:12:16 | bobTHC | i'm joking |
| 16:12:59 | HCl | :P |
| 16:13:02 | bobTHC | i'm sure is not a fake |
| 16:14:59 | rasher | By the way Linus.. the battery tests were run with LCD on.. so battery life is not as short as you might fear |
| 16:15:56 | * | HCl would start on the runtime database, but guesses he'll have to wait till we can actually play songs |
| 16:16:25 | Zagor | HCl: we can play songs, on archos players and simulators |
| 16:16:30 | HCl | true. |
| 16:17:34 | amiconn | austriancoder: pls fix those 'no newline at end of file' warnings |
| 16:18:12 | amiconn | I guess this is caused by apps/plugins/SOURCES |
| 16:18:19 | austriancoder | oh.. yeah will do it |
| 16:18:21 | austriancoder | sorryy |
| 16:19:00 | amiconn | Gcc is sometimes picky |
| 16:19:18 | * | HCl has never used an archos simulator... |
| 16:19:28 | austriancoder | i need the rockbox112x37 in main_menu.c, but i only have the bigger one |
| 16:19:39 | austriancoder | what should i do knoe? |
| 16:19:43 | austriancoder | now? |
| 16:20:03 | amiconn | Simply include it, depending on HAVE_REMOTE_LCD and the remote lcd sizes |
| 16:20:07 | HCl | does anyone know whether its possible to lseek past a file, write, and have the file being increased in size |
| 16:20:10 | HCl | ? |
| 16:20:24 | HCl | say you open an nonexisting file, lseek to a 2mb offset, write, would it become a 2mb file? |
| 16:20:42 | austriancoder | so i should make a new file for the logo? |
| 16:21:57 | austriancoder | the porblem is the icons.h |
| 16:22:05 | amiconn | Why? |
| 16:22:36 | amiconn | I'm a bit confused. Code says remote lcd is 132x65, devicechart says 134x65. Which one is correct? |
| 16:23:08 | austriancoder | there is the rockbox112x37 defined, but i dont know whats the best way to include the logo |
| 16:23:27 | austriancoder | hmm.. code seems to be wrong |
| 16:23:32 | | Join t0mas [0] (~Tomas@ip503c08d1.speed.planet.nl) |
| 16:23:59 | t0mas | hi |
| 16:24:04 | austriancoder | i will change it... |
| 16:24:05 | austriancoder | hi |
| 16:24:40 | t0mas | lot of CVS activity today? |
| 16:24:52 | austriancoder | jep |
| 16:24:56 | amiconn | rockbox112x37 is included conditionally: #if LCD_WIDTH == 112 || LCD_WIDTH == 128 |
| 16:25:02 | austriancoder | yeah |
| 16:25:12 | austriancoder | but iriver's my lcd is bigger |
| 16:25:26 | rasher | just copy the bitmap into the plugin then :) |
| 16:25:34 | amiconn | Just extend this to #if LCD_WIDTH == 112 || LCD_WIDTH == 128 || (HAVE_REMOTE_LCD && REMOTE_LCD_WIDTH == 132) |
| 16:25:57 | amiconn | ..in both icons.h and icons.c |
| 16:26:06 | amiconn | So on iriver, both versions get included |
| 16:26:16 | HCl | t0mas: remote lcd works |
| 16:26:19 | austriancoder | ah |
| 16:26:21 | austriancoder | ok |
| 16:26:26 | t0mas | yeah, just read it :) |
| 16:26:38 | HCl | *nods* |
| 16:26:59 | amiconn | Then you'll use rockbox112x37 for the remote lcd, and keep using rockbox160x53 for the main lcd |
| 16:28:04 | austriancoder | thats what i want |
| 16:28:15 | amiconn | Fortunately we chose different names for both. What a wise foresight... |
| 16:29:16 | austriancoder | recorder/icons.h:70:63: operator '&&' has no left operand |
| 16:29:33 | amiconn | Bleh |
| 16:29:46 | amiconn | #if LCD_WIDTH == 112 || LCD_WIDTH == 128 || (defined(HAVE_REMOTE_LCD) && REMOTE_LCD_WIDTH == 132) |
| 16:31:24 | austriancoder | main_menu.c: In function `show_logo': |
| 16:31:24 | austriancoder | main_menu.c:83: error: `rockbox112x37' undeclared (first use in this function) |
| 16:31:27 | austriancoder | :( |
| 16:32:32 | amiconn | Grr, that's because I cannot read correctly. It's LCD_REMOTE_WIDTH, not REMOTE_LCD_WIDTH |
| 16:32:41 | austriancoder | oh yes |
| 16:34:16 | austriancoder | works ;) |
| 16:34:23 | austriancoder | will do a new commit |
| 16:34:39 | t0mas | wow |
| 16:34:42 | t0mas | 20 mbit adsl |
| 16:34:50 | t0mas | 40 euro's / month |
| 16:34:53 | t0mas | :D |
| 16:35:07 | * | t0mas says goodbye to 4 mbit slow connection :P |
| 16:36:14 | amiconn | HCl: For the runtime database's 'recently played' feature, you don't need to store the passed time. Just count the songs which are played, and store the highest song number across reboots |
| 16:36:24 | austriancoder | i will make now a break |
| 16:36:37 | austriancoder | the last hours i got much of the remote lcd to work |
| 16:36:44 | LinusN | austriancoder: commit first |
| 16:36:53 | Shagnar | good work :) @ austriancoder |
| 16:36:58 | austriancoder | i have done it.. some seconds before |
| 16:37:04 | LinusN | great |
| 16:37:22 | austriancoder | now you only need to improve my work, because they could be some dirty hacks ;) |
| 16:37:35 | austriancoder | rockbox logo is now shown on startup |
| 16:37:54 | austriancoder | next thing will be wsp for the remote i think |
| 16:37:56 | austriancoder | or? |
| 16:39:01 | bobTHC | making the remote working as a joypad for 2 players games ;) [i'm kidding] |
| 16:39:13 | elinenbe | bobTHC: nice idea.. |
| 16:39:18 | elinenbe | for games like "battleship" |
| 16:39:23 | elinenbe | or chess :-) |
| 16:39:27 | bobTHC | yes! |
| 16:39:30 | austriancoder | yeah.. only need some work on the button driver |
| 16:39:36 | LinusN | austriancoder: can you write text? |
| 16:40:06 | austriancoder | at the moment not |
| 16:40:12 | LinusN | ok |
| 16:40:16 | austriancoder | i can only draw bitmaps |
| 16:40:24 | austriancoder | but this is not a hard work to code |
| 16:40:25 | LinusN | then text is not far away |
| 16:40:31 | austriancoder | yeah |
| 16:40:31 | LinusN | gotta go, cu guys |
| 16:40:38 | bobTHC | cu! |
| 16:40:42 | austriancoder | tonight... text on remote ;) |
| 16:40:46 | | Part LinusN |
| 16:40:47 | austriancoder | see you |
| 16:40:49 | amiconn | I should really start with my graphics api overhaul... |
| 16:40:50 | | Quit austriancoder ("using sirc version 2.211+KSIRC/1.3.11") |
| 16:50:29 | elinenbe | amiconn: go for it! |
| 16:50:53 | elinenbe | amiconn: I think everything needs grayscale and anti-aliasing capabilities... nice fonts... etc. |
| 16:54:36 | amiconn | It's mainly about improving/unifying the api. See #if LCD_WIDTH == 112 || LCD_WIDTH == 128 || (HAVE_REMOTE_LCD && REMOTE_LCD_WIDTH == 132) |
| 16:55:03 | amiconn | Bleh |
| 16:55:42 | amiconn | See http://www.rockbox.org/twiki/bin/view/Main/GraphicsAPI#Proposal_for_a_new_unified_and_e |
| 16:57:43 | amiconn | I also have some ideas for speedups, both for b&w (archos, iriver remote) and greyscale (iriver main lcd) |
| 16:58:03 | amiconn | Too bad I still didn't receive my iriver :( |
| 16:59:09 | Shagnar | which one did you order? |
| 17:00 |
| 17:00:00 | amiconn | H140 |
| 17:00:16 | Shagnar | :) |
| 17:00:52 | bobTHC | they have more room for hd replacement, it's a good choice ;) |
| 17:01:58 | bobTHC | u can already swap hd for a 60gig one |
| 17:02:40 | Shagnar | <= still waiting for the 80GB hdd :o) |
| 17:02:57 | amiconn | Shagnar: I already have an 80 GB mp3 player :) |
| 17:03:05 | Shagnar | h140?? |
| 17:03:10 | Shagnar | lol |
| 17:03:13 | Shagnar | archos |
| 17:03:15 | Shagnar | ? |
| 17:03:23 | amiconn | Yes, archos |
| 17:03:31 | * | HCl isn't gonna replace till he manages to fill 40gb... |
| 17:03:50 | HCl | half of my iriver's storage is used by disney movies at the moment |
| 17:04:00 | amiconn | 20 GB were too tight, so I had to decide whether to upgrade to 40 or 80 GB. |
| 17:04:02 | HCl | and i can still fit my entire music collection next to it |
| 17:04:24 | Shagnar | nice |
| 17:04:30 | amiconn | This was before the iriver port was even started |
| 17:05:06 | Shagnar | well... my music collection 's 80 GB ...^^ |
| 17:08:03 | HCl | can someone point me where to look if i needed the code that gets executed at the (near) end of a song? |
| 17:08:06 | Shagnar | but of course, i don't think its necessary to have the whole 80gb all the time with me... but, a bigger HDD is also nice e.g. for transfering movies/pictures in the holidays |
| 17:13:23 | | Join belgarath [0] (~accbb4e4@labb.contactor.se) |
| 17:14:20 | dwihno | Great work with the remote LCD! |
| 17:14:25 | dwihno | I salute thee! |
| 17:18:07 | HCl | rasher / Zagor: can you remind me why we split the tag and runtime db at all since they're rather intertwined at the moment anyways? |
| 17:19:19 | | Join Sucka [0] (~NNSCRIPT@host81-157-72-191.range81-157.btcentralplus.com) |
| 17:20:34 | HCl | also, why do we have an artist relation in the song structure when it can be deduced from the album? |
| 17:27:56 | Shagnar | perhaps because of albums with various artists ?! |
| 17:33:35 | | Quit belgarath ("CGI:IRC") |
| 17:33:39 | | Join belgarath [0] (~acc8b7d2@labb.contactor.se) |
| 17:36:26 | *** | Saving seen data "./dancer.seen" |
| 17:44:32 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 17:45:04 | LinusN | we split the runtime and tag db because we want the tag db to be static |
| 17:45:23 | amiconn | 36g *ee2er ; |
| 17:45:34 | amiconn | Erm, log peeker ;) |
| 17:45:40 | amiconn | Damn numlock |
| 17:46:03 | LinusN | there is a song->artist relation because we only want one relation table loaded in memory at a time |
| 17:46:52 | LinusN | dman, my recorder died... |
| 17:46:55 | LinusN | damn |
| 17:47:10 | LinusN | hard drive totally dead |
| 17:47:19 | LinusN | guess it's the power supply |
| 17:47:29 | LinusN | better heat up my soldering iron |
| 17:47:31 | | Part LinusN |
| 17:49:16 | | Join cYmen_ [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 17:49:30 | | Quit cYmen (Read error: 104 (Connection reset by peer)) |
| 18:00 |
| 18:03:39 | | Quit belgarath ("CGI:IRC (EOF)") |
| 18:06:14 | | Join Tulkar[] [0] (~hfdshd@log68-1-82-227-88-10.fbx.proxad.net) |
| 18:06:38 | Tulkar[] | Hi there ^^ |
| 18:07:12 | MoosCamaro | hi |
| 18:07:41 | Tulkar[] | is there any dev here ? ^^ |
| 18:07:49 | HCl | yea |
| 18:08:51 | Tulkar[] | k |
| 18:09:22 | | Quit tvelocity ("Leaving") |
| 18:09:24 | Tulkar[] | I just wanna know if it is possible to port the rockboy plugin to the AV300 series & how hard it is ^^ |
| 18:09:53 | HCl | do we even support the av300 series? |
| 18:10:07 | amiconn | nope |
| 18:10:08 | bobTHC | no :( |
| 18:10:53 | HCl | well, unless it comes close to 120mhz and has a suitable screen, i doubt it'll run anywhere near as nice as it runs on the iriver, and even that isn't at full speed yet |
| 18:10:53 | Tulkar[] | :/ |
| 18:11:32 | Tulkar[] | I think that the AV has got a 100mhz one whith a 320x240 screen |
| 18:11:39 | amiconn | I think the av units are more powerful the the sh1 based jukeboxes, because they play video |
| 18:11:45 | amiconn | *than the |
| 18:12:15 | Tulkar[] | yes they are ^^ |
| 18:12:24 | bobTHC | yes but rockboy works with coldfire and not on sh1 |
| 18:12:50 | bobTHC | or verrrrrrry badly with sh1 |
| 18:12:57 | bobTHC | i dunno |
| 18:12:57 | HCl | heh |
| 18:12:59 | HCl | 320x240 |
| 18:13:15 | HCl | if you manage to get the cpu, you might even be able to run gba on it. |
| 18:13:22 | HCl | but i doubt 100mhz is fast enough for that. |
| 18:14:19 | amiconn | bobTHC: Imho it's only a question of cpu clock. Of course a 11 MHz SH1 runs slower than a 120 MHz coldfire... |
| 18:14:39 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.umbc.edu) |
| 18:14:50 | bobTHC | totally agree, and of optimization too |
| 18:14:58 | amiconn | Tulkar[]: Anyway, making rockboy run on the AV units would require a rockbox port first. |
| 18:15:06 | bobTHC | indeed |
| 18:15:19 | Tulkar[] | the GBA has got an ARM processor so we "only" need to emulate the display function ^^ |
| 18:15:23 | amiconn | http://www.rockbox.org/twiki/bin/view/Main/NonArchos |
| 18:15:46 | amiconn | rockboy emulates gb/gbc, not gba |
| 18:16:03 | Tulkar[] | yes I know ^^ |
| 18:16:41 | Tulkar[] | but it should be possible to run a gb emulator |
| 18:17:39 | amiconn | Even if gba and emulator use the same cpu, emulation isn't as simple as just emulating i/o, at least as long as there is no mmu and a way to catch privileged instructions |
| 18:17:56 | HCl | definately. |
| 18:18:01 | Tulkar[] | of course ^^ |
| 18:18:08 | HCl | just look at the slowness of vmware on x86 |
| 18:18:17 | | Join Psy^DeadWeight [0] (nobby@host81-157-152-226.range81-157.btcentralplus.com) |
| 18:18:30 | Psy^DeadWeight | anyone here? |
| 18:18:33 | HCl | nope. |
| 18:18:35 | bobTHC | :) |
| 18:18:47 | Psy^DeadWeight | i have an extremely minor feature request :) |
| 18:18:52 | bobTHC | just 50 |
| 18:18:55 | HCl | shoot |
| 18:19:23 | | Join belgarath [0] (~acc8b7d2@labb.contactor.se) |
| 18:19:26 | Psy^DeadWeight | for the iriver remote, if any buttons are held down at startup (except the one that turns it on) make it disabled |
| 18:19:35 | Psy^DeadWeight | my remote has buggered up levers |
| 18:19:45 | amiconn | HCl: VMware on x86 isn't that slow, because it does exactly what I described. It only catches privileged instructions, and runs user space code 1:1 |
| 18:19:59 | HCl | mk |
| 18:20:47 | amiconn | I/O is relatively slow, but cpu intensive stuff runs at almost the same speed as it would on the host |
| 18:20:55 | Psy^DeadWeight | anyone interested in my request? can't be that hard to do... :) |
| 18:22:07 | | Quit belgarath (Client Quit) |
| 18:23:17 | HCl | eh, you'd have to add a check everywhere where we check remote buttons... |
| 18:24:59 | | Join DMJC [0] (~James@220-245-171-89.tpgi.com.au) |
| 18:26:40 | Psy^DeadWeight | :/ |
| 18:26:55 | Psy^DeadWeight | what about a play/pause/stop/volume only remote mode? |
| 18:27:11 | Psy^DeadWeight | with volume as an option on any lever? |
| 18:27:20 | Psy^DeadWeight | 2 of my levers are fsked IIRC |
| 18:27:27 | Psy^DeadWeight | maybe just the volume one... |
| 18:27:33 | Psy^DeadWeight | its annoying anyway |
| 18:28:03 | HCl | same thing, i guess. i guess you could change the button_status() function.. |
| 18:31:02 | amiconn | Psy^DeadWeight: There's a hardware limitation that makes it impossible to read more than one button at once. So if one button is stuck, there's no way to read the others. There are 2 exceptions to this rule iirc: (1) the ON button, (2) the HOLD switch |
| 18:31:18 | HCl | can anyone point me to the code that gets executed when you play a song / when you (almost) finish playing a song |
| 18:31:57 | | Nick Tulkar[] is now known as Tulkar[AFK] (~hfdshd@log68-1-82-227-88-10.fbx.proxad.net) |
| 18:32:18 | | Join Kafka [0] (~808be225@labb.contactor.se) |
| 18:32:53 | bobTHC | bye all! |
| 18:32:57 | | Part bobTHC |
| 18:33:35 | | Join Bippy [0] (~51982779@labb.contactor.se) |
| 18:33:48 | Bippy | Lots of CVS activity going on today |
| 18:34:01 | HCl | mhm. |
| 18:34:05 | HCl | remote lcd working.. |
| 18:34:19 | Bippy | How about MP3 or Radio :D |
| 18:34:23 | HCl | nope |
| 18:34:30 | Bippy | oh well, i can dream |
| 18:34:43 | HCl | i'm curious to radio as well, cause as far as i understand, it'll be possible to record from radio at least in hardware |
| 18:34:56 | Kafka | how bout bi-directional languages? |
| 18:35:09 | HCl | bi-directional languages? |
| 18:35:11 | Bippy | Just get radio before you start any fancy thingi mi bobs |
| 18:35:24 | Kafka | like hebrew and arabic |
| 18:35:30 | Bippy | Once it has radio ill never use iriver again |
| 18:35:31 | Kafka | that go from right to left |
| 18:35:34 | HCl | well, i'm wanting to take a look at on the fly playlist generation first... |
| 18:35:38 | HCl | ah.. |
| 18:35:40 | HCl | heh. |
| 18:35:46 | Bippy | OTF is already in there... |
| 18:36:28 | HCl | well, i admit i haven't looked at it, but i know the current tag database is no way in heck gonna support what i want. |
| 18:36:29 | Kafka | where i can i get coldfire's assembly? |
| 18:36:32 | Bippy | Would be nice if you could remove songs from the playlist, or whole directorys |
| 18:36:42 | HCl | Kafka: you mean instruction set description or what? |
| 18:36:54 | Shagnar | i think the biggest problem for gba on iriver is the resolution of the display?! |
| 18:36:59 | Kafka | aye |
| 18:37:06 | HCl | Shagnar: lol, consider cpu speed first. |
| 18:37:07 | Bippy | There also seem to be a bug with OTF if i add a DIR some times it adds it twice |
| 18:37:13 | HCl | considering that at 120 mhz |
| 18:37:21 | HCl | we can barely emulate a 4mhz machie |
| 18:37:24 | HCl | machine |
| 18:37:37 | Kafka | :X |
| 18:37:57 | Kafka | the lag on this java client... |
| 18:39:12 | amiconn | Bippy: You already can remove songs from a playlist |
| 18:41:40 | Shagnar | hmm kk, didn't think about that ;o) |
| 18:42:31 | | Quit Kafka ("CGI:IRC") |
| 18:44:09 | | Nick Lynx_ is now known as Lynx_awy (HydraIRC@134.95.189.59) |
| 18:46:39 | elinenbe | HCl: speed up that emulation! |
| 18:46:40 | elinenbe | :) |
| 18:46:49 | HCl | elinenbe: gonna look at runtime stats first |
| 18:47:09 | | Join Kafka [0] (~meh@209.8.233.243) |
| 18:51:00 | HCl | if i could find the spot where it actually plays mp3s |
| 18:51:02 | HCl | ;/ |
| 18:51:54 | Bippy | how amiconn |
| 18:55:27 | amiconn | Playlist Options->View Current Playlist. In the playlist viewer, long-press play (select on iriver) to get the context menu. It offers 'Remove', 'Move' and 'File Options' |
| 18:57:54 | amiconn | You can also edit a saved playlist. |
| 18:58:06 | | Part Psy^DeadWeight |
| 18:58:32 | amiconn | Long-press play (select on iriver) while on the .m3u, then select playlist->view. Proceed as above |
| 19:00 |
| 19:01:51 | Bippy | Ok nice one |
| 19:05:46 | | Quit Kafka (Read error: 131 (Connection reset by peer)) |
| 19:06:09 | Shagnar | HCl is the clock of the cpu really set higher if i choose that option in the dev. menu? |
| 19:11:41 | | Quit Bippy ("CGI:IRC (EOF)") |
| 19:19:38 | HCl | Shagnar: which option? |
| 19:21:37 | Shagnar | CPU clock - (0) 49'xxx'xxx or (1) 115'xxx |
| 19:21:48 | HCl | oh. yes, it gets set higher. |
| 19:21:57 | Shagnar | :) |
| 19:22:06 | HCl | i think you can notice it when decoding mp3 and stuff like that. |
| 19:22:13 | Shagnar | nice |
| 19:22:22 | Shagnar | but its not dangerous |
| 19:22:24 | Shagnar | ? |
| 19:22:26 | HCl | no. |
| 19:22:26 | Shagnar | for the cpu ? |
| 19:22:32 | HCl | rockboy runs at 120mhz |
| 19:22:36 | HCl | the cpu is still underclocked |
| 19:22:39 | HCl | the cpu is 140mhz max |
| 19:22:40 | Shagnar | fine ^^ but it doenst affect rockboy... ah ok ^^ |
| 19:22:49 | HCl | rockboy already runs at 120mhz |
| 19:22:57 | Shagnar | so its to save battery? |
| 19:24:13 | HCl | yes. |
| 19:24:17 | HCl | well |
| 19:24:18 | HCl | actually |
| 19:24:23 | HCl | 120mhz is the max we can run it at |
| 19:24:25 | HCl | without overheating |
| 19:24:32 | HCl | the iriver firmware doesn't go higher than 96mhz |
| 19:25:33 | t0mas | you reversed it? :) |
| 19:25:46 | HCl | what? |
| 19:26:03 | t0mas | iriver firmware |
| 19:26:08 | t0mas | to know that speed :) |
| 19:26:11 | Shagnar | hehe thats nice. btw, wave => ogg and stuff like that would be nice, too ;) |
| 19:26:34 | HCl | t0mas: oh, i think linus has. |
| 19:26:41 | t0mas | ah ok |
| 19:27:51 | Shagnar | reversed means? de-compilet? |
| 19:28:42 | t0mas | sort off |
| 19:28:51 | t0mas | but afaik not to normal C code... |
| 19:29:26 | Shagnar | well of curse not, i think thats impossible ^^ |
| 19:30:30 | t0mas | :) |
| 19:33:47 | | Join stevenm [0] (~steve@177-210.mam.umd.edu) |
| 19:34:03 | t0mas | LOL |
| 19:34:03 | t0mas | http://www.macminute.com/images/db/tiger2 |
| 19:34:20 | Shagnar | :D |
| 19:36:27 | *** | Saving seen data "./dancer.seen" |
| 19:36:41 | | Join belgarath [0] (~acc8b7d2@labb.contactor.se) |
| 19:38:24 | | Quit belgarath (Client Quit) |
| 19:43:13 | * | HCl grins. |
| 19:43:45 | Shagnar | lol |
| 19:43:58 | * | Shagnar laughs out loud...^^ |
| 19:50:57 | stevenm | Wow is that real ? |
| 19:53:57 | t0mas | the picture? |
| 19:54:06 | t0mas | not sure... think so... |
| 19:54:38 | stevenm | what exactly are they referring to ? |
| 19:56:07 | t0mas | Micro$oft always copying their new ideas? |
| 19:59:30 | | Nick Tulkar[AFK] is now known as Tulkar[] (~hfdshd@log68-1-82-227-88-10.fbx.proxad.net) |
| 20:00 |
| 20:02:20 | stevenm | Ah, makes sense |
| 20:02:39 | stevenm | What is the meaning of the hex numbers in viewers.config ? |
| 20:02:47 | stevenm | is that an icon or something ? |
| 20:03:02 | amiconn | yes, it's the icon |
| 20:03:07 | stevenm | amiconn, ah thanks |
| 20:03:50 | stevenm | amiconn, any tools on how to generate it, other than pen and paper? |
| 20:05:12 | amiconn | I did the .gb / .gbc icons with a pen-and-paper-like method, but the format is the same as the rockbox internal bitmaps |
| 20:05:57 | amiconn | So it should be possible to convert a 6x8 pixel, 1 bit .bmp with bmp2rb, then take just the 6 hex numbers |
| 20:10:50 | stevenm | viewers.cpnfig applies to /.rockbox/plugins right ? |
| 20:12:07 | stevenm | or is it somewhere else |
| 20:14:12 | stevenm | ah ok |
| 20:15:12 | amiconn | just /.rockbox |
| 20:16:07 | stevenm | ah, thanks |
| 20:16:17 | amiconn | Bagder: Your new cvsmod script seems to have a bug. Sometimes it displays the very same change for 2 subsequent compile runs. |
| 20:16:42 | amiconn | Compare http://www.rockbox.org/cvsmod/chlog-2005-04-15%2014:20:46.html and http://www.rockbox.org/cvsmod/chlog-2005-04-15%2014:35:32.html |
| 20:16:54 | amiconn | Both list the 'no newline fix' |
| 20:25:00 | | Join lolo-laptop [0] (~lostlogic@68.251.84.226) |
| 20:26:16 | elinenbe | HCl: if you run rockboy at 140mhz does it run 100% realitime? |
| 20:30:33 | preglow | nah |
| 20:37:10 | Shagnar | ^^ |
| 21:00 |
| 21:01:25 | | Join asdsd_ [0] (~asdsd@h-67-100-25-7.miatflad.dynamic.covad.net) |
| 21:03:00 | | Part asdsd_ |
| 21:10:11 | | Join Fer [0] (~Ferasprod@201-13-9-204.dsl.telesp.net.br) |
| 21:13:05 | | Part Fer |
| 21:14:18 | | Join belgarath [0] (~acd41a0e@labb.contactor.se) |
| 21:17:01 | | Quit belgarath (Client Quit) |
| 21:20:08 | | Quit stevenm (Read error: 110 (Connection timed out)) |
| 21:21:39 | HCl | elinenbe: you can't run at 140mhz cause the cpu crashes. |
| 21:24:07 | | Join stevenm [0] (~steve@181-26.mam.umd.edu) |
| 21:31:10 | stevenm | hello people |
| 21:31:38 | HCl | hey |
| 21:31:40 | HCl | hows midi |
| 21:31:40 | HCl | ? |
| 21:31:52 | MoosCamaro | hi |
| 21:32:10 | preglow | bah |
| 21:32:15 | stevenm | HCl, it's coming along. I got it working so that you can select a file and it will play |
| 21:32:18 | preglow | did you ever make that mod2wav, hcl? |
| 21:32:50 | stevenm | Now moving the configs to a better place and adding some error checks |
| 21:35:55 | HCl | preglow: no, i got a bit stumped by floats in the dumbout.c |
| 21:36:06 | Rick | hey guys |
| 21:36:07 | preglow | really? |
| 21:36:13 | Rick | I see AC worked on the remote a lot |
| 21:36:14 | HCl | yes. |
| 21:36:29 | preglow | have you checked if m68k-gcc makes code for floats? |
| 21:36:30 | *** | Saving seen data "./dancer.seen" |
| 21:36:44 | HCl | no. but it probably does, otherwise it probably wouldn't have compiled |
| 21:37:05 | HCl | (the library) |
| 21:37:26 | preglow | don't be sure, it might be using fpu instructions |
| 21:37:43 | preglow | but indeed, why are you stumped about these floats? |
| 21:38:07 | HCl | cause i need to convert them to integers before it'll work? |
| 21:38:10 | HCl | at least, thats what i assumed |
| 21:38:10 | preglow | no? |
| 21:38:16 | HCl | mk. |
| 21:38:20 | preglow | if a routine takes a float, then it takes a float |
| 21:38:29 | preglow | don't care if it actually uses a fpu to do the calculations |
| 21:38:39 | preglow | after i've massaged it into submission, then it'll take ints |
| 21:38:44 | HCl | mk |
| 21:38:46 | HCl | well |
| 21:39:00 | HCl | in that case, we're mostly missing some floor() pow() and log() functions, i thik |
| 21:39:04 | HCl | think |
| 21:39:18 | preglow | well, that's true |
| 21:39:33 | preglow | but the math lib gcc uses might have those |
| 21:39:37 | stevenm | Hey guys.. is there any way to bail out of a plugin other than returning -1 to the very first function ? |
| 21:39:39 | preglow | but you'll need to specify -lm |
| 21:40:04 | HCl | mk |
| 21:40:12 | HCl | i have to go in 10 min anyways. |
| 21:40:19 | Rick | stevenm: properly design your plugin to handle errors from functions |
| 21:45:01 | stevenm | Rick, yea, I'm trying to make everything return -1 on error, etc.. just wondering if there's a better way |
| 21:47:18 | preglow | HCl: gcc does indeed emulate them |
| 21:47:28 | HCl | mk |
| 21:47:55 | preglow | so everything should work fine and dandy, just slow as hell |
| 21:51:16 | Rick | hmm |
| 21:51:19 | Rick | cvs lcd.h is broken |
| 21:51:48 | Rick | oh |
| 21:51:49 | Rick | nevermind |
| 21:59:53 | Rick | hehe |
| 21:59:54 | Rick | nice logo |
| 22:00 |
| 22:07:48 | stevenm | does anyone mind if I commit viewers.config? |
| 22:08:12 | stevenm | and some midi code too |
| 22:11:26 | preglow | commit away |
| 22:11:37 | stevenm | excellent |
| 22:11:37 | preglow | as long as it doesn't break anything, just toss it in |
| 22:12:10 | stevenm | preglow, just to make sure.. I checked out the latest rockbox-devel this morning.. It will only comit the files I changed, right ? |
| 22:12:22 | preglow | well, check the list |
| 22:12:32 | preglow | it should give you a list when you commit |
| 22:12:33 | stevenm | hmmm ? |
| 22:12:39 | preglow | over files that are about to be commited |
| 22:12:47 | preglow | have you tested it on the target yet, btw? |
| 22:13:01 | stevenm | preglow, yea. rasher was running it last night |
| 22:13:32 | | Quit thegeek (Read error: 131 (Connection reset by peer)) |
| 22:13:33 | preglow | it produced sound? |
| 22:13:34 | stevenm | we got the memory allocation thing fisxed.. it started working on the target, writing to HD, etc. then it ran out of battery |
| 22:13:40 | preglow | haha |
| 22:13:58 | stevenm | preglow, it was supposed to write to a .raw file (haven't done the xxx2wav thing yet, getting build errors) |
| 22:14:15 | stevenm | it was writing to SOMETHING but then rasher had to go before he could let it finish and check it |
| 22:14:23 | stevenm | preglow, you feel like testing it ? |
| 22:15:47 | preglow | not now |
| 22:15:57 | stevenm | ah ok |
| 22:16:07 | preglow | doing some other coding that urgently needs doing |
| 22:16:17 | stevenm | with the cvs command, is there a way to see what it is going to commit before it actually does it? |
| 22:16:29 | stevenm | When Linus showed me, it just did it all in one go |
| 22:17:23 | preglow | whenever i do a 'cvs commit', i'm asked to write a log message |
| 22:17:27 | preglow | in that message, there is a list of files |
| 22:17:46 | preglow | if you want to know the actual changes, do a 'cvs diff' |
| 22:18:28 | stevenm | oh ok |
| 22:19:47 | | Join asdsd__ [0] (~asdsd@h-67-100-25-7.miatflad.dynamic.covad.net) |
| 22:19:48 | | Join El_Gringo [0] (~chatzilla@bzq-165-126.dsl.bezeqint.net) |
| 22:20:02 | | Quit El_Gringo (Client Quit) |
| 22:21:59 | | Join El_Gringo [0] (~chatzilla@bzq-165-126.dsl.bezeqint.net) |
| 22:22:05 | El_Gringo | Hello everybody |
| 22:22:59 | | Join thegeek [0] (~thegeek@ti521110a080-1991.bb.online.no) |
| 22:24:36 | stevenm | hello |
| 22:25:52 | MoosCamaro | hi |
| 22:26:10 | | Join xen` [0] (~xen@ADijon-153-1-22-121.w83-203.abo.wanadoo.fr) |
| 22:28:16 | t0mas | HM.. |
| 22:28:22 | t0mas | little makefile question... |
| 22:28:24 | t0mas | irctest : main.cpp irc.o ircclass.h |
| 22:28:24 | t0mas | ${CC} -o irctest main.cpp irc.o ${LIBS} |
| 22:28:24 | t0mas | irc.o : ircclass.cpp ircclass.h socket.o socket.h |
| 22:28:24 | DBUG | Enqueued KICK t0mas |
| 22:28:24 | t0mas | ${CC} -c -o irc.0 ircclass.cpp ${LIBS} |
| 22:28:50 | t0mas | is that ircclass.h needed in the first target line? |
| 22:29:06 | t0mas | or is it ok to leave that out, because it's on the second line? |
| 22:31:37 | | Quit El_Gringo ("Chatzilla 0.9.67 [Firefox 1.0.2/20050318]") |
| 22:37:22 | | Quit xen` (Read error: 60 (Operation timed out)) |
| 22:47:03 | preglow | well, yes, irctest depends on irc.o, and irc.o depends on ircclass.h |
| 22:47:08 | preglow | so it doesn't matter |
| 22:56:31 | HCl | hello |
| 22:58:04 | Bagder | red build I see |
| 22:58:22 | Bagder | naughty |
| 22:59:39 | HCl | Bagder: i think the recent cvs activity broke. |
| 22:59:50 | Bagder | yeps |
| 23:00 |
| 23:00:03 | Bagder | midi/guspat.c:100: undefined reference to `snprintf' |
| 23:00:51 | HCl | it broke because we have a red one? |
| 23:01:05 | HCl | thats not very practical, then you can't see what broke it :/ |
| 23:01:07 | Bagder | oh, how do you mean broke? |
| 23:01:19 | HCl | check the main page.. |
| 23:01:24 | Bagder | yes? |
| 23:01:28 | HCl | Recent CVS activity |
| 23:01:28 | HCl | cvs2html.pl [-s style] [-h html] [-n numberoftablelines] |
| 23:01:28 | HCl | −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− |
| 23:01:32 | HCl | Page was last modified "Feb 16 2005" The Rockbox Crew |
| 23:01:34 | Bagder | ah |
| 23:01:36 | Bagder | reload |
| 23:01:41 | HCl | i have. |
| 23:01:47 | HCl | its not changing |
| 23:01:52 | Bagder | no, I meant I realoded now |
| 23:01:58 | HCl | ah. |
| 23:01:59 | HCl | okay |
| 23:02:55 | Bagder | I'm fiddling with the script atm |
| 23:06:09 | Bagder | there |
| 23:06:33 | preglow | stevenm: you really need to test build for the device before you commit |
| 23:07:18 | Bagder | and you need to check the source formatting we use |
| 23:10:12 | Bagder | guspat.c is just plain... wrong |
| 23:10:30 | HCl | hm |
| 23:10:39 | HCl | maybe its an idea to automatically run astyle over committed source? |
| 23:10:54 | Bagder | nah |
| 23:10:58 | HCl | why not? |
| 23:11:05 | Bagder | it kills good versioning of the source |
| 23:11:20 | HCl | hmm... i'm not 100% sure, but you might be right. |
| 23:11:23 | HCl | it would the first time |
| 23:11:27 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 23:11:27 | * | rasher just slept for 7 hours |
| 23:11:29 | HCl | but after that, it might work? |
| 23:11:31 | HCl | i dunno |
| 23:11:36 | rasher | now that'll work wonder for my sleeping patterns |
| 23:12:07 | Bagder | HCl: doing things on files on commit just usually strikes back in your face |
| 23:12:15 | Bagder | sooner or later |
| 23:12:16 | HCl | maybe |
| 23:12:19 | preglow | ugh, no |
| 23:12:23 | HCl | astyle is pretty safe for me so far |
| 23:12:24 | preglow | no automatic formating, please |
| 23:12:28 | Bagder | it would be better to reject the commit |
| 23:12:31 | HCl | what about.. |
| 23:12:37 | HCl | adding an astyle command on the wiki |
| 23:12:40 | HCl | to format it correctly |
| 23:12:45 | HCl | that people can use personally |
| 23:12:47 | HCl | when they commit new files |
| 23:12:48 | HCl | ? |
| 23:12:49 | preglow | better |
| 23:12:49 | Bagder | that would be useful |
| 23:13:07 | preglow | but please no forcing, as long as it's sane, i think it should be allowed |
| 23:16:18 | rasher | How tragic.. red build :( |
| 23:17:23 | * | Bagder steps forward |
| 23:17:33 | * | Bagder steps back again |
| 23:20:27 | HCl | o.o; |
| 23:20:47 | preglow | almost ninja-like, this is |
| 23:22:40 | preglow | beer time |
| 23:33:26 | amiconn | Ah, good |
| 23:33:37 | | Quit Harpy (Read error: 60 (Operation timed out)) |
| 23:33:58 | * | amiconn just checked whether the windows installer installs rockboy.ovl for the archos recorders. It does :) |
| 23:34:18 | amiconn | Should have done this waaay earlier though... |
| 23:34:44 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 23:35:55 | Bagder | evening LinusN |
| 23:36:18 | LinusN | evening |
| 23:36:31 | *** | Saving seen data "./dancer.seen" |
| 23:40:30 | | Join Strath [0] (~mike@dgvlwinas01pool0-a221.wi.tds.net) |
| 23:41:19 | t0mas | hi |
| 23:45:58 | LinusN | hi |
| 23:46:13 | thegeek | http://www.misticriver.net/boards/showthread.php?t=18271 |
| 23:46:16 | thegeek | seen? |
| 23:46:19 | * | LinusN sees a really nasty problem with ata_sleep() |
| 23:46:28 | thegeek | ogg problems with 1.65+rbx |
| 23:46:43 | Bagder | thegeek: its mentioned on the iriverboot wiki page |
| 23:46:46 | | Quit lolo-laptop ("Client exiting") |
| 23:46:52 | thegeek | oh;) |
| 23:46:53 | thegeek | hehe |
| 23:46:55 | thegeek | oh well |
| 23:49:09 | preglow | LinusN: really nasty? |
| 23:49:41 | LinusN | if the hard drive goes to sleep at the same time the dma playback starts, the cpu core freezes |
| 23:49:49 | thegeek | :) |
| 23:49:50 | thegeek | yay |
| 23:50:16 | preglow | haha |
| 23:50:18 | preglow | that qualifies |
| 23:50:57 | LinusN | there is a bug in ata_sleep() but i didn't think it would manifest itself like this |
| 23:51:16 | LinusN | preglow: you can try it yourself |
| 23:51:30 | LinusN | set the disk spindown to 3s |
| 23:51:50 | LinusN | then run the audio playback test on a long (>8mb) file |
| 23:51:55 | LinusN | in 48MHz |
| 23:52:22 | LinusN | make sure you have a reset pin |
| 23:52:25 | preglow | well, that does explain why i've had it lock up several times |
| 23:54:02 | LinusN | i just wish i knew what happens |
| 23:54:34 | | Quit StrathAFK (Read error: 110 (Connection timed out)) |
| 23:55:45 | preglow | what's with the drive going to sleep that conflicts with dma? |
| 23:55:55 | preglow | i can't think of anything obvious |
| 23:57:26 | LinusN | me neither |
| 23:57:46 | LinusN | except that the ata bus is tri-stated |
| 23:58:20 | preglow | well, i can't see why that should matter either |
| 23:58:28 | LinusN | nope |
icon identifies that the person is a core developer (has commit access).