| 00:17:18 | | Part scott666_ |
| 00:17:24 | | Quit _aLF ("Leaving") |
| 00:20:06 | | Join Lurkski [0] (~Miranda@24.30.163.142) |
| 00:22:41 | | Part Lurkski |
| 00:58:30 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:03:51 | [IDC]Dragon | my Ondio tuner works! |
| 01:04:03 | midk | woo! :) |
| 01:04:13 | midk | great work.. sounds like it's progressing quite well |
| 01:04:22 | | Quit AciD (Remote closed the connection) |
| 01:04:29 | midk | curious, what haven't you got to work yet? |
| 01:04:49 | [IDC]Dragon | we got it pretty much complete now |
| 01:05:44 | [IDC]Dragon | the keyboard screen is missing, tuner presets found no button |
| 01:09:12 | midk | great |
| 01:24:40 | [IDC]Dragon | 'night! |
| 01:24:45 | | Quit [IDC]Dragon () |
| 01:54:44 | | Join Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 01:57:06 | midk | hey bc |
| 01:57:11 | Bluechip | hey mk |
| 01:57:32 | midk | anything in the works lately? |
| 01:57:47 | Bluechip | been writing a book |
| 01:58:14 | midk | on what? |
| 01:58:22 | Bluechip | linguistics |
| 01:58:40 | Bluechip | primarily neuro linguisitc programming |
| 01:58:52 | midk | neuro what? :) |
| 01:58:58 | Bluechip | but variations and adaptations based on it |
| 01:59:02 | Bluechip | lol ;) |
| 01:59:47 | midk | do you plan to publish it or anything? |
| 01:59:57 | Bluechip | probably, yes |
| 02:00 |
| 02:00:11 | midk | awesome |
| 02:00:35 | Bluechip | ty |
| 02:01:22 | midk | appropriate("Good luck!")?say():shutUp(); |
| 02:01:32 | Bluechip | lol |
| 02:01:37 | Bluechip | he has mastered the ? |
| 02:01:58 | midk | not really sure if it would work or not.. last time i tried something like that i got an error |
| 02:02:12 | midk | i stuck to switch(case) or if(x) |
| 02:02:14 | midk | :) |
| 02:02:39 | Bluechip | often fixed by adding paren's everywhere |
| 02:02:48 | Bluechip | ()?():(); |
| 02:03:46 | midk | good idea |
| 02:04:54 | Bluechip | especially if you have them nested, when it becomes almost essential ...not sure why - poor compilation imho - but then I may be lacking the vital piece of information that makes everything clear |
| 02:05:57 | midk | i never liked that style much anyhow.. i prefer something a little more readable like if-else |
| 02:06:14 | Bluechip | they are good when used sensibly, i think |
| 02:06:33 | midk | if there's more than 3 or so if/else statements i use a switch |
| 02:07:17 | Bluechip | theory has it that the compiler should do that anyway |
| 02:07:38 | Bluechip | you should make two compiles, one with, one without, and see if there is any filesize difference on the .rock |
| 02:07:55 | midk | simpler to read is all |
| 02:08:13 | midk | most of my programming now takes place at linav |
| 02:08:55 | Bluechip | printf("%d file%s copied", n, (n==1)?"":"s"); |
| 02:09:24 | midk | looks right to me |
| 02:09:35 | midk | to make it shorter: |
| 02:09:41 | Bluechip | i suggest that would be a beneficial way to use ? |
| 02:09:43 | midk | printf("%d file%s copied", n, (n>1)?"s":""); |
| 02:09:44 | midk | :) |
| 02:09:53 | Bluechip | 0 file copied ??? |
| 02:10:03 | midk | oh. |
| 02:10:05 | midk | :p |
| 02:10:06 | midk | HAHA. |
| 02:10:07 | Bluechip | lol |
| 02:10:08 | Bluechip | ;) |
| 02:10:33 | midk | rephrased: 'to make it shorter but less functional:' :) |
| 02:10:40 | Bluechip | lol |
| 02:10:43 | Bluechip | :D |
| 02:10:51 | Bluechip | now..... |
| 02:11:03 | Bluechip | how many times have *I* done that in my life? |
| 02:11:07 | Bluechip | lol |
| 02:11:46 | midk | mmm.. probably 0 :) |
| 02:11:53 | Bluechip | i wish |
| 02:12:06 | Bluechip | did you read my post on the database idea yet? |
| 02:12:21 | midk | nope |
| 02:12:25 | Bluechip | i used to do that for a living, you can be sure I cocked up more than one of those in my life |
| 02:12:59 | midk | 'id3 database browsing'? |
| 02:13:06 | Bluechip | indeed |
| 02:14:31 | midk | aaaaaaaaaahhaha |
| 02:14:34 | midk | "Adding itunes support sounds like a clincher to me." |
| 02:15:03 | Bluechip | I was actually referring to my most recent post |
| 02:15:16 | Bluechip | on database structuring |
| 02:15:18 | midk | i'm looking |
| 02:15:23 | midk | that just make me laugh |
| 02:15:33 | Bluechip | glad to be of service |
| 02:16:12 | midk | "PS. What is a "cluebie"?" |
| 02:16:14 | midk | HAHAHA funnier |
| 02:16:34 | Bluechip | still don't know ...is it "have a vague clue" or "all clued up" or something else? |
| 02:17:09 | midk | no idea |
| 02:17:56 | Bluechip | it's creator did not reply :( |
| 02:18:36 | midk | http://static.userland.com/userLandDiscussArchive/msg015585.html |
| 02:19:15 | Bluechip | aha |
| 02:19:39 | Bluechip | I'm a newbie - LMAO |
| 02:20:16 | midk | :)) |
| 02:20:50 | midk | as far as iTunes, i think being a cluebie is worse ;) |
| 02:21:20 | Bluechip | LOL |
| 02:21:28 | * | Bluechip giggling |
| 02:22:51 | midk | :) |
| 02:23:53 | Bluechip | we need a util to pull the id3 tags out of an mp3 file |
| 02:24:15 | midk | i need a util to gimme a c array from a 1bit bmp |
| 02:25:03 | Bluechip | you can get the header data by copying my win32sim code and changing the fwrites to freads |
| 02:25:50 | midk | fread? HAHA |
| 02:26:12 | midk | i just need to modify bmp2rb for it.. but whenever i run bmp2rb i get a segfault anyways |
| 02:26:36 | Bluechip | is your bmp saved in the "correct" format? |
| 02:26:47 | midk | 1bit.. should be |
| 02:26:55 | midk | i was thinking that may be it, i need to try again soon |
| 02:27:17 | midk | WINE can run notepad but not paint :( |
| 02:27:45 | Bluechip | weird |
| 02:45:05 | | Join DJBaz [0] (~baz@80.229.144.229) |
| 02:56:07 | midk | bagder? |
| 02:56:20 | midk | Bagder_, i mean :) |
| 02:58:33 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:29:14 | midk | bc? |
| 03:29:24 | Bluechip | mk! |
| 03:29:31 | midk | <3 |
| 03:30:09 | midk | any idea what the problem is? |
| 03:30:10 | midk | icons.c:27: parse error before `linavLogo' |
| 03:30:10 | midk | icons.c:27: warning: excess elements in scalar initializer |
| 03:30:10 | DBUG | Enqueued KICK midk |
| 03:30:10 | midk | icons.c:27: warning: (near initialization for `linavLogo') |
| 03:30:47 | Sebulba02 | Whats on that line? |
| 03:31:16 | midk | BITMAP linavLogo = {(unsigned int) linav_logo, 65, 10, 0, 0}; |
| 03:31:22 | midk | confusing, it works in a different .c |
| 03:31:26 | midk | .c file* |
| 03:32:10 | midk | i think i got it.. just a bit of tweaking |
| 03:32:27 | midk | i always do that.. i try to fix something for 20 minutes, then ask, then immediately figure it out |
| 03:32:31 | midk | apologies :) |
| 03:32:43 | Bluechip | I do that in Tesco |
| 03:35:30 | midk | tesco? |
| 03:36:06 | midk | a store? |
| 03:37:28 | Sebulba02 | your not the only one, sometimes you just need to talk to someone before you can figure it out, even if they have nfc of what your saying, heh |
| 03:39:21 | midk | haha :) |
| 03:39:32 | midk | actually that was sort of it |
| 03:40:16 | midk | i realized that you wouldn't know what BITMAP was −− i'm quite sure it's a standard C variable type −− and then i remembered i'd probably forgotten to include something |
| 03:41:01 | midk | s/quite sure it's a/quite sure it's not a |
| 03:41:56 | Sebulba02 | I was about to suggest that. |
| 03:42:11 | Sebulba02 | But its always better if you figure it out on your own :) |
| 03:42:46 | midk | next time i've got a problem i'll just paste it in a text editor as if i were pasting it to you, then come up with the answer right away :) |
| 03:43:24 | Sebulba02 | Or ask the wall your question & the answer will come to you. |
| 03:43:47 | midk | seems less convenient. |
| 03:44:11 | Sebulba02 | Oh, you don't talk to the walls? |
| 03:44:23 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 03:44:23 | * | Sebulba02 must just be weird then. |
| 03:44:31 | Bluechip | I talk to the trees, but they don't listen to me - LOL |
| 03:44:35 | midk | i generally attempt to refrain from the practice... |
| 03:44:38 | midk | haha :) |
| 03:48:03 | * | Sebulba02 goes back to star gazing. |
| 03:49:00 | Sebulba02 | Bluechip: Well, trees have other things to worry about, like not losing leaves.. or producing fruit. A wall has nothing real to worry about, it'll listen, heh. |
| 03:49:16 | Sebulba02 | Anyways. |
| 03:49:17 | Bluechip | hmmmmm |
| 03:49:22 | Bluechip | a good point |
| 03:54:07 | * | Sebulba02 thinks Cygnus is above him. |
| 03:55:07 | Bluechip | Is it a split decision? |
| 03:55:08 | Bluechip | lol |
| 03:56:19 | * | Sebulba02 looks lost. |
| 03:56:43 | Bluechip | Doesn't Cygnus link to the Gemini twins? |
| 03:57:10 | Bluechip | Maybe my mythology and/or astrology is off |
| 03:57:35 | Sebulba02 | I thought that was somehow a gemini thing, but I can't really tell based on this map. |
| 04:00 |
| 04:01:04 | Sebulba02 | Ah, a square chart helps. |
| 04:04:00 | Sebulba02 | Which oddly doesn't have gemini on it. |
| 04:04:08 | Bluechip | LOL |
| 04:04:24 | Bluechip | evil twin wins again |
| 04:04:55 | Sebulba02 | heh, hey.. I'm one of those :P |
| 04:05:02 | Bluechip | LOL |
| 04:05:18 | Sebulba02 | 3/4ths of my family is |
| 04:05:22 | Bluechip | weird |
| 04:05:52 | Bluechip | statistically very unlikely |
| 04:05:59 | Sebulba02 | Theres only 4 of us. |
| 04:06:04 | Bluechip | ah |
| 04:06:20 | Sebulba02 | But it is weird, yes. |
| 04:06:33 | Bluechip | then what is the occasion celebrated by your parents three months after your birthday? |
| 04:07:59 | Sebulba02 | Nothings in August, really. |
| 04:09:00 | Bluechip | I was surprised by the number of people who realised they were "birthday presents" |
| 04:09:57 | Sebulba02 | heh |
| 04:10:08 | Sebulba02 | Not in my case. |
| 04:10:16 | Bluechip | me neither (fwiw) |
| 04:10:36 | Sebulba02 | It was made clear a long time ago I was a mistake. |
| 04:10:44 | Sebulba02 | but who isn't? |
| 04:12:27 | Bluechip | My mother was on the pill (although now knowing that the 21yr test results are in, it would seem ...not taking it as prescribed) |
| 04:13:00 | Sebulba02 | heh |
| 04:13:08 | Sebulba02 | Oops. |
| 04:13:14 | Bluechip | lol |
| 04:19:42 | Sebulba02 | kick arse, Stargaze works in WINE |
| 04:53:43 | | Quit DJBaz ("Leaving") |
| 04:55:47 | | Quit midk (Remote closed the connection) |
| 04:57:39 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 04:58:34 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:20:15 | | Quit Bluechip () |
| 06:00 |
| 06:58:37 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:02:25 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 07:11:13 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 07:19:46 | | Quit AciD (Read error: 104 (Connection reset by peer)) |
| 07:20:06 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 08:00 |
| 08:35:26 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 08:42:17 | | Join [IDC]Dragon [0] (~idc-drago@pD95123A5.dip.t-dialin.net) |
| 08:43:05 | [IDC]Dragon | 'morning! |
| 08:45:04 | [IDC]Dragon | LinusN: r u there? |
| 08:48:43 | LinusN | i'm here |
| 08:49:05 | [IDC]Dragon | that's nice ;-) |
| 08:49:20 | LinusN | yeah, isn't it? |
| 08:49:26 | [IDC]Dragon | how did you like my hacking? |
| 08:49:37 | LinusN | you've been busy this weekend |
| 08:49:50 | [IDC]Dragon | mostly with our house |
| 08:50:17 | | Join Zagor [242] (~bjst@labb.contactor.se) |
| 08:51:07 | [IDC]Dragon | another good morning seem in order |
| 08:51:17 | LinusN | i haven't looked that much at your radio stuff, but so far it looks good |
| 08:51:22 | [IDC]Dragon | seems, hi Zagor |
| 08:52:04 | [IDC]Dragon | I replicated the i2c for now, credited it back to you |
| 08:53:13 | LinusN | ah, i see that |
| 08:53:32 | [IDC]Dragon | dunno if multi-instance is beneficial, passing a struct to it, with the port addresses and bit masks |
| 08:53:49 | LinusN | it will be on the iriver |
| 08:54:02 | LinusN | it has separate i2c busses for each device (!!!) |
| 08:54:42 | [IDC]Dragon | the port banging code would grow quite substantially, not using the short and_b() and or_b any more |
| 08:55:03 | LinusN | yup |
| 08:56:09 | [IDC]Dragon | the iriver folks had either ports to waste, or want to independently do their i2c from various contexts |
| 08:58:41 | *** | Saving seen data "./dancer.seen" |
| 08:59:22 | LinusN | their programmers probably didn't know about locking :-) |
| 08:59:54 | [IDC]Dragon | :-) ...or do I2c in interrupts |
| 09:00 |
| 09:00:05 | LinusN | maybe |
| 09:05:44 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
| 09:06:57 | | Join kurzhaarrocker [0] (~knoppix@p50877AEF.dip0.t-ipconnect.de) |
| 09:07:17 | kurzhaarrocker | Moin. |
| 09:07:18 | einhirn | Hello Kurzhaarrocker |
| 09:07:29 | einhirn | A feature Implementor? |
| 09:07:48 | kurzhaarrocker | :D That's what I crave for! |
| 09:08:26 | einhirn | Ah... Less work for us Humans, if a plugin like that would exist... ;) |
| 09:20:38 | | Join ey [0] (~knoppix@p508771E9.dip0.t-ipconnect.de) |
| 09:21:28 | ey | :( I stole my nick |
| 09:21:28 | * | ey slaps kurzhaarrocker |
| 09:22:17 | Mode | "#rockbox +o LinusN " by ChanServ (ChanServ@services.) |
| 09:22:34 | LinusN | who shall i kick? |
| 09:22:44 | ey | that kurzhaarrocker - ghost |
| 09:22:52 | Kick | (#rockbox kurzhaarrocker :LinusN) by LinusN!~linus@labb.contactor.se |
| 09:23:11 | LinusN | that felt good |
| 09:23:17 | ey | :D |
| 09:23:28 | ey | Still the nick is claimed to be in use |
| 09:25:17 | ey | LinusN: I updated the trigger code to the current cvs |
| 09:25:37 | LinusN | saw that, great! |
| 09:25:37 | einhirn | ey: Can't Nickserv do something for you? |
| 09:25:59 | LinusN | you should register kurzhaarrocker |
| 09:26:08 | ey | yes I should |
| 09:26:59 | | Nick ey is now known as langhaarrocker (~knoppix@p508771E9.dip0.t-ipconnect.de) |
| 09:27:32 | | Nick langhaarrocker is now known as kurzhaarrocker (~knoppix@p508771E9.dip0.t-ipconnect.de) |
| 09:27:36 | Zagor | btw, kurz, is there a reason why splitedit uses the currently playing file instead of being invoked from the "open with" menu? |
| 09:28:09 | kurzhaarrocker | Not really but there are many reasons why the spliteditor should be reprogrammed from scratch :) |
| 09:28:18 | Zagor | :) |
| 09:28:33 | LinusN | feel free to do it :-) |
| 09:28:48 | kurzhaarrocker | And I'm convinced that I started the spliteditor before there was the open with stuff |
| 09:28:54 | LinusN | yup |
| 09:29:55 | Zagor | yeah, I was just curious if you'd looked at it and dismissed it, or just hadn't looked at it |
| 09:31:35 | kurzhaarrocker | Well there in fact _is_ a reason: by pressing pause during playback you can preselect the coarse split position. Doing that within the split edtior is not very comfortable. It's merely for finetuning the split. |
| 09:32:03 | Zagor | ok. we could have it both ways. |
| 09:32:10 | kurzhaarrocker | yes |
| 09:32:49 | Zagor | do you have any ambition to do more work on splitedit? |
| 09:33:40 | kurzhaarrocker | I cant guarantee to have enough time this century. Otherwise I have many ideas about it. Fell free to do whatever you like with it :) |
| 09:34:04 | Zagor | ok, just checking |
| 09:47:09 | | Nick Bagder_ is now known as Bagder (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 09:55:08 | | Part kurzhaarrocker |
| 10:00 |
| 10:01:18 | Bagder | curl release day |
| 10:01:25 | LinusN | wooo |
| 10:01:43 | | Join kurzhaarrocker [0] (~knoppix@p508771E9.dip0.t-ipconnect.de) |
| 10:02:54 | Bagder | so now I deserve some coffee |
| 10:03:21 | Zagor | what do you guys say, should we release rockbox today too? |
| 10:03:37 | kurzhaarrocker | Is the recording bug squished? |
| 10:03:40 | LinusN | Zagor: are you nuts? |
| 10:03:52 | Zagor | hehe |
| 10:04:05 | Zagor | kurzhaarrocker: it appears to be a hardware bug |
| 10:04:21 | | Join Headie [0] (~hehe@fsto6.sto.sema.se) |
| 10:04:28 | LinusN | Bagder: i heard that wget is better than curl :-) |
| 10:05:03 | LinusN | Zagor: do we know that? i haven't had any feedback from paul yet |
| 10:05:25 | Zagor | −−> appears <−− |
| 10:05:26 | kurzhaarrocker | :( No triggered recording in the next rockbox release |
| 10:05:32 | LinusN | and paul definitely has problems with the asm ATA optimizations |
| 10:05:52 | Bagder | LinusN: :-P |
| 10:06:14 | LinusN | he can't run the dailies without removing the ata optimizations |
| 10:06:43 | Zagor | neato. do we have his hardware info logged? |
| 10:06:53 | LinusN | think so |
| 10:08:20 | Zagor | I recorded two hour-long sessions myself this weekend. the archos mic is quite impressive, for the price. a bit noisy, but very sensitive. |
| 10:08:53 | kurzhaarrocker | Concerning that recording bug: Why not turn off that crc check if it causes trouble? |
| 10:09:08 | LinusN | we might add an option for it |
| 10:09:25 | LinusN | but the stereo mode affects it as well |
| 10:10:48 | kurzhaarrocker | Sensitivity without sacrificing the s/n ratio is the hard and expensive part. |
| 10:11:07 | Zagor | yeah |
| 10:15:11 | Zagor | well I propose we disable crc, zip it up and release 2.3. all this waiting benefits noone. |
| 10:15:25 | Bagder | I agree |
| 10:15:35 | * | kurzhaarrocker cries |
| 10:15:51 | LinusN | Zagor: another release without a manual? |
| 10:16:00 | Bagder | there is one |
| 10:16:30 | LinusN | yes, we have the preliminary that christi started writing, but it is far from finished |
| 10:16:38 | Zagor | if needs be, yes. we can't just sit around and wait forever. |
| 10:16:50 | Bagder | well, no one writes docs then let's skip it |
| 10:17:05 | kurzhaarrocker | <- wrote docs for triggered recording :) |
| 10:17:11 | LinusN | she specifically waited until we froze the features |
| 10:17:21 | * | Bagder slaps the "good contributor" sticker on kurzhaarrocker |
| 10:18:26 | Zagor | I don't want to freeze now, it just takes more time and halts current work. we've got a pretty good state right now, let's ship it. |
| 10:18:55 | LinusN | Zagor: i assume you have tested the new fm radio code and found it allright? |
| 10:19:45 | Bagder | if it bugs terribly, we release a 2.3.1 |
| 10:19:52 | Zagor | I'm confident jörg and jens have. and if it's not working well, I'll be happy to release a new version tomorrow |
| 10:20:12 | LinusN | i really don't like this |
| 10:20:21 | Zagor | I know. you never like to release :) |
| 10:20:28 | LinusN | thanks |
| 10:20:33 | Bagder | we need a "release manager" |
| 10:20:38 | Bagder | honestly |
| 10:21:21 | Zagor | LinusN: well speak up, what exactly is it you want to wait for? |
| 10:21:50 | LinusN | i want the recording issue resolved |
| 10:22:04 | [IDC]Dragon | I want the keyboard for the ondio |
| 10:22:05 | LinusN | and i want a manual |
| 10:22:21 | Bagder | I want world peace |
| 10:22:26 | Bagder | :-O |
| 10:22:45 | [IDC]Dragon | me too |
| 10:22:54 | kurzhaarrocker | And I want triggered recordings - but I know I'm the only one who wants that. |
| 10:23:00 | Zagor | how many people are bitten by the recording issue? |
| 10:23:11 | Zagor | kurzhaarrocker: I want it too, but I don't want to delay the release for it |
| 10:23:24 | LinusN | we don't know how many that suffer from the recording bug |
| 10:23:25 | [IDC]Dragon | the ondio is almost ready... |
| 10:23:26 | Bagder | this isn't the last release you know ;-) |
| 10:23:33 | kurzhaarrocker | I know, Zagor, just nagging. |
| 10:23:49 | Zagor | LinusN: how many have reported it? |
| 10:24:12 | LinusN | paul is the only one who has put the finger on it |
| 10:24:15 | * | kurzhaarrocker has lost recordings |
| 10:25:39 | Zagor | so we're waiting for a bug that has bitten one or two persons? and the only clue we have is that crc introduced it. |
| 10:25:56 | LinusN | qoute from the forum: |
| 10:25:57 | LinusN | Quote from: pcspecialist on October 14, 2004, 09:38:34 PM |
| 10:25:57 | LinusN | I've had no luck getting stability out of any of the daily builds so you'll want to stay away from them. |
| 10:26:22 | Zagor | right, and how many bug reports have we seen from him? |
| 10:26:38 | LinusN | ok, go ahead, release it |
| 10:27:21 | LinusN | how many bug reports do you want to believe that there really is a bug? |
| 10:27:27 | kurzhaarrocker | Why not first try to disable crc, let paul and me try and then release in two days or so? |
| 10:27:58 | Zagor | kurzhaarrocker: paul got a test build over a week ago. linus can you send the same build to kurz? |
| 10:28:04 | LinusN | i sent paul a test version weeks ago |
| 10:29:03 | LinusN | http://linus.haxx.se/paul_rectest1.ajz |
| 10:29:07 | kurzhaarrocker | I have a practice session tonight anyway. A good opportunity for a 4 h recording. |
| 10:29:15 | LinusN | that is 2.2 with CRC check enabled |
| 10:29:45 | LinusN | if our theory is correct, the recording will be seriously corrupt |
| 10:30:02 | kurzhaarrocker | I'll try and report tomorrow |
| 10:30:06 | Zagor | ok good, I'll wait |
| 10:31:32 | Zagor | [IDC]Dragon: how much work would you say is left on the ondio port? |
| 10:31:52 | LinusN | i think we should announce a feature freeze, like we used to do |
| 10:33:27 | LinusN | for instance, we should make the recording file name generation algorithm an option |
| 10:33:42 | Zagor | why? that's a new feature. |
| 10:33:42 | LinusN | "regular" recorder users want that too |
| 10:33:59 | LinusN | we've tons of feature requests for that one |
| 10:34:03 | LinusN | we've had |
| 10:34:04 | Zagor | many people want a lot of new feaures |
| 10:34:05 | [IDC]Dragon | do we? |
| 10:34:33 | [IDC]Dragon | Zagor: a few days would be OK to brush it up, I'd say |
| 10:34:35 | LinusN | Zagor: since the ondio does it, the regular one could do it as well |
| 10:35:21 | [IDC]Dragon | I'm a big fan of releases, but not like announcing them for tomorrow |
| 10:35:39 | * | kurzhaarrocker wants directories generated by date and files named by time and my mind consists of many split personalities. Does that count extra? |
| 10:36:28 | [IDC]Dragon | give us some timline horizon to implement against, but no "snapshot release" |
| 10:37:37 | [IDC]Dragon | if I know a scheduled release is due, in, say a week, I can stabilize things well better |
| 10:40:59 | [IDC]Dragon | bbl |
| 10:41:05 | | Quit [IDC]Dragon () |
| 10:46:30 | | Join ashridah [0] (ashridah@220-253-119-176.VIC.netspace.net.au) |
| 10:48:36 | Bagder | clamav uses libcurl now |
| 10:48:48 | LinusN | c00l |
| 10:49:16 | kurzhaarrocker | what a pity it doesn't use wget. |
| 10:49:16 | * | kurzhaarrocker hides |
| 10:49:21 | Bagder | haha |
| 10:49:32 | Bagder | libcurl is quite a different beast than wget |
| 10:53:14 | * | Bagder 's daughter is right now sitting on the floor and rips toilet paper into very very tiny pieces |
| 10:53:15 | kurzhaarrocker | The only one time I wanted to use curl yet I had to realize my provider doesn't allow that. |
| 10:53:54 | Bagder | ;-) |
| 10:54:02 | Bagder | you mean the php module then? |
| 10:54:07 | kurzhaarrocker | yes |
| 10:57:53 | | Join amiconn [0] (~jens@pD95D1099.dip.t-dialin.net) |
| 10:58:07 | amiconn | G'morning |
| 10:58:16 | LinusN | yo |
| 10:58:34 | kurzhaarrocker | ghurt |
| 10:58:44 | *** | Saving seen data "./dancer.seen" |
| 10:59:21 | LinusN | amiconn: we are discussing the recording issue |
| 10:59:30 | amiconn | Yup. (log peeking) |
| 10:59:42 | Bagder | aha, a peeker! |
| 11:00 |
| 11:00:02 | kurzhaarrocker | That reminds me of good old C64 basic |
| 11:00:08 | amiconn | I like to remind you that I cannot test the radio code; no box with a radio :( |
| 11:00:32 | Zagor | LinusN: which feature did you say ondio has that "regular" doesn't? |
| 11:00:55 | LinusN | generating recording file names, "file0001.mp3" etc |
| 11:01:05 | LinusN | or is it "rec0001.mp3"? |
| 11:01:09 | amiconn | Ondio seriously lacks the keyboard :( |
| 11:01:40 | Zagor | yeah, because it doesn't have a clock |
| 11:01:41 | amiconn | (But I already have some idea how to do that with the limited keys) |
| 11:02:03 | Zagor | amiconn: if the crazy player people could do it, so can you ;) |
| 11:02:11 | LinusN | Zagor: yes, but people have been bugging us for years about not doing that for the regular recorder :-) |
| 11:02:30 | Zagor | yes, and I agree it would be a nice option. but it's not a release-stopper. |
| 11:02:58 | * | Bagder is off |
| 11:03:08 | LinusN | surely not, but i thought we could very well add it, since the code is there |
| 11:03:43 | amiconn | Zagor: The player keyboard is rather unintuitive (imho, now that I could test it with my Studio) |
| 11:03:58 | Zagor | amiconn: i agree completely |
| 11:04:12 | Zagor | however I don't think it *can* be made intuitive |
| 11:04:17 | LinusN | the player keyboard design is really silly |
| 11:04:47 | amiconn | I think it can, maybe that will become a by-product of the Ondio keyboard |
| 11:05:03 | Zagor | sounds good |
| 11:05:07 | | Join Lurkski [0] (~Miranda@24.30.163.142) |
| 11:06:40 | | Join edx [0] (edx@p54879108.dip.t-dialin.net) |
| 11:09:46 | Zagor | so is everyone happy with a week-long freeze instead then? |
| 11:10:12 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 11:11:01 | LinusN | yup |
| 11:11:16 | amiconn | Zagor: I don't like freezes :( The plugins need quite some rework... |
| 11:11:40 | LinusN | amiconn: that's not adding features, is it? |
| 11:12:46 | * | [IDC]Dragon just steps back in, reading logs |
| 11:13:04 | [IDC]Dragon | a week grace period sounds fine |
| 11:13:22 | amiconn | LinusN: Not quite, but it sometimes means to change how things work |
| 11:13:47 | Zagor | that's why I wanted to do a snapshot release, to avoid hindering current work |
| 11:13:57 | [IDC]Dragon | amiconn: what else have we got left for the ondio? |
| 11:14:10 | [IDC]Dragon | did I forget something? |
| 11:15:22 | amiconn | Most lacking is keyboard. Then we need dual-volume and howswap |
| 11:15:40 | [IDC]Dragon | the latter 2 can wait, I'd say |
| 11:15:51 | [IDC]Dragon | those are big features |
| 11:16:05 | Zagor | why is keyboard essential? |
| 11:16:18 | LinusN | file renaming etc |
| 11:16:36 | [IDC]Dragon | you're prompted with that in various places |
| 11:16:47 | [IDC]Dragon | e.g. .cfg saving |
| 11:17:38 | [IDC]Dragon | and I'm missing FM presets, found no button for that |
| 11:17:53 | [IDC]Dragon | maybe Jens has an idea |
| 11:18:35 | Zagor | file renaming is hardly essential on a flash player. config saving is nice, but could probably just as well use a couple of predefined names. |
| 11:19:21 | amiconn | Zagor: I would have needed file renaming already several times |
| 11:19:39 | Zagor | but if you think you can have keyboard code running in a short time, that's ok with me |
| 11:20:05 | | Join mrelwood [0] (~d5f38ec0@labb.contactor.se) |
| 11:20:11 | LinusN | fm preset handling should work too imho |
| 11:20:11 | Zagor | amiconn: yes, it's a nice feature. but hardly essential. lots of players (most, I would bet) lack it |
| 11:20:30 | [IDC]Dragon | I need to work a bit more on the tuner |
| 11:20:34 | amiconn | [IDC]Dragon: I can't test FM :( ... but, to overcome the small number of buttons, context menus would be rather handy... |
| 11:20:54 | Zagor | so now you're saying we should wait until the ondio is Release Quality |
| 11:21:15 | [IDC]Dragon | amiconn: but you can think about it ;-) |
| 11:21:20 | Zagor | I have massive respect for Jens and Jörg, but I doubt it will be done by next monday |
| 11:21:26 | mrelwood | Hey guys! Don't know if it's my english or understanding, but FAQ and forums didn't enlighten me. Is the Rockbox already working on a iRiver iHP-120? |
| 11:21:33 | Zagor | mrelwood: no |
| 11:21:41 | mrelwood | okay. |
| 11:21:51 | [IDC]Dragon | Zagor: it will be like 1.0 for rockbox |
| 11:21:51 | mrelwood | is it still under developement? |
| 11:21:53 | amiconn | I wanted to ask whether it is desired to rewrite the text viewer a bit. Today, it uses a heapload of non-intuitive key combos to cycle through various settings. It should have a config menu instead, with save function. |
| 11:22:16 | [IDC]Dragon | I wodn't worry about that |
| 11:22:18 | LinusN | mrelwood: we have only begun with the iriver port |
| 11:22:23 | Zagor | [IDC]Dragon: yes, that's how I feel it should be. and 1.0 didn't have file rename. |
| 11:22:29 | Zagor | (for example) |
| 11:22:30 | [IDC]Dragon | the main thing is to scroll up and down |
| 11:22:57 | kurzhaarrocker | [IDC]Dragon: bookmarking would be nice |
| 11:23:03 | mrelwood | cool! are the options and possibilities going to be the same as in the current for Archos? |
| 11:23:11 | kurzhaarrocker | (but that's something else) |
| 11:23:13 | Zagor | mrelwood: yes |
| 11:23:17 | LinusN | mrelwood: that's the plan |
| 11:23:17 | [IDC]Dragon | kurzhaarrocker: it does |
| 11:23:36 | mrelwood | so, input level metering for recording, and no recording time limits? |
| 11:23:37 | * | kurzhaarrocker is astonished |
| 11:23:52 | LinusN | mrelwood: yes |
| 11:24:01 | [IDC]Dragon | all Rockbox features are in Ondio as well, since it's the same code |
| 11:24:04 | kurzhaarrocker | o-oh, the metering. That will be interesting stuff to port |
| 11:24:22 | mrelwood | oh my! those are the only things that has kept me from getting the iHP! |
| 11:24:31 | LinusN | kurzhaarrocker: yes, we need a basic sound energy algorithm |
| 11:24:39 | [IDC]Dragon | Except for a few places where the buttons are too few and we had to explicitely cut features |
| 11:25:02 | mrelwood | but the recording formats and bitrates will be the same as they are in the iRiver originally? |
| 11:25:14 | Zagor | LinusN: i guess we need an rb lunch :) |
| 11:25:32 | kurzhaarrocker | But once we have that metering code it will probably precise in contrast to the archos hardware crap. |
| 11:25:51 | kurzhaarrocker | +be |
| 11:26:22 | Zagor | mrelwood: not necessarily. we will focus on mp3 first, and then add other formats after that. |
| 11:26:37 | mrelwood | but it will be able to do 320kbps mp3? |
| 11:26:44 | amiconn | [IDC]Dragon: What is the current button assignment in radio screen (both JB FMR and Ondio FMR)? |
| 11:27:32 | Zagor | mrelwood: hopefully, yes |
| 11:28:09 | LinusN | mrelwood: we honestly don't know much about the limitations in the original iriver firmware |
| 11:28:32 | Zagor | lunch, see you later |
| 11:28:33 | LinusN | lunch time |
| 11:28:35 | | Nick Zagor is now known as Zagor|lunch (~bjst@labb.contactor.se) |
| 11:28:58 | mrelwood | The original can rec up to 320kbps and 44.1kHz wav. But if the 320kbps is available, I'll surely wait instead of getting some other poor excuse for a DAP. Thanks guys! |
| 11:29:51 | kurzhaarrocker | What is DAP? |
| 11:31:04 | [IDC]Dragon | amiconn: FMR is tuning on left/right, volume on up/down, menu on F1, presets on F2, recording on F3, stop recording on Off, screen freeze on Play, exit on On |
| 11:32:01 | mrelwood | Digital Audio Player |
| 11:32:08 | kurzhaarrocker | ok |
| 11:32:12 | kurzhaarrocker | thx |
| 11:32:21 | [IDC]Dragon | OndioFM currently is same for direction, menu on long Menu, recording on short Menu, stop recording on Off, screen exit on long Off |
| 11:32:58 | mrelwood | american forums use it alot. like www.dapreview.com. mostly meaning mp3 players with a HD. |
| 11:33:12 | [IDC]Dragon | see radio.c, line 55 ff. |
| 11:33:46 | amiconn | [IDC]Dragon: two qns: (1) "exit" (On) brings you where? (2) Presets is a menu, or a cycle-through? |
| 11:34:21 | [IDC]Dragon | (1) exit goes back into the main menu where you came from |
| 11:35:16 | [IDC]Dragon | (2) presets is a menu |
| 11:39:13 | amiconn | Why do you exit from radio with "On" and not "Off"? Off would be much more logical... |
| 11:40:22 | amiconn | It would be the same as with the recording screen: 1st "Off" stops the recording, 2nd "Off" exits |
| 11:40:45 | amiconn | (no long hold necessary) |
| 11:44:13 | [IDC]Dragon | yes, with some slight code modifications we may do so |
| 11:45:04 | [IDC]Dragon | but how to call the presets menu? |
| 11:45:31 | [IDC]Dragon | unless we do very unintuitive combos with the menu button |
| 11:45:32 | amiconn | You can use some Menu+xxx combos |
| 11:45:52 | amiconn | Yes, that is not very intuitive :( |
| 11:47:14 | [IDC]Dragon | what are your ideas for the keyboard screen? |
| 11:48:04 | [IDC]Dragon | like, arrows move across the pickboard, menu arrows move within the string? |
| 11:48:56 | [IDC]Dragon | or, a 1-D pickboard instead of 2-D? |
| 11:49:02 | kurzhaarrocker | with menu being a "toggle" or a "shift" (combos) |
| 11:51:48 | amiconn | No, arrows move cursor around the screen (up/down/left/right), with a 4-row pickboard as it is now, but the cursor is also allowed to move outside the pickboard into the filename line, and move the insert position there. Menu+Left would be backspace there, and Menu+Right delete. |
| 11:52:21 | amiconn | Menu button inside pickbaord inserts character under cursor, long press accepts file name. |
| 11:52:36 | kurzhaarrocker | ok, got understood. |
| 11:53:22 | [IDC]Dragon | sounds good |
| 11:53:30 | amiconn | Moving the cursor across the left or right border of the pickboard selects previous/next pickboard |
| 11:53:55 | amiconn | (Perhaps with an alias on Menu+Left/Right for direct pickboard selection) |
| 11:54:19 | amiconn | Off button = cancel (same as now) |
| 11:54:34 | | Part Lurkski |
| 11:55:35 | amiconn | Some of these changes might be useful for recorders too, and the ideas could be re-used for a better player pickboard (1-line only, of course) |
| 11:56:38 | [IDC]Dragon | d the nice thing is that tis code can be tested on the simulator, for a change |
| 11:57:21 | [IDC]Dragon | (oops, I fail with this PC keyboard already) |
| 11:58:08 | kurzhaarrocker | btw: When I tried to build with target = recorder a dummy rombox is build. When I do the same with target = FMRecorder building rombox fails. Is that difference intensional? |
| 11:58:52 | amiconn | kurzhaarrocker: You need the updated uclpack for proper rombox. For FMR it fails because of too little flash space |
| 11:58:58 | [IDC]Dragon | you probably have no up to date uclpack |
| 11:59:28 | [IDC]Dragon | amiconn: for OndioFM, it now fails again, too |
| 11:59:32 | kurzhaarrocker | ok I'll test that tomorrow with current uclpack |
| 12:00 |
| 12:01:09 | amiconn | [IDC]Dragon: Radio is working properly now, or does it need some more polishing? |
| 12:05:00 | amiconn | I have to admit that I almost never use the simulator |
| 12:34:14 | | Join webguest64 [0] (~5149bab3@labb.contactor.se) |
| 12:43:19 | | Nick Zagor|lunch is now known as Zagor (~bjst@labb.contactor.se) |
| 12:49:54 | | Join thedude02 [0] (thedude02@pm477-42.dialip.mich.net) |
| 12:50:58 | | Part thedude02 |
| 12:51:31 | LinusN | amiconn: u there |
| 12:51:32 | LinusN | ? |
| 12:58:48 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:00:54 | amiconn | LinusN: Now I am. |
| 13:01:02 | [IDC]Dragon | me too |
| 13:01:09 | [IDC]Dragon | (just got back) |
| 13:02:07 | [IDC]Dragon | amiconn: the radio needs a better "tuned" detection for the search mode, ans I need to suspend it after use |
| 13:04:17 | amiconn | Doesn't the philips tuner have an autotune feature? Just use this... |
| 13:04:47 | [IDC]Dragon | it has, but the generalization would go overboard |
| 13:05:29 | [IDC]Dragon | right now, the radio screen doesn't know which tuner it is talking to. |
| 13:06:23 | amiconn | Why? You could implement the autotune feature as a tuner api function. For philips, it would use the chip's autotune feature, and for samsung it would do it the same way as now |
| 13:07:14 | [IDC]Dragon | possible, then the samsung implementation needs a task |
| 13:07:43 | | Quit mrelwood ("CGI:IRC (EOF)") |
| 13:08:09 | kurzhaarrocker | There's a bug in recording.c that can be fixed easily: When you enter quickscreens from the recording screen the blinking red led might stay switched on. Very irritating when there's neither disk access nor a recording in progress |
| 13:08:19 | kurzhaarrocker | Want a patch file? |
| 13:14:15 | amiconn | [IDC]Dragon: Why would it need a thread? The current system does the autotune in the main thread, right? |
| 13:16:45 | [IDC]Dragon | if we want a common interface, you either (1) say: tune to xx MHz, then tell me if this is a station. You iterate until a good one is found. |
| 13:17:24 | [IDC]Dragon | or (2) you say "search upwards" to the tuner interface, sit an poll until tuned |
| 13:18:22 | [IDC]Dragon | for (2), and a tuner without a search feature, the tuner wrapper has to autonomously tune and test, to emulate it |
| 13:19:02 | [IDC]Dragon | so it would need a thread, unless you do something crappy like a tick function |
| 13:19:29 | [IDC]Dragon | e.g. the polling from the top level could be used to advance |
| 13:22:08 | amiconn | Iirc, the current tuning works that way, or can't you auto-search upward, but only tune in steps by hand? |
| 13:23:25 | [IDC]Dragon | ?? The samsung tuner need to be set each time, the Philips has a search enable and a direction bit, plus a readback if the search stopped |
| 13:23:28 | amiconn | In that case, I think a thread would be needed, for philips as well. Then the thread could report the "station found" back to the main thread via an event - no polling |
| 13:23:48 | | Nick kurzhaarrocker is now known as kurzhaarrocker|l (~knoppix@p508771E9.dip0.t-ipconnect.de) |
| 13:24:13 | amiconn | My question was: Can you auto-tune in the current radio screen, or not? |
| 13:24:20 | [IDC]Dragon | the radio screen has nothing to do anyway |
| 13:24:45 | [IDC]Dragon | the screen does have a search, if that is what you mean |
| 13:25:18 | [IDC]Dragon | it advances the tuner by 100kHz, checks for tuning, and so on |
| 13:25:37 | amiconn | No I mean (like I would expect from it): short press of left/right would tue down/up by 50 kHz, while a longer press would start a search for the previous/next station |
| 13:26:50 | [IDC]Dragon | exactly, yes |
| 13:27:33 | amiconn | And the tune/check/tune.. is currently done within the main thread? |
| 13:27:40 | [IDC]Dragon | yes |
| 13:28:15 | amiconn | Hmm. Then I think we should go for an additional thread. |
| 13:28:43 | [IDC]Dragon | I try to keep it simple, if we can |
| 13:31:06 | amiconn | I think the auto-tune by the chip might work both faster and better than a hand-implementation. If this needs a thread for non autosearch capable tuners to be properly wrappable, then let's do it |
| 13:31:49 | [IDC]Dragon | LinusN: reading? |
| 13:35:20 | [IDC]Dragon | Or like I wrote above, I use the poll interval of the screen as a tick to try the next frequency |
| 13:41:14 | amiconn | The samsung tuner probably needs some time until it tuned to a new frequency, right? Des it report back when done, or is there a fixed delay time? |
| 13:42:24 | [IDC]Dragon | sleep(1) |
| 13:45:13 | LinusN | what is the problem? |
| 13:45:27 | [IDC]Dragon | no problem |
| 13:45:40 | LinusN | then why are we talking about separate threads for tuning? |
| 13:46:38 | [IDC]Dragon | ok, (so far) the tuning is not detected, the search is failing |
| 13:47:14 | [IDC]Dragon | right now I don't remember if it always stops, or always carries on |
| 13:47:25 | [IDC]Dragon | I think it stops |
| 13:47:44 | [IDC]Dragon | Jens raised the autosearch of the Philips |
| 13:49:18 | [IDC]Dragon | but first I'd like to check what the IF counter really returns |
| 13:52:52 | LinusN | absolutely |
| 13:52:57 | | Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) |
| 13:53:16 | LinusN | i prefer the "manual" tuning, because it makes the API simpler |
| 13:58:40 | amiconn | Why not use a feature already present in the chip? |
| 13:59:50 | Zagor | use a callback to avoid the need for a thread |
| 14:00 |
| 14:00:00 | LinusN | because it forces us to emulate it on the other chip and |
| 14:00:33 | LinusN | i think it's better to use the common feature set |
| 14:00:47 | LinusN | why is the autotuning feature better? |
| 14:00:55 | LinusN | is it more accurate? |
| 14:01:13 | [IDC]Dragon | if it works and the other doesn't, it is better ;-) |
| 14:01:35 | Zagor | we already emulate it, don't we? |
| 14:01:39 | amiconn | I think it will be both faster and more accurate, because the chip decides when to advance the frequency |
| 14:01:41 | LinusN | i doubt that the semi-manual methos doesn't work |
| 14:01:45 | [IDC]Dragon | let's rather call it autosearch |
| 14:02:20 | LinusN | Zagor: yes, but we'd have to emulate in on the API level, if we want the interface "clean" |
| 14:02:46 | [IDC]Dragon | then please change the subject until I found out |
| 14:03:31 | Zagor | LinusN: is that so bad? if both use a callback for screen updates, the api would be nice and clean |
| 14:03:41 | [IDC]Dragon | (the discussion is premature) |
| 14:04:02 | Zagor | well we can still discuss the principle |
| 14:07:14 | [IDC]Dragon | ok, my $0.02 then: in terms of code size, it probably doesn't matter much if the stepping is done in the screen or in a tuner thread. The latter architecture pays off if you have a search-capable tuner, then you can drop that ( little bit of) code |
| 14:07:42 | [IDC]Dragon | right now, I tried not to turn everything upside down |
| 14:07:45 | | Part oxygen77 ("Cho") |
| 14:07:45 | Zagor | why a thread instead of a callback? |
| 14:08:01 | [IDC]Dragon | who does the stepping? |
| 14:08:31 | Zagor | since we are talking in the context of a single thread, the answer is: the code |
| 14:08:54 | [IDC]Dragon | so you tick the lower tuner layer? |
| 14:09:03 | Zagor | i.e. tuner_autosearch(up, &search_callback) |
| 14:09:28 | [IDC]Dragon | as a blocking call, you mean, now I get it |
| 14:09:31 | Zagor | yes |
| 14:09:59 | [IDC]Dragon | hmm, might not be so friendly to all the other button handling |
| 14:10:05 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:10:32 | Zagor | sure it would. the callback can check the button queue and order the search function to abort |
| 14:10:54 | | Quit edooo (Remote closed the connection) |
| 14:11:07 | Zagor | (via its' return code) |
| 14:11:09 | [IDC]Dragon | then the callback ticks the app? |
| 14:11:17 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:11:21 | | Quit edooo (Remote closed the connection) |
| 14:11:43 | Zagor | the callback handles screen updates and maybe button checking to see if user wants to stop searching |
| 14:11:56 | Zagor | app-level stuff |
| 14:12:08 | [IDC]Dragon | this is very upside down now |
| 14:12:20 | Zagor | if the callback returns false, tuner_search aborts and returns |
| 14:13:41 | [IDC]Dragon | I don't like to overuse callbacks, they revert the normal layer hierarchy |
| 14:14:23 | Zagor | i don't think this is overuse. it's a simple way to add user feedback to a long blocking function without having to add a dedicated thread |
| 14:15:01 | Zagor | sort of like a progress indicator callback |
| 14:15:32 | [IDC]Dragon | but a big one, which contains all the event-driven code of the screen |
| 14:16:25 | Zagor | what it does is up to the application. the tuner code just contains the option. |
| 14:16:36 | Zagor | how do you mean all event-driven code? |
| 14:16:59 | Zagor | the callback would not start new functions |
| 14:17:19 | Zagor | (other than lcd_drawstring etc) |
| 14:17:50 | [IDC]Dragon | it has to do all the work the screen usually does. Check buttons, invoke actions |
| 14:18:31 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:18:33 | Zagor | no, the only button check is to allow the user to abort searching. |
| 14:18:49 | | Quit edooo (Remote closed the connection) |
| 14:19:03 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:19:06 | [IDC]Dragon | and if we simply want to adjust volume during the search? |
| 14:19:11 | Zagor | you can't |
| 14:19:26 | | Quit edooo (Remote closed the connection) |
| 14:19:41 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:19:53 | Zagor | maybe i'm misunderstanding everything, but surely while searching there is no actual sound? |
| 14:19:53 | | Quit edooo (Read error: 54 (Connection reset by peer)) |
| 14:20:20 | [IDC]Dragon | not nice. Then I have to exit the search, remember the condition, later adjust the volume and kick off a new search |
| 14:20:49 | Zagor | exit the search? doesn't the search exit automatically when you find a channel? |
| 14:20:54 | [IDC]Dragon | what piece of code were we trying to save, btw? |
| 14:21:36 | Zagor | we want to be able to use the hardware search |
| 14:22:03 | [IDC]Dragon | I know. At quite some cost, it seems now. |
| 14:22:04 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:22:30 | Zagor | ? |
| 14:22:47 | | Quit edooo (Remote closed the connection) |
| 14:23:02 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:23:37 | [IDC]Dragon | I mean, if we start to workaroud setting up an interrupted search, to allow things like volume set |
| 14:23:41 | | Quit edooo (Remote closed the connection) |
| 14:24:01 | Zagor | granted, I don't have an FM unit so I'm probably in the blue here. but doesn't it work just like a normal car radio: press SEARCH+ to search for a channel at a higher frequency. the display shows the increasing frequency and the sound is muted. when a channel is found, the display stops and sound is turned on again |
| 14:24:14 | Zagor | why would you want to adjust volume while searching. there is no sound! |
| 14:24:15 | | Join elinenbe [0] (~elinenbe_@65.115.46.225) |
| 14:24:25 | elinenbe | bonjour |
| 14:24:42 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:24:46 | | Quit edooo (Read error: 54 (Connection reset by peer)) |
| 14:24:58 | [IDC]Dragon | there is sound, and it may be interesting information to you, because you e.g. just went over that weak station you're looking for |
| 14:25:18 | Zagor | it's like adjusting volume while fast-forwarding an mp3 file |
| 14:25:39 | Zagor | but, sure, we can adjust volume in the callback if that is a desired function |
| 14:26:22 | [IDC]Dragon | please let me try to use "Samsung mode" first |
| 14:26:42 | Zagor | i.e. not use the hardware feature? |
| 14:26:55 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 14:26:58 | [IDC]Dragon | for the time being, yes |
| 14:27:29 | [IDC]Dragon | the Ondio needs to support both tuners anyway, decided at runtime |
| 14:27:56 | | Quit edooo (Remote closed the connection) |
| 14:28:34 | [IDC]Dragon | and you want to release in a week ;-) |
| 14:29:02 | Zagor | i wanted to release today... |
| 14:29:05 | amiconn | For getting it to work, I agree (like not using DMA was useful for me to get MMC to work at all), while once it works, using the chip's autotune would be desired. |
| 14:29:40 | Zagor | amiconn: agreed |
| 14:29:52 | amiconn | If there is a feature in one chip and not in the other, it is imho better to implement the feature in software for the chip lacking it, instead not using the feature just because the other chip doesn't offer it |
| 14:30:04 | Zagor | if practical, yes |
| 14:30:26 | [IDC]Dragon | but imagine you have to use the non-DMA for the other anyhow, then it's tempting to not utilize it |
| 14:31:13 | [IDC]Dragon | assumed if there is no practical drawback |
| 14:32:02 | [IDC]Dragon | guys, I'm happy the tuner works at all today |
| 14:32:14 | amiconn | Imho the auto-tune in software should not need much code, but it needs either a thread, or a tick-task |
| 14:33:28 | Zagor | why? |
| 14:34:07 | [IDC]Dragon | I gree that I prefer the tick over the callback. |
| 14:34:13 | amiconn | In order to get the same behaviour as for the autotune-capable chip, without adding extended callback mechanisms |
| 14:34:52 | Zagor | a callback is MUCH more simple than adding tick tasks or threads |
| 14:35:24 | [IDC]Dragon | this callback loop would be an emulation for the autotuning, because naturally it could return right away |
| 14:36:05 | Zagor | the callback has nothing to do with tuning, it only handles the user feedback |
| 14:36:17 | [IDC]Dragon | else you would fire off the search, then query it once in a while how it is doing |
| 14:37:39 | Zagor | ...which requires a state machine in the user interface code, PLUS a whole thread just to create user feedback |
| 14:38:03 | [IDC]Dragon | no |
| 14:38:28 | [IDC]Dragon | case 1, autosearching tuner: |
| 14:38:58 | [IDC]Dragon | the user holds e.g. Right to start search |
| 14:39:22 | [IDC]Dragon | the app call search(up, 95.5 MHz) |
| 14:39:50 | [IDC]Dragon | which returns after setting the frequnecy and search dir |
| 14:40:22 | [IDC]Dragon | the app periodically updates the screen, so it calls get_search_state() |
| 14:40:57 | [IDC]Dragon | which returns current frequency, stopped, strenght, whatever |
| 14:41:17 | Zagor | what happens when the user holds right again, during searching? |
| 14:41:21 | [IDC]Dragon | case 2, Samsung tuner: |
| 14:41:51 | [IDC]Dragon | it may start a new search at the current frequency |
| 14:42:35 | [IDC]Dragon | which is probably no harm and no difference |
| 14:42:50 | [IDC]Dragon | it definitely has to start anew if the user holds Left |
| 14:43:01 | [IDC]Dragon | ready for case 2? |
| 14:43:15 | Zagor | i don't need it |
| 14:43:42 | Zagor | i still think adding a thread is much more unneeded complexity than just running a callback each .25 MHz or whatever |
| 14:44:24 | Zagor | plus that we don't have these types of asynchronous calls anywhere else in rockbox |
| 14:44:38 | [IDC]Dragon | my dummy approach for Samsung wound be to do the first tuning on search(up, 95.5 MHz) |
| 14:45:07 | [IDC]Dragon | the next on each get_search_state() call |
| 14:46:52 | | Nick kurzhaarrocker|l is now known as kurzhaarrocker (~knoppix@p508771E9.dip0.t-ipconnect.de) |
| 14:49:54 | Zagor | question: how is tuner_search different from jpeg_decode? |
| 14:50:12 | * | Bagder gets bored by the db thread on the list |
| 14:51:04 | [IDC]Dragon | Zagor: because you found a callback there? |
| 14:51:08 | Bagder | I actually tried to make a db according to the TagDatabase wiki page |
| 14:51:53 | Zagor | [IDC]Dragon: it appears to be a callback that does pretty much want I'd like the callback in tuner_search to do |
| 14:53:30 | [IDC]Dragon | that callback doesn't run the whole UI |
| 14:53:48 | Zagor | neither would the one in tuner_search. i don't know where you got that from. |
| 14:54:32 | Zagor | let me explain my view: |
| 14:55:21 | Zagor | if user holds right, app calls tuner_search(up, 95.5, &callback) |
| 14:56:09 | Zagor | tuner_search() starts searching upwards from 95.5, either using hardware search or software search. each 0.25 MHz it calls callback(some,info) |
| 14:56:51 | [IDC]Dragon | for HW, I can't assure a certain frequency interval |
| 14:57:03 | Zagor | ok, at some interval then |
| 14:57:53 | Zagor | callback() redraws the screen with the new info, and checks if user pressed an abort button. if so, it returns false |
| 14:58:12 | Zagor | tuner_search() checks the return code from callback(). it it is false, it stops searching and returns to the app |
| 14:58:43 | Zagor | if we want to be able to adjust volume during search, callback() can check for those buttons too |
| 14:58:52 | *** | Saving seen data "./dancer.seen" |
| 14:59:13 | [IDC]Dragon | I was afraid this redraw and button handler would replicate a lot of the normal UI |
| 14:59:31 | Zagor | it can call the same draw function as the normal ui loop |
| 15:00 |
| 15:00:15 | Zagor | but the abort search button is a search-specific ui, so it has to be done separately |
| 15:01:00 | | Join pillo [0] (~trillian@navlab03.dei.unipd.it) |
| 15:03:01 | [IDC]Dragon | my thinking was that the search runs more or less in the background, decoupled from the screen |
| 15:03:55 | Zagor | yes, but I don't think the user sees it that way so there is no need for the code to do that either. searching is a pretty active action. |
| 15:09:59 | amiconn | Using a thread or tick task would enable setting the volume etc. independently whether a seach is running or not, with no additional code |
| 15:10:20 | Zagor | a new thread is no additional code? :) |
| 15:10:55 | amiconn | Plus, the thread/task would only needed to be started if a samsung tuner is found. |
| 15:11:59 | Zagor | why do you want to use a thread when it's not needed? |
| 15:12:08 | LinusN | i didn't follow the discussion |
| 15:12:21 | LinusN | do we know for a fact that we need to use the auto-tune funcion? |
| 15:13:08 | Zagor | it's not a question of "needs", we're discussion on the assumption that autotune will bring a benefit |
| 15:14:03 | LinusN | in any case, i fail to see the need for a separate thread |
| 15:14:30 | amiconn | With the callback approach you would have to account for whether a search is running or not in the ui code. With a thread/task you don't |
| 15:14:41 | LinusN | yes you do |
| 15:14:47 | LinusN | the user wants the feedback |
| 15:15:34 | amiconn | Yes, but that is much easier (imho) than different button checking in a large callback function |
| 15:15:34 | Zagor | amiconn: quite the opposite. with a callback you *don't* need such state information, since everything is a single thread and thus call tree |
| 15:15:49 | Zagor | for the 98th time, it's not a large callback function |
| 15:16:26 | LinusN | it could be the same function that the radio code uses for the screen update |
| 15:16:41 | amiconn | You need to distiguish whether the ui code is called via callback or directly, or you have to duplicate the ui code |
| 15:17:01 | Zagor | no we don't. both functions can call radio_drawscreen() |
| 15:17:34 | LinusN | but the button polling might be slightly different in the callback context |
| 15:18:00 | Zagor | yes, because it is different functions. when not searching, you naturally don't have a button to abort it... |
| 15:18:06 | amiconn | yup, that's what I mean |
| 15:18:12 | LinusN | (btw, this is exactly what i want to avoid by not using the autotune function) |
| 15:18:17 | Zagor | sort of like you can't stop ffwd in pause mode |
| 15:19:03 | LinusN | but the extra complexity in the button handler is nothing compared to adding a new thread |
| 15:20:10 | Zagor | just imagine all the nice cleanup code. "oh, do we have a search running? we need to stop it before exiting radio screen" |
| 15:21:11 | Zagor | how do you stop a search? are some buttons conditional depending on if you are in search state or not? |
| 15:22:43 | LinusN | currently, you stop the search by clicking left or right |
| 15:22:53 | LinusN | i.e tune manually |
| 15:23:00 | LinusN | iirc |
| 15:32:50 | elinenbe | LinusN: how is the iriver progress coming? anything on the drawing board right now? |
| 15:34:34 | Zagor | which is the better win32 program: eac or cdex? |
| 15:35:47 | Zagor | btw, Bagder: i tried upgrading my plextor firmware but it still freaks out on bad disks. |
| 15:35:52 | kurzhaarrocker | Depends on wether you prefer emacs or vi? :) |
| 15:35:56 | Bagder | Zagor: ok |
| 15:36:29 | Zagor | kurzhaarrocker: emacs. doesn't everyone? ;) |
| 15:37:39 | kurzhaarrocker | apropos thread: I'd still favor a thread to read out the peak meter registers :) |
| 15:38:28 | kurzhaarrocker | concerning eac vs cdex: I used both and both worked to my satisfaction. I don't prefer either over the other. |
| 15:38:39 | Zagor | so they're pretty much the same? |
| 15:38:52 | kurzhaarrocker | At least the result is pretty much the same. |
| 15:39:54 | LinusN | elinenbe: will probably work on it this evening |
| 15:40:08 | LinusN | timers and LCD driver is next |
| 15:40:26 | kurzhaarrocker | LinusN is our lonely worrier at the iriver front. |
| 15:40:54 | Zagor | i'm looking at the mp3 encoder right now |
| 15:41:18 | LinusN | Shine |
| 15:41:34 | Zagor | yeah |
| 15:41:43 | | Join JoyOfDuck [0] (~d98680b3@labb.contactor.se) |
| 15:43:12 | JoyOfDuck | Hello - Can anyone spare a minute to shed light on a mis-behaving Jukebox Studio |
| 15:43:23 | LinusN | shoot |
| 15:43:55 | JoyOfDuck | thankyou - My little box of tricks just stopped working |
| 15:44:07 | JoyOfDuck | It only powers on when the USB cable is conmnected |
| 15:44:25 | JoyOfDuck | Appears to work fine in USB mode, but not at all in play, or battery charge mode |
| 15:44:34 | JoyOfDuck | Thought it might be a hardware issue |
| 15:44:54 | kurzhaarrocker | Are the batteries really fully charged? Might they be old and broken? |
| 15:45:14 | JoyOfDuck | I thought it might be the batteries, so changed them for new ones |
| 15:45:42 | LinusN | what happens when you try to turn it on? |
| 15:46:07 | JoyOfDuck | The green LED flicks on once - no disc motor, no backlight |
| 15:46:26 | LinusN | does it charge the batteries? |
| 15:46:35 | JoyOfDuck | Appears not |
| 15:46:46 | LinusN | my guess is that the IRF7416 is broken |
| 15:46:49 | JoyOfDuck | I took it apart and checked voltages |
| 15:47:01 | JoyOfDuck | Got les than three volts across the battery terminals |
| 15:47:06 | LinusN | what heppened when it stopped working? |
| 15:47:26 | LinusN | 3 volts |
| 15:47:34 | kurzhaarrocker | that's nearly nothing |
| 15:47:38 | LinusN | have you checked the battery terminals themselves? |
| 15:47:42 | JoyOfDuck | I left it charging for a few hours and noticed that it wasn't warming up |
| 15:47:49 | JoyOfDuck | Tried switching it on and it was dead |
| 15:47:51 | LinusN | the connections to the small PCB:s |
| 15:48:02 | kurzhaarrocker | Or maybe you checked the wrong terminals and measured only two batteries? |
| 15:48:15 | JoyOfDuck | I checked the battery termansl at the top |
| 15:48:26 | kurzhaarrocker | ok |
| 15:48:27 | JoyOfDuck | Also checked the two solder tabs at the top end of the board |
| 15:48:34 | LinusN | then your batteries are discharged |
| 15:48:48 | JoyOfDuck | They are brand new, so I expect that they are discharged |
| 15:49:35 | JoyOfDuck | Is the IRF7416 the battery chargin component? |
| 15:50:21 | JoyOfDuck | I was prepared to lose my favourate toy, but then noticed it worked fine with a USB cable plugged in |
| 15:50:32 | JoyOfDuck | Thought that might indicate a simple hardware problem |
| 15:52:02 | JoyOfDuck | Oh well, that looks like it. Thanks for your time - I'll start saving for an iRiver |
| 15:52:04 | kurzhaarrocker | To start charging you have to leave them for serveral minutes in the jukebox |
| 15:52:26 | JoyOfDuck | Oh yes - I have left them variously for several hours |
| 15:52:45 | kurzhaarrocker | If you have an external charger you might want to try charging them separately. |
| 15:53:02 | JoyOfDuck | Good idea - I'll try and borrow one |
| 15:53:24 | JoyOfDuck | Might be able to limp along until Christmas :-) |
| 15:54:24 | JoyOfDuck | If anyone thinks of anything, my addy is "joy at beyond2000.co.uk" |
| 15:54:27 | JoyOfDuck | Thanks again |
| 15:54:59 | LinusN | you're welcome |
| 15:55:53 | LinusN | gotta go now, cu guys |
| 15:55:57 | | Quit webguest64 ("CGI:IRC (EOF)") |
| 15:55:59 | | Part LinusN |
| 15:57:20 | amiconn | kurzhaarrocker: Iirc he said he has a Studio - Players charging is hardware |
| 16:00 |
| 16:02:56 | | Join Lynx_ [0] (lynx@134.95.189.59) |
| 16:05:31 | kurzhaarrocker | right, amiconn, stupid me. |
| 16:05:50 | JoyOfDuck | Helo are we still thinking about my Studio 20 issue? |
| 16:15:40 | amiconn | JoyOfDuck: I'd try the following things: |
| 16:15:52 | JoyOfDuck | Hello |
| 16:16:18 | amiconn | (1) Take a set of 4 new batteries, charge them externally and put them into the box. Does it start? |
| 16:16:40 | amiconn | If yes, the charging circuit in the box is most likely broken. |
| 16:17:50 | JoyOfDuck | Thanks - I plan doing this first point following the earllier suggestion |
| 16:18:19 | amiconn | If it does not start, (2) measure the voltage across the battery contacts, both at zero load (box off) and while trying to start. |
| 16:19:12 | amiconn | If the voltage drops below ~4.5 V while trying to start (with fully charged cells) the battery contacts are broken |
| 16:20:26 | amiconn | Anyone here who knows which of the 4 contacts are the ends (can't check myself atm) of the 4-cell circuit? |
| 16:21:53 | | Quit Zagor (burroughs.freenode.net irc.freenode.net) |
| 16:21:53 | NSplit | burroughs.freenode.net irc.freenode.net |
| 16:23:15 | NHeal | burroughs.freenode.net irc.freenode.net |
| 16:23:15 | NJoin | Zagor [242] (~bjst@labb.contactor.se) |
| 16:24:14 | JoyOfDuck | I see a photo on the Rockbox site at http://www.rockbox.org/docs/solderjoints.jpg |
| 16:26:05 | JoyOfDuck | I also had the second symptom of broken contacts: Reboot when the bumpers are compressed |
| 16:26:10 | Zagor | hmm, the "fixed point" implementation of Shine uses double, log and sqrt... |
| 16:27:06 | amiconn | JoyOfDuck: The pictures are for a JB recorder, but the problem most likely also exists for players. |
| 16:27:20 | JoyOfDuck | Ahah! |
| 16:27:37 | JoyOfDuck | Thanks again for the help - I'll report back once I have a working player :-) |
| 16:47:11 | kurzhaarrocker | Well the peak meter code contains some log too, Zagor :) |
| 16:53:36 | Zagor | :) |
| 16:54:14 | Zagor | see you |
| 16:54:15 | | Part Zagor |
| 16:55:22 | | Quit ashridah ("sleep") |
| 16:58:53 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:01:09 | | Join gromit``` [0] (~gromit@ALagny-151-2-2-244.w82-121.abo.wanadoo.fr) |
| 17:06:27 | | Join methangas [0] (methangas@0x50a476bc.virnxx10.adsl-dhcp.tele.dk) |
| 17:18:22 | | Quit gromit`` (Read error: 110 (Connection timed out)) |
| 17:22:03 | | Join mecraw__ [0] (~lmarlow@69.2.235.2) |
| 17:25:59 | | Quit [IDC]Dragon ("CGI:IRC") |
| 17:34:20 | | Part pillo |
| 17:36:26 | | Part kurzhaarrocker |
| 18:00 |
| 18:03:52 | | Quit einhirn (Read error: 54 (Connection reset by peer)) |
| 18:15:44 | | Quit edx (Read error: 54 (Connection reset by peer)) |
| 18:21:48 | | Join elinenbe_ [0] (~elinenbe_@65.115.46.225) |
| 18:39:39 | | Quit elinenbe (Read error: 110 (Connection timed out)) |
| 18:39:39 | | Nick elinenbe_ is now known as elinenbe (~elinenbe_@65.115.46.225) |
| 18:42:18 | | Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
| 18:58:57 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:54:44 | | Join schnauz [0] (zazz@dh051-118.chem.sunysb.edu) |
| 20:00 |
| 20:13:04 | | Quit Headie (Read error: 110 (Connection timed out)) |
| 20:29:17 | | Quit _Lucretia (Connection timed out) |
| 20:29:49 | | Join [av]bani [0] (~goemon@washuu.anime.net) |
| 20:29:59 | | Part [av]bani |
| 20:29:59 | | Join _Lucretia [0] (~munkee@abyss2.demon.co.uk) |
| 20:42:27 | | Join Headie [0] (~hehe@fsto6.sto.sema.se) |
| 20:59:00 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:01:06 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so cool") |
| 21:07:56 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 21:11:24 | | Quit JoyOfDuck ("CGI:IRC (Ping timeout)") |
| 21:13:17 | | Quit edooo (Read error: 54 (Connection reset by peer)) |
| 21:15:47 | | Nick _Lucretia is now known as _Lucretia_ (~munkee@abyss2.demon.co.uk) |
| 21:28:37 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 21:32:10 | | Quit edooo (Read error: 54 (Connection reset by peer)) |
| 21:34:55 | | Join edooo [0] (~edooo_188@82.129.244.5) |
| 21:35:47 | | Quit edooo (Read error: 54 (Connection reset by peer)) |
| 21:49:51 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 21:54:17 | | Join gmb [0] (~441ae028@labb.contactor.se) |
| 21:55:34 | | Quit gmb (Client Quit) |
| 22:00 |
| 22:23:42 | | Join dropandhop [0] (~43646aab@labb.contactor.se) |
| 22:23:47 | dropandhop | hey all! |
| 22:23:53 | dropandhop | iriver user here |
| 22:23:57 | dropandhop | was wondering how i could help |
| 22:24:01 | dropandhop | i can't code tho! |
| 22:34:20 | | Quit elinenbe (" Try HydraIRC -> http://www.hydrairc.com <-") |
| 22:41:14 | | Join [av]bani [0] (~goemon@washuu.anime.net) |
| 22:41:22 | | Part [av]bani |
| 22:46:53 | | Join Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 22:59:01 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:26:25 | | Nick scott666_ is now known as scott666 (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 23:36:56 | | Quit dropandhop ("CGI:IRC") |
| 23:38:57 | | Join gromit` [0] (~gromit@ALagny-151-2-2-244.w82-121.abo.wanadoo.fr) |
| 23:38:57 | | Quit gromit``` (Read error: 104 (Connection reset by peer)) |
| 23:52:20 | | Join iRiverMan [0] (~acca5915@labb.contactor.se) |
| 23:52:26 | iRiverMan | hey people |
| 23:52:59 | iRiverMan | can someone help me regarding an iriver please? |
| 23:53:12 | | Quit Hadaka (No route to host) |
icon identifies that the person is a core developer (has commit access).