00:06:26 | | Quit Harpy (Read error: 110 (Connection timed out)) |
00:09:57 | | Join webguest87 [0] (~51429ed6@labb.contactor.se) |
00:10:09 | webguest87 | Hello all |
00:10:17 | Bagder | hi |
00:11:08 | webguest87 | a quick question for the Bagder administrator :) |
00:12:04 | webguest87 | why in the CVS buil table, the 2 colums of the Gmini port still apear ? |
00:12:19 | Bagder | because the columns are based on more data than what is shown |
00:12:21 | webguest87 | i know it's not important |
00:12:52 | webguest87 | are will always here? |
00:12:56 | Bagder | no |
00:13:19 | webguest87 | i know this port is in "stand by" |
00:14:25 | Bagder | I would call it abandoned |
00:14:48 | webguest87 | :) anyone worked on it since long time? |
00:14:55 | Bagder | nope |
00:15:00 | Bagder | been months since |
00:15:10 | webguest87 | ok |
00:15:31 | webguest87 | there was just one dev worked on it? |
00:15:38 | Bagder | yes |
00:16:08 | webguest87 | difficult to port Rockbox alone, no? |
00:16:20 | Bagder | his computer broke down |
00:16:28 | webguest87 | :( |
00:16:31 | Bagder | and he couldn't afford a new one |
00:16:48 | webguest87 | not good for him |
00:17:09 | webguest87 | personaly i'm iriver user |
00:17:21 | webguest87 | one very happy user :) |
00:17:25 | Bagder | :-) |
00:18:18 | webguest87 | i read in the logs of today maybe Slasheri'll go to imlement paek meter things |
00:18:27 | webguest87 | it's very good |
00:18:44 | webguest87 | *peak |
00:19:31 | webguest87 | i love your Rockbox fw :) |
00:19:40 | Bagder | thanks |
00:20:25 | webguest87 | and i love his "association" with the GPL concept |
00:20:45 | webguest87 | not money way |
00:20:54 | webguest87 | and free to code |
00:22:39 | webguest87 | Bagder: think you in the futur (soon i hope), it'll be possible to have got a beep option like the original fw or most of music players? |
00:22:52 | webguest87 | it's not a request just question :) |
00:23:00 | Bagder | what would that do? |
00:23:17 | Bagder | I mean, when would it beep? |
00:23:28 | Bagder | but yes, surely we can make it beep |
00:23:39 | webguest87 | when pushed a key |
00:23:57 | Bagder | oh |
00:24:08 | Bagder | I always disable such stuff |
00:24:13 | webguest87 | like mostly player music |
00:24:14 | Bagder | on every device I own |
00:24:44 | webguest87 | you don't like it? |
00:25:03 | Bagder | I hate it |
00:25:22 | webguest87 | :), scuse for this evocation in your brain :) |
00:25:26 | Bagder | hehe |
00:25:35 | Bagder | well, that's what options are for |
00:25:52 | webguest87 | but it be very usual for lot of people i assume |
00:26:01 | webguest87 | true |
00:26:24 | webguest87 | think you it'll be dificult to add to options? |
00:27:08 | Bagder | I would guess that the most difficult part is to find someone who'll write the code for the feature |
00:27:58 | webguest87 | yes i assume, just if one dev work on it, needed lot of codes? |
00:28:08 | webguest87 | lot of time? |
00:28:16 | webguest87 | for him |
00:28:31 | Bagder | that would depend on the coder of course |
00:28:40 | webguest87 | :) of course |
00:29:24 | webguest87 | for example, you, you are an experimented hackers |
00:29:37 | Bagder | no, it would not take very long |
00:30:45 | Bagder | sleep time |
00:30:58 | webguest87 | have a good night |
00:31:40 | webguest87 | thanks for your answers |
00:32:44 | webguest87 | good night to all too :) |
00:32:48 | | Quit webguest87 ("CGI:IRC") |
00:34:35 | | Quit matsl (Remote closed the connection) |
00:37:55 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
01:00 |
01:01:45 | | Join CBM-away [0] (~youshould@tc2-225-085.altelco.net) |
01:09:12 | *** | Saving seen data "./dancer.seen" |
01:37:48 | XavierGr | when a static variable is declared on a a1.c file does it get recognised if called by a a2.c file (included the a1.h)? |
01:39:04 | XavierGr | also if someone could tell me where the tree initialization occurs when running rockbox I would be obligued |
02:00 |
02:26:01 | | Quit matsl (Remote closed the connection) |
02:32:02 | | Quit Moos (" Like VS.net's GUI? Then try HydraIRC -> http://www.hydrairc.com <-") |
02:41:10 | XavierGr | good night all! I have to sleep! |
02:41:13 | | Quit XavierGr () |
03:00 |
03:07:53 | | Quit Sucka ("a bird in the bush is worth two in your house") |
03:09:16 | *** | Saving seen data "./dancer.seen" |
03:10:21 | | Join textchimp [0] (~chimp@ip67.net66.ipnetworks.net.au) |
03:15:20 | | Join ashridah [0] (ashridah@220-253-123-31.VIC.netspace.net.au) |
03:28:29 | | Quit Coldtoast (Read error: 110 (Connection timed out)) |
03:54:14 | | Quit hicks (Remote closed the connection) |
03:54:40 | | Quit cYmen_ ("zZz") |
03:57:39 | | Nick CBM-away is now known as CheeseBurgerMan (~youshould@tc2-225-085.altelco.net) |
04:00 |
04:05:34 | | Join QT_ [0] (as@area51.users.madwifi) |
04:16:03 | | Quit QT (Read error: 110 (Connection timed out)) |
04:16:03 | | Quit textchimp (Read error: 104 (Connection reset by peer)) |
04:24:02 | | Quit CheeseBurgerMan () |
04:24:35 | | Join CheeseBurgerMan [0] (~youshould@tc2-225-085.altelco.net) |
04:43:05 | | Nick CheeseBurgerMan is now known as CBM (~youshould@tc2-225-085.altelco.net) |
05:00 |
05:09:18 | *** | Saving seen data "./dancer.seen" |
05:24:56 | | Nick CBM is now known as CheeseBurgerMan (~youshould@tc2-225-085.altelco.net) |
05:33:37 | | Nick CheeseBurgerMan is now known as CBM-AFK (~youshould@tc2-225-085.altelco.net) |
05:36:28 | | Nick CBM-AFK is now known as CheeseBurgerMan (~youshould@tc2-225-085.altelco.net) |
07:00 |
07:09:20 | *** | No seen item changed, no save performed. |
08:00 |
08:19:41 | | Quit pike (Read error: 110 (Connection timed out)) |
08:27:59 | | Join pilled [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) |
08:37:53 | | Quit pill (Read error: 110 (Connection timed out)) |
08:37:53 | | Nick pilled is now known as pill (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) |
08:52:39 | | Join Coldtoast [0] (~edan@ppp111-3.lns1.hba1.internode.on.net) |
08:53:59 | | Nick CheeseBurgerMan is now known as CBM-away (~youshould@tc2-225-085.altelco.net) |
09:00 |
09:09:24 | *** | Saving seen data "./dancer.seen" |
09:35:25 | | Join pike [0] (pike@c83-249-120-126.bredband.comhem.se) |
09:42:30 | | Join Harpy [0] (LiZ63v73tt@dsl-hkigw7wbb.dial.inet.fi) |
11:00 |
11:05:32 | | Join Lear [0] (~chatzilla@h143n1c1o285.bredband.skanova.com) |
11:09:28 | *** | No seen item changed, no save performed. |
11:09:40 | | Quit edx () |
11:13:28 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
11:24:23 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
11:30:47 | | Join edx [0] (edx@p54A8F533.dip.t-dialin.net) |
11:31:10 | | Quit cYmen (Read error: 104 (Connection reset by peer)) |
11:31:13 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
11:37:34 | Slasheri | Hmm, my current implementation of the peak meter looks more like a spectrum meter.. |
11:38:28 | Lear | Too fast? |
11:39:38 | Slasheri | nope, it meters one fixed frequency.. Maybe something like 4 kHz |
11:39:50 | Slasheri | i will try to fix that |
11:40:01 | Slasheri | for example it igrones bass totally |
11:40:34 | Lear | Aren't you just looking at peak sample values? |
11:41:10 | Slasheri | hmm, we dont have peak values but we have to calculate tehm? |
11:41:54 | | Quit cYmen (Read error: 104 (Connection reset by peer)) |
11:41:54 | Lear | How else would you do it? |
11:43:19 | Slasheri | Hmm.. currently i try to find min and max sample values between a specified period and then calculate average peak value for a longer period |
11:45:39 | Lear | Doesn't the peak meter do some averaging as well? |
11:45:51 | Slasheri | maybe i should first find the bias value and then base the peak readings on that |
11:46:00 | Slasheri | then it might work better |
11:46:39 | Slasheri | maybe, but it takes samples only ~20 times per second |
11:46:53 | Slasheri | so we have to calculate some average also |
11:49:42 | Slasheri | current implementation works well for higher frequencies but its more an eq analyzer than a peak meter |
11:50:06 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
11:50:15 | Slasheri | i will try that different bias thing when i get to home |
12:00 |
12:07:23 | | Quit Seed (Nick collision from services.) |
12:07:30 | | Join Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il) |
12:25:03 | | Join LinusN [0] (~linus@labb.contactor.se) |
12:29:35 | | Join austriancoder [0] (~5078751e@labb.contactor.se) |
12:29:41 | austriancoder | hi |
12:29:47 | LinusN | hi |
12:48:05 | | Join Moos [0] (DrMoos@m29.net81-66-158.noos.fr) |
12:48:18 | Moos | Good Day all |
12:48:46 | austriancoder | hi |
12:50:39 | austriancoder | LinusN: we should maybe rename i2c-h100 to i2c-coldfire? |
12:53:14 | LinusN | one of those days, yes |
12:54:38 | Moos | Hmm, anyone of you 2, planed to improve the i2c patch? :) |
12:54:50 | LinusN | one of those days, yes :-) |
12:54:55 | austriancoder | g |
12:55:00 | Moos | :) |
12:55:17 | austriancoder | if i have the bdm in my hands and got it wokring |
12:55:51 | LinusN | really? cool! |
12:56:09 | LinusN | was it hard to find out where to connect it? |
12:56:34 | LinusN | oh... "if i"... :-) |
12:56:44 | Moos | :) |
12:56:53 | * | LinusN cleans his glasses |
12:57:08 | austriancoder | jep.. i am looking where to connect the bdm today |
13:00 |
13:01:22 | LinusN | should be pretty straightforward, as the cpu pins are visible |
13:02:29 | austriancoder | i hope that the palces to connect are marked |
13:03:58 | LinusN | you still haven't scanned the pcb's? |
13:05:04 | LinusN | reboot, brb |
13:05:07 | | Part LinusN |
13:06:41 | Lear | Interesting... At least since September, the ID3 screen hasn't shown all information. Doesn't anyone use it? :) |
13:07:08 | | Join LinusN [0] (~linus@labb.contactor.se) |
13:07:58 | austriancoder | i have scanned it, but as the pcb is not laying straight on the scanner it gets blurred |
13:08:03 | Moos | Lear: all informations? |
13:08:18 | LinusN | austriancoder: aha |
13:08:31 | Lear | Yeah, some info, like bitrate, frequency and path aren't possible to display. |
13:08:48 | Moos | i see it |
13:09:05 | austriancoder | LinusN: i must look if i could get better results |
13:09:21 | LinusN | would be good, as we all could see the pcb's |
13:09:30 | *** | Saving seen data "./dancer.seen" |
13:10:16 | | Part LinusN |
13:11:28 | | Join LinusN [0] (~linus@labb.contactor.se) |
13:11:33 | austriancoder | and everybody could help to find the bdm connectors ;) |
13:11:45 | LinusN | yup |
13:12:52 | austriancoder | its time to setup my whole laptop as linux-only-zone |
13:13:34 | austriancoder | time to go |
13:13:36 | austriancoder | see you |
13:13:40 | | Quit austriancoder ("CGI:IRC 0.5.4 (2004/01/29)") |
13:14:09 | | Part LinusN |
13:14:18 | | Quit edx (Read error: 110 (Connection timed out)) |
13:15:37 | | Join LinusN [0] (~linus@labb.contactor.se) |
13:19:59 | | Part LinusN |
13:21:17 | | Join LinusN [0] (~linus@labb.contactor.se) |
13:22:02 | | Join hicks [0] (~hicks@zeus.mups.co.uk) |
13:28:47 | | Nick Febs is now known as Febs_away (~chatzilla@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) |
13:32:56 | | Join Tangleding [0] (~Tangledin@ARennes-351-1-25-19.w82-126.abo.wanadoo.fr) |
13:34:03 | Moos | Hi crazy Tang |
13:34:53 | Tangleding | Hi Moos |
13:34:55 | Tangleding | :) |
13:35:04 | Tangleding | Back to Brest finaly |
13:35:12 | Moos | déjà? |
13:35:20 | Moos | pv |
13:36:00 | Tangleding | okay |
13:38:23 | | Join ghostiger [0] (~ghostiger@13e7c2047dcb9e70.session.tor) |
13:51:11 | Tangleding | hello Rbx :) |
13:51:26 | Tangleding | A x |
13:51:37 | Tangleding | I wasn't on IRC chan for a while |
14:00 |
14:00:06 | Tangleding | Congrate for latest progresses... |
14:00:08 | Tangleding | :) |
14:00:13 | Tangleding | Very good work |
14:00:16 | Tangleding | :) |
14:00:50 | Tangleding | just waiting for remote displaying patch to be comitted in CVS |
14:01:03 | Tangleding | then i'll leave original iRiver fw :) |
14:01:05 | Tangleding | bye |
14:05:04 | | Quit ghostiger ("Leaving") |
14:18:59 | | Part LinusN |
14:26:25 | | Join LinusN [0] (~linus@labb.contactor.se) |
14:28:01 | Tangleding | hi linus |
14:28:07 | Tangleding | how are you? |
14:28:09 | Tangleding | :) |
14:30:48 | LinusN | fine i guess |
14:37:06 | Tangleding | :) |
14:37:11 | Tangleding | nice |
14:37:28 | Tangleding | want to gongrate you |
14:37:38 | Tangleding | for the H110 bootloader |
14:37:40 | Tangleding | :) |
14:37:52 | Tangleding | very nice work |
14:39:20 | LinusN | thx |
14:56:05 | | Join edx [0] (edx@p54A8EB53.dip.t-dialin.net) |
15:00 |
15:00:07 | Tangleding | :) |
15:00:16 | Tangleding | Okay i've to go |
15:00:41 | Tangleding | i will make a donation at spetember/october |
15:00:52 | LinusN | wee! thx |
15:00:54 | Tangleding | since i've suceeded in my exam |
15:01:11 | Tangleding | and i'll work now and get payd |
15:01:12 | Tangleding | :) |
15:02:43 | Tangleding | Cheers :) |
15:03:52 | | Quit Tangleding ("Chatzilla 0.9.68a [Firefox 1.0.4/20050511]") |
15:09:31 | *** | Saving seen data "./dancer.seen" |
15:40:09 | | Quit cYmen (Read error: 104 (Connection reset by peer)) |
15:40:40 | | Join firefox_i686 [0] (~firefox_i@AToulouse-152-1-51-230.w82-125.abo.wanadoo.fr) |
15:44:38 | | Part firefox_i686 ("faites vous plaisir -----> www.linuxiso.org") |
15:56:23 | | Quit matsl (Remote closed the connection) |
15:56:24 | | Quit Coldtoast (Read error: 104 (Connection reset by peer)) |
15:59:51 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
16:00 |
16:00:48 | | Join Coldtoast [0] (~edan@ppp111-3.lns1.hba1.internode.on.net) |
16:05:50 | | Quit matsl (Remote closed the connection) |
16:08:28 | | Join cYmen_ [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
16:13:10 | | Join asdsd____ [0] (~asdsd@h-67-100-24-142.miatflad.dynamic.covad.net) |
16:14:44 | | Part asdsd____ |
16:35:20 | | Quit ashridah ("Leaving") |
17:00 |
17:01:24 | | Join BBub_ [0] (belzebub16@dsl-082-082-243-103.arcor-ip.net) |
17:02:40 | Slasheri | Hmm, if you find any bugs with playback, please tell me as soon as possible. I am only few days here and then month away |
17:06:46 | Lear | Slasheri: the end of each track seem to be trimmed by a few seconds... |
17:06:46 | crwl | only three weeks away ;) |
17:07:24 | Slasheri | crwl :) |
17:07:33 | Slasheri | Lear: Hmm, with any codec or mp3 only? |
17:08:29 | Slasheri | i think this is mp3 problem.. |
17:09:34 | *** | Saving seen data "./dancer.seen" |
17:10:41 | Lear | I mainly play MP3, but I've notived it for oggs as well, when testing the resampler. It started happening within the last couple of days or so... |
17:11:50 | Slasheri | LinusN: btw, the optical out is working with current builds. Beam is only lower intensity while not playing anything |
17:12:20 | Slasheri | Lear: oh, i will check that |
17:12:20 | LinusN | i assumed he meant while playing |
17:12:29 | Slasheri | weird |
17:12:44 | LinusN | afaik, it's been working for quite some time |
17:14:30 | Slasheri | Lear: thanks, there is something wrong, ogg playback was not gapless when i just tried with a sine wave |
17:15:45 | Lear | Good, easy to reproduce. :) Crossfade was off when I noticed it, btw. |
17:18:08 | | Quit BBub (Read error: 110 (Connection timed out)) |
17:18:08 | | Nick BBub_ is now known as BBub (belzebub16@dsl-082-082-243-103.arcor-ip.net) |
17:23:44 | Slasheri | Lear: that was easy to fix, i will commit soon :) |
17:26:52 | Coldtoast | about 3 days ago I was listenign to tracks and instead of tracks crossfading, I got the start of the next song, a burst of the last song then the rest of the next song. Ithink it was after buffering then changing to a different dir, listening for a few secs then skipping to the next track |
17:27:29 | Coldtoast | so kind of a "worst case scenario" for playback |
17:27:50 | Moos | i experimented this too few days ago :( |
17:28:02 | crwl | i've got stuff like that too, and i don't use crossfading |
17:28:03 | Coldtoast | once it buffered again tho, it was fine |
17:28:33 | crwl | not buffering enough initially or something (this only happens sometimes when changing tracks to something that isn't buffered yet) |
17:33:32 | BBub | Slasheri: i found a problem on flac, latest build, it makes a short noise on the beginning of a track |
17:33:37 | | Join XavierGr [0] (~XavierGr@ppp49-adsl-96.ath.forthnet.gr) |
17:33:45 | BBub | maybe its the tag as rockbox doesnt read it |
17:34:00 | Slasheri | BBub: Hmm, i will try that too |
17:34:05 | Coldtoast | heh. I've queued every single MP3 I have in Winamp then enabled Shuffle and now listening to tracks I've never even heard before |
17:34:42 | BBub | thx Slasheri ;) |
17:49:21 | * | LinusN cut the lcd updating time from 1.8ms to 1ms |
17:49:42 | LinusN | in 120mhz |
17:53:18 | LinusN | and from 3ms to 2.5ms in 48mhz |
17:54:55 | | Join Tangleding [0] (~Tangledin@ARennes-351-1-29-158.w82-126.abo.wanadoo.fr) |
17:55:15 | Tangleding | Is there slashery? |
17:55:26 | Tangleding | slasheri sorry |
17:55:52 | Tangleding | ? |
17:56:24 | Slasheri | Tangleding: hi, yes i am :) |
17:56:31 | Tangleding | Hello |
17:56:33 | Tangleding | :) |
17:56:36 | Tangleding | How are you? |
17:56:38 | Tangleding | :) |
17:57:22 | Slasheri | fine thx ;) just trying to catch the last bugs before i leave for few weeks :) |
17:57:28 | Tangleding | :) |
17:57:29 | Tangleding | nice |
17:57:37 | Tangleding | about the gapless fix |
17:57:40 | Tangleding | precisely |
17:57:48 | Tangleding | it's conceerning ogg i guess? |
17:57:56 | Tangleding | no lame? |
17:59:24 | Slasheri | all codecs had the problem, but it doesn't mean lame would be totally gapless now |
17:59:50 | Slasheri | at least other codecs should be true gapless |
18:00 |
18:00:01 | Tangleding | ah okay |
18:00:26 | Tangleding | lame is really diffrent from others concerning gapless issue? |
18:00:55 | Slasheri | yes it's because mp3s are not designe to be gapless.. |
18:01:58 | Tangleding | in fact i've discussed with Gabriel Bouvigne |
18:02:09 | Tangleding | (a Lame developer) |
18:02:19 | Tangleding | and according to him |
18:02:33 | Tangleding | the mainly différence was a "standadisation" one |
18:02:36 | Lear | LAME-encoded stuff can be gapless, but it is something tacked on later. |
18:02:48 | Tangleding | since there are many encoders |
18:02:58 | Tangleding | unlike Vorbis for exemple |
18:03:38 | Tangleding | he told me that thje vorbis gapless feature was using same method thanrecent lame (with fixed delay) |
18:03:43 | XavierGr | so its pretty much impossible to see gapless to non-lame mp3s right? |
18:03:56 | Tangleding | i guess so |
18:04:01 | Tangleding | would be necessary |
18:04:23 | Tangleding | to set the delay according to each encoder |
18:04:27 | Slasheri | XavierGr: we may have the dsp to detect and cut silence in future |
18:04:36 | XavierGr | :) |
18:04:39 | Lear | Yes, because the decoder doesn't know how much the source was padded. Encoder delay isn't fixed either. |
18:05:01 | Tangleding | oit's fixed for lame anyway |
18:05:20 | Tangleding | have you got contact with some of the lame developers? |
18:06:02 | Lear | Problem is, how to not detect/cut silence not at the very end... |
18:08:00 | XavierGr | LinusN: Do you happen to from where the tree.c code is executed? I found the tree_init function called by main.c but this isnt most likely |
18:08:13 | XavierGr | ^happen to know |
18:08:17 | Tangleding | A cool feature about silence remover |
18:08:38 | Tangleding | should allow to detect long silence not only at the file end |
18:08:49 | Tangleding | (for kinda bonus track ;) ) |
18:09:00 | LinusN | XavierGr: app_main() calls init() and then browse_root() |
18:09:30 | XavierGr | thanks |
18:11:28 | XavierGr | so if I make a remote-tree.c identical to tree.c (cahnged lcd_ functions to remote_lcd) and call remote_tree_init() and remote_browse_root() (changed respectively) I can get the remote working right? (then toss up the clutter code) |
18:12:56 | Lear | Except having two browsers active at the same time sounds like a bad idea... The remote should mirror a clipped version of the main display, IMO. |
18:13:37 | LinusN | Lear: agreed |
18:14:24 | | Quit CBM-away (Read error: 54 (Connection reset by peer)) |
18:14:27 | XavierGr | Well amiconn suggested that we use a saperate thread for each. Like creating remote-tree.c remote-wps-display.c e.t.c |
18:14:39 | Tangleding | how do the iRiver fw proceeds? |
18:15:28 | Lear | That might work, but it could also be confusing (for the user), and wouldn't there be synchronization issues? |
18:18:11 | XavierGr | well I started a quick hack by replicating every lcd_ function to lcd_remote in the tree.c but encountered a dead end. Where a a function returns the height of the screen. I cant find a way to return 2 values, 1 for the main unit and for the remote. So I thought a different .c file would be better. |
18:18:59 | XavierGr | what do you suggest? |
18:19:38 | Lear | what functions do you refer to? |
18:19:58 | XavierGr | you mean the lcd_ ones? |
18:20:15 | XavierGr | or the replicate_height()? |
18:20:42 | Lear | the ones you had problems with |
18:23:13 | XavierGr | in tree.c line 239 recalc_screen_height. int height, is returned with the height value of the screen (LCD_HEIGHT) but then the remote screen isnt displayed correctly (text is hidden in the bottom part) |
18:23:14 | Lear | hm... separating tree into a model and a view sounds like one way of doing it. I.e., tree (and also the wps) maintains a model over what to display, then call on functions to draw that model, once for the main display, and once for the remote, if present. |
18:24:28 | XavierGr | so if I change height = REMOTE_LCD_SCREEN the remote is displayed correctly but the main is not |
18:24:32 | Lear | yes, you need to maintain two values (using arguments to return the value or indicate what you want, different functions,etc) |
18:26:03 | XavierGr | so what to do. 1.replicate and adjust 2.make another file for the remote |
18:26:40 | Lear | 3. split out the rendering code into two cases, main and remote |
18:27:15 | XavierGr | in the same tree.c? |
18:27:40 | Lear | could be, but that isn't a requirement... |
18:28:03 | Lear | the point is to logically separate the rendering from the rest. |
18:28:54 | XavierGr | a complete rewrite as I see it... I will have to understand each and every line of the code... and I am newb. nevertheless i will try. |
18:30:01 | Lear | no, not a complete rewrite. Lots of restructuring, yes... |
18:30:57 | XavierGr | to rewrite tree.c for the screen height is tricky though. I tried many times but the rendering functions must be run twice for every display. |
18:32:11 | Lear | no, once per display should be enough. :) |
18:32:38 | XavierGr | yeah my bad I meant twice, once for each display |
18:33:21 | Lear | but there is no other way, because the screens need to be rendered differently. |
18:34:06 | Lear | and the easy way to handle that is to put the rendering in separate functions. |
18:34:52 | XavierGr | though amiconn said clearly to me to make a different thread, not just a quick replicate hack, but then I will have to make a huge restructural work in order not to duplicate unnecessary code... |
18:35:53 | XavierGr | so I could make a remote-tree.c which has the rendering functions for the remote and then call them from the tree.c if there is a remote? |
18:35:59 | Lear | personally, I don't see the need for a separate thread... I guess the restructuring needed is why nobody has cared enough just yet. :) |
18:36:38 | XavierGr | LinusN: What do you think? |
18:36:55 | Lear | yes, something like that. Only I'd always call them, and let them return immediately if there is no remote. |
18:37:43 | LinusN | XavierGr: i agree with Lear |
18:38:32 | XavierGr | but what if the code in tree.c is not saperated with rendering/setup functions. It is most likely that they are mixed up. |
18:39:08 | XavierGr | I will have to dig up a little to be sure |
18:39:18 | Lear | the code sure isn't separated today, but it needs to be... |
18:40:43 | XavierGr | Pitty because I quite sure that I will have troubles to saperate them or even likely to understand them... |
18:41:06 | Lear | to a large degree, I think what is needed is a "render list" function, that based on the loaded directory, cursor position and an internal state (the top line) draws that list. |
18:42:51 | XavierGr | god the remote thing is the only thing that keeps me away from using rockbox. I am dying to make something for it. |
18:44:03 | Lear | A few additional things are needed though,e.g., the "create playlist" splash. Some could problably be made with splash() (which perhaps also should know how to handle an additional display). |
18:44:57 | XavierGr | another question: a static is seen without change in a single .c file, right? What if I want to use a static variable from another file? |
18:45:28 | Lear | I'd start by going through all rendering (lcd calls) and try to group them logically. As in, render tree, create playlist... |
18:46:56 | XavierGr | truth is that not all functions in tree.c has and lcd rendering function. |
18:46:59 | Lear | A static is only visible within that module, yes. If you want access from another file, use accessor functions. dsp_stereo_mode() is a good example. It returns the current stereo mode, which is maintained within dsp.c. |
18:47:28 | Lear | well, then perhaps they don't need to be changed at all? |
18:47:44 | XavierGr | but it has some huge ones that do many things. |
18:47:50 | Lear | i.e., there's no rendering to break out. |
18:48:10 | XavierGr | also they counter react with other files for various tasks. |
18:48:43 | Lear | but those things can be grouped into a limited number of "functions"... |
18:49:57 | XavierGr | 7 functions have at least one lcd rendering function |
18:50:33 | XavierGr | and dirbrowse is HUGE also there are alot of ifdes which need to be removed for the remote. |
18:52:42 | Lear | But most of that is non-render logic, afaict. The "model" part I mentioned before. |
18:54:28 | XavierGr | how can I return 2 values from a function? Maybe as a void functions which alters 2 static values? |
18:55:48 | Lear | on a tangent, shouldn't the lcd_puts_scroll code be common to all targets? And wasn't it, once upon a time... :) |
18:56:14 | Lear | pass in a pointer, and set the value through that pointer, |
18:57:40 | Lear | see e.g. get_tag, it sets flags that way |
18:57:51 | Lear | (in wps-display.c, that is) |
18:59:15 | XavierGr | ok thanks. I will think of this a little bit and I will see what I can do... |
19:00 |
19:03:12 | XavierGr | so Slasheri are you going on vacation? |
19:08:11 | | Join Sucka [0] (~NNSCRIPT@host81-156-157-175.range81-156.btcentralplus.com) |
19:09:37 | *** | Saving seen data "./dancer.seen" |
19:12:44 | Slasheri | XavierGr: no.. i have to go to the mandatory (civil) military service.. :D |
19:15:03 | XavierGr | for how long? |
19:16:30 | Slasheri | 13 months and one month (3 weeks in fact) without net access |
19:17:02 | Slasheri | but i can do other things during that 12 month period too :) |
19:17:30 | XavierGr | so we will see you again after 13 months!!!!! |
19:17:43 | Slasheri | hehe :D |
19:17:52 | XavierGr | we will surely miss you.... :( |
19:18:00 | Slasheri | after one month could be more realistic i hope ;) |
19:18:28 | XavierGr | but you said 12 months? |
19:18:41 | Slasheri | yes, the service lasts 13 months |
19:19:01 | XavierGr | you will have some breaks? |
19:19:06 | Slasheri | but during that last 12 month period i have the net access and can do other things too if i have time :) |
19:19:09 | XavierGr | ^brakes |
19:19:22 | thegeek | do as I did |
19:19:24 | thegeek | get lucky |
19:19:29 | thegeek | and get out after 7 months |
19:19:33 | Slasheri | hmm :D |
19:19:40 | thegeek | because of bad economy |
19:19:47 | thegeek | they just had to dump some of us |
19:19:47 | Slasheri | hehe, nice ;D |
19:19:50 | XavierGr | how old are Slasheri? |
19:19:51 | thegeek | indeed:) |
19:19:55 | Slasheri | XavierGr: 20 :) |
19:20:24 | XavierGr | and going to military so soon? I am 21 and I will go in 2011! |
19:20:48 | Slasheri | oh :) i just wanted to go there as soon as possible.. then i don't need to worry about it later :) |
19:20:49 | Ismo | Slasheri: inspired by your latest commit I browsed the playback.c a bit. Is the line 1349 correct or should there be some if statement before that? |
19:21:04 | Slasheri | Ismo: Hmm, i will check that |
19:21:59 | Ismo | I haven't looked how the pcm stuff works, but that line looks like a bit too alone :) |
19:22:01 | Slasheri | Ismo: yes, that's correct. If we were filling the buffer, AUDIO_PLAY event will start the crossfade |
19:22:08 | Slasheri | and if not, then it's started there |
19:22:16 | Slasheri | :D |
19:22:19 | Ismo | ok |
19:22:21 | Ismo | :) |
19:23:03 | Slasheri | in fact codec_track_changed() could be on that statement too but it's outside it because in every case we want to update the wps immediately |
19:23:33 | XavierGr | and what country are you from Slasheri? |
19:23:41 | Slasheri | XavierGr: from Finland :) |
19:24:00 | XavierGr | I thought that is was voluntarily there. |
19:24:19 | Slasheri | this is the about only EU country that still has mandatory mil service.. :/ |
19:24:36 | thegeek | hey! |
19:24:37 | XavierGr | well count Greece in that too |
19:24:39 | thegeek | dont forget norway |
19:24:42 | thegeek | or sweden |
19:24:45 | XavierGr | haha |
19:24:45 | thegeek | oh |
19:24:46 | thegeek | eu |
19:24:47 | thegeek | oh well |
19:24:48 | Slasheri | :D |
19:24:50 | thegeek | sweden then |
19:25:26 | XavierGr | its 12 months (i think) mandatory here too. |
19:25:55 | XavierGr | I remember the elders calling 36 months in the military! :x |
19:27:10 | Slasheri | huh, that's sick :D |
19:28:16 | XavierGr | indeed! |
19:30:50 | | Join Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com) |
19:33:42 | Stryke` | small bug report: the patch that was added to stop scrolling at the bottom of a list when holding it down does not work in the Debug menu |
19:34:41 | LinusN | Stryke`: iirc, that patch was only for the browser, not for menus |
19:35:19 | Stryke` | oh, any reason it would not be applied there? |
19:35:53 | LinusN | no particular reason |
19:36:19 | | Join stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk) |
19:42:35 | stripwax | ello |
19:43:17 | XavierGr | hi stripwax! |
19:43:39 | crashd | feh |
19:43:45 | crashd | anyone in london fancy a beer ? |
19:44:15 | stripwax | crashd - i'd love one, but I've just got back from a four hour drive from the midlands .. way too hot to do anything right now |
19:44:26 | stripwax | XavierGr - hey dude |
19:44:26 | crashd | :\ |
19:44:30 | crashd | hehe |
19:44:41 | crashd | im sunburnt from sitting up on hampstead heath yesterday |
19:44:59 | stripwax | crashd hehe. i'm sunburnt from driving round back from the midlands! ;-D |
19:45:04 | crashd | : ) |
19:45:25 | | Join webguest72 [0] (~51429e1d@labb.contactor.se) |
19:45:33 | webguest72 | hello folks |
19:45:45 | webguest72 | a litle question please |
19:46:08 | stripwax | sure |
19:46:54 | * | stripwax slaps himself for running old plugins in rockbox sim and wondering why it kept crashing.. |
19:46:55 | webguest72 | there is a patch for i2c in the tracker, and apear anyone want to work on it, it's normal? :) |
19:47:10 | webguest72 | the FM it's very usual :) |
19:47:16 | stripwax | "usual" ? |
19:47:46 | webguest72 | "important" for much people |
19:48:13 | webguest72 | Linus? |
19:48:21 | webguest72 | it's not in your plan? |
19:48:51 | webguest72 | Linus: i'm sure you can do it easyly,no? |
19:49:16 | webguest72 | no? |
19:50:35 | webguest72 | Linus:i noticed in the log that you have adapted the code a bit for i2c for irivers, have you planed something please? :) |
19:51:44 | stripwax | webguest72 - which patch are you referring to? |
19:52:16 | | Quit webguest72 ("CGI:IRC (EOF)") |
19:52:26 | | Join webguest72 [0] (~51429e1d@labb.contactor.se) |
19:52:37 | webguest72 | this: http://sourceforge.net/tracker/index.php?func=detail&aid=1232476&group_id=44306&atid=439120 |
19:53:18 | | Quit west-acre ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") |
19:53:24 | stripwax | webguest72 - you'll have to ask ac about that one... |
19:53:32 | | Join solex_ [0] (~jrschulz@d127233.adsl.hansenet.de) |
19:53:56 | webguest72 | but he deserted this because he working in iaudio now |
19:54:08 | webguest72 | and alone Linus can help us |
19:54:41 | | Join bagawk [0] (~lee@bagawk.user) |
19:54:45 | webguest72 | Linus: nope? |
19:54:58 | LinusN | huh? |
19:55:23 | LinusN | i optimized the i2c bit rate |
19:55:45 | webguest72 | have you planed to aplly the ac patch? |
19:55:57 | LinusN | yes |
19:56:06 | webguest72 | wonderfull :) |
19:56:21 | webguest72 | it's easy for you, no? |
19:56:34 | LinusN | what do you mean? |
19:57:16 | webguest72 | it's more easy for you to do this work than one other dev, because Rockbox is your baby, no? |
19:57:29 | webguest72 | :) |
19:57:38 | LinusN | hehe, rockbox is our baby, not mine |
19:57:43 | webguest72 | :D |
19:57:44 | Coldtoast | it's open source so many ppl have written code for it |
19:57:44 | stripwax | webguest72 - any of the devs could apply ac's patch, i expect |
19:57:57 | Coldtoast | it's not like LinusN could know ALL the code intimately |
19:58:30 | webguest72 | i just want to know he was the must experimented with it |
19:58:32 | webguest72 | ;) |
19:58:53 | LinusN | was that english? :-) |
19:59:00 | Coldtoast | haha |
19:59:19 | webguest72 | scuse me for my english :) |
19:59:32 | | Join spiralout [0] (~keep_goin@p54B38C70.dip0.t-ipconnect.de) |
19:59:34 | LinusN | since i have hooked up my logic analyzer, it feels natural to add the i2c reading, since i can easily verify it |
19:59:55 | webguest72 | ok |
19:59:56 | LinusN | right now i'm investigating the s/pdif output |
20:00 |
20:00:11 | stripwax | LinusN- neat - what's to investigate there? |
20:00:33 | LinusN | some people have problems with it, their dac refuses to play it |
20:01:28 | webguest72 | Linus: scuse me for this stupid questions and thanks, we hope you'll can add i2c things for FM soon if you can :) |
20:01:37 | LinusN | webguest72: don't worry |
20:01:58 | webguest72 | have a long life to Rockbox :) |
20:02:11 | webguest72 | bye all |
20:02:15 | | Quit webguest72 ("CGI:IRC") |
20:03:11 | LinusN | i have a theory why spdif doesnt work, but i don't have a toslink cable to test with :-) |
20:03:51 | LinusN | dinner time |
20:03:57 | LinusN | cu in a while |
20:04:10 | | Part LinusN |
20:04:11 | | Quit solex (Read error: 110 (Connection timed out)) |
20:09:05 | stripwax | Anyone want a patch for sokoban so it caches leveldata? |
20:11:20 | BBub | a small bug: on the h110 rockbox always shows 276mb of free space no matter how much space is really free |
20:11:51 | stripwax | hehe, neat! |
20:15:29 | stripwax | My sokoban cache patch is here - http://sourceforge.net/tracker/index.php?func=detail&aid=1239851&group_id=44306&atid=439120 |
20:25:29 | | Join hicks_ [0] (~hicks@zeus.mups.co.uk) |
20:40:25 | | Quit hicks (Read error: 110 (Connection timed out)) |
20:42:23 | | Quit Tangleding ("Chatzilla 0.9.68a [Firefox 1.0.4/20050511]") |
20:43:04 | | Join webguest80 [0] (~3e4f4094@labb.contactor.se) |
20:43:41 | HCl | hmm |
20:43:51 | webguest80 | BBub: What if you press the joystick while on the "Disk info: Free" screen? (this will rescan free space) |
20:43:52 | HCl | where's preglow when you need him |
20:44:02 | | Quit Maxime () |
20:44:35 | | Quit bagawk ("Leaving") |
20:46:52 | | Join muesli- [0] (muesli_tv@c-180-216-90.cvx-h.dial.de.ignite.net) |
20:48:24 | muesli- | re |
20:49:55 | XavierGr | re? |
20:50:32 | XavierGr | have to go see you all later! |
20:50:35 | | Quit XavierGr () |
20:51:37 | muesli- | dont you understand "re" !? |
20:52:39 | | Join Psy-Dead [0] (~nobby@cpc1-bele3-3-1-cust167.belf.cable.ntl.com) |
20:53:20 | Coldtoast | a lot of ppl don't understand anything less than a TLA |
20:57:13 | muesli- | tla? |
20:57:23 | | Quit Seed (Read error: 104 (Connection reset by peer)) |
20:57:27 | Coldtoast | Three Letter Abbreviation |
20:57:40 | muesli- | and ppl? |
20:57:44 | muesli- | people? |
20:57:50 | Coldtoast | yeah |
20:57:54 | muesli- | cheers |
20:57:57 | Coldtoast | heh |
20:57:58 | muesli- | mate |
20:58:17 | Coldtoast | you in the UK? or Australia? |
20:58:30 | muesli- | neither nor..germany ;) |
20:58:39 | muesli- | but have been in oz last year |
20:58:48 | Coldtoast | did you like it there? |
20:59:55 | muesli- | it was in october and exprected to be warm but it was lousy cold ;-) but oz is nice..wished to had more time |
20:59:56 | | Join Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il) |
21:00 |
21:00:48 | muesli- | are you from down under? |
21:01:57 | Coldtoast | I am |
21:02:04 | Coldtoast | where the heck WERE you in Australia? heh |
21:02:31 | muesli- | just in sydney to see the coat hanger (spelling!?) |
21:02:57 | muesli- | whats yr location? |
21:04:39 | | Join dj-death [0] (~user@djdeath.dyndns.org) |
21:04:42 | dj-death | Hi all |
21:04:54 | dj-death | I'm new to rockbox |
21:05:06 | Coldtoast | I'm actually in Tasmania |
21:05:07 | dj-death | I just got it on my iriver ihp120 |
21:05:19 | dj-death | it works great ;) |
21:05:44 | dj-death | and has some really cool feature |
21:06:12 | muesli- | tasmania sounded great by brochure. and where do you live most of the time? |
21:06:21 | | Join LinusN [0] (~linus@labb.contactor.se) |
21:09:02 | muesli- | high LinusN |
21:09:31 | LinusN | yo |
21:09:38 | *** | Saving seen data "./dancer.seen" |
21:10:43 | dj-death | has someone problem at the end of file when playing on iriver ? |
21:11:04 | LinusN | dj-death: try the latest bleeding edge |
21:11:34 | dj-death | I mean when listening a file (mp3/ogg) rockbox jump to the next track 2/3 seconds before the end of the current file |
21:11:50 | LinusN | yes, try the latest bleeding edge |
21:12:00 | dj-death | bleeding edge ? |
21:12:07 | dj-death | you mean daily build ? |
21:12:12 | LinusN | the very bottom of the daily build page |
21:12:28 | dj-death | ok |
21:12:29 | dj-death | thx |
21:13:03 | muesli- | http://www.rockbox.org/dl.cgi?bin=h120 |
21:13:09 | muesli- | isnt it this one? |
21:13:20 | Stryke` | those are daily builds |
21:13:39 | muesli- | where do i find the bleedings? |
21:13:41 | Stryke` | http://www.rockbox.org/auto/build-h120/rockbox.zip |
21:13:41 | Stryke` | thats bleeding edge |
21:13:50 | webguest80 | <LinusN> the very bottom of the daily build page |
21:14:10 | dj-death | ok upgrade done |
21:14:14 | dj-death | let's try |
21:14:38 | muesli- | http://www.rockbox.org/auto/build-h120/?C=S;O=D |
21:14:43 | muesli- | now its the upper one |
21:16:21 | dj-death | LinusN: works fine thx a lot |
21:16:31 | | Part dj-death ("bye") |
21:19:18 | Slasheri | LinusN: Hmm, would you like to look at the peak meter code if i commit it soon? at some degree it works but it has quite a strange behaviour |
21:19:52 | LinusN | Slasheri: strange? |
21:20:53 | Slasheri | i think the scaling might not be right and for some reason i have to "invert" the calculated average to get the right reading. You will find more from the code :) |
21:29:10 | Slasheri | LinusN: committed, please take a look if you have time |
21:29:16 | LinusN | ok |
21:29:41 | Slasheri | i really don't know how that peak average should be calculated so i just tried _something_ =) |
21:32:37 | | Quit crashd ("leaving") |
21:32:48 | | Join memmem [0] (~user@p54A23260.dip0.t-ipconnect.de) |
21:33:39 | | Join crashd [0] (nobody@badger.ing.me.uk) |
21:36:01 | Coldtoast | sorry dude. got distracted |
21:36:16 | Coldtoast | city called Launceston muesli- |
21:36:53 | muesli- | mmh..never heard of it..which state? |
21:37:21 | Coldtoast | Tasmania |
21:38:52 | muesli- | mmh..didnt made it far in the south.. |
21:38:55 | muesli- | next time ;) |
21:39:27 | Coldtoast | http://images.google.com.au/imgres?imgurl=http://www.kyne.com.au/~mark/photos/tasmania/launceston.jpg&imgrefurl=http://www.kyne.com.au/~mark/photos/tasmania/page2.php&h=600&w=800&sz=52&tbnid=zrZcGfiAE1oJ:&tbnh=106&tbnw=142&hl=en&start=3&prev=/images%3Fq%3Dlaunceston%2Btasmania%26svnum%3D10%26hl%3Den%26hs%3D9uY%26lr%3D%26safe%3Doff%26client%3Dfirefox-a%26rls%3Dorg.mozilla:en-US:official%26sa%3DN |
21:39:35 | HCl | what a horrid url |
21:39:42 | Coldtoast | http://www.kyne.com.au/~mark/photos/tasmania/launceston.jpg |
21:39:49 | Coldtoast | yeah. google link. sorry |
21:39:55 | Coldtoast | anyway. that's where I live |
21:40:14 | HCl | looks cloudy ;x |
21:40:18 | muesli- | :D |
21:40:29 | Coldtoast | heh. it is. especially in Winter |
21:40:38 | Coldtoast | blue skies in Summer tho |
21:43:49 | muesli- | yeah, gorgious nature..thats what i heard about tasmania |
21:43:58 | muesli- | g'Day HCl btw |
21:44:07 | HCl | evening |
21:44:22 | muesli- | gorgeous |
21:44:24 | muesli- | .. |
22:00 |
22:01:41 | muesli- | l8er mates |
22:05:57 | | Join Yasmine_ [0] (~GS3@AMarseille-252-1-48-136.w86-193.abo.wanadoo.fr) |
22:06:01 | | Part Yasmine_ |
22:17:34 | | Join ep0ch_ [0] (~ep0ch@81-6-218-35.gotadsl.co.uk) |
22:18:45 | ep0ch_ | hey, anyone else noticed that all of sudden 128 kbps mp3 is now realtime with no CPU boost? |
22:19:11 | ep0ch_ | i could swear it needed boost before... |
22:19:14 | Coldtoast | I have no 128kbit MP3s on mine, so no. But great to hear |
22:22:08 | stripwax | Slasheri - is that pcm peakmeter basically the same approach as I had or does it precalculate volume levels? |
22:22:53 | ep0ch_ | oh wierd *some* 128 kbps are realtime, and some arent. |
22:23:15 | | Join webguest04 [0] (~44e5eab9@labb.contactor.se) |
22:23:21 | | Quit webguest04 (Client Quit) |
22:23:57 | Slasheri | stripwax: hmm, it tries to calculate some average volume from one chunk of 512 bytes. But i don't even exactly know what it does ;) what kind of approach you have? |
22:24:41 | ep0ch_ | the peakmeter is wierd... even quiet parts of the music show full peak |
22:25:02 | Slasheri | yes, it's kind weird.. try using linear scale instead of logarithmic |
22:25:09 | | Quit muesli- (Read error: 110 (Connection timed out)) |
22:25:42 | ep0ch_ | Slasheri: oh thanks for all the recent playback fixes :) |
22:26:08 | Slasheri | np, one more fix is coming (i found just a bug in the playback code) |
22:26:36 | ep0ch_ | hmm i just changed to "linear" peakmeter and the music just hung :s |
22:26:44 | Slasheri | :/ |
22:26:58 | Slasheri | did it crash or just hung? |
22:27:09 | ep0ch_ | just got silence |
22:27:12 | ep0ch_ | no sound |
22:27:15 | Slasheri | ah.. |
22:27:39 | ep0ch_ | i'll try it again, see if it was the peakmeter |
22:28:37 | Slasheri | hmm, is the peak meter disabled if wps don't show it? i hope it is.. |
22:28:56 | ep0ch_ | nah i dont think it was changing the peakmeter that broke the sound.. did it again and it worked... |
22:29:46 | Slasheri | if you have logf enabled, take a dump and try to see what happened |
22:29:55 | Coldtoast | haha |
22:30:08 | ep0ch_ | not enabled |
22:30:13 | Slasheri | :/ |
22:30:21 | ep0ch_ | i'll try and reproduce |
22:30:49 | Coldtoast | sorry. telling him to "take a dump" is childishly amusing |
22:30:54 | ep0ch_ | heh |
22:30:59 | Slasheri | :D |
22:35:33 | stripwax | Slasheri - yes, that was my approach too but I remember Linus saying it was quite strange so I guess I thought an approved approach would have to be different ;-) |
22:36:01 | Slasheri | ah, interesting :) |
22:36:55 | stripwax | Slasheri - how do you work around something like SAR0 changing while you're reading the buffers? or the remaining buffer size being less than your averaging window? |
22:37:31 | stripwax | Slasheri - i think my patch was here http://www.beermex.com/@spc/vu.patch |
22:38:26 | ep0ch_ | so basically you average a block of samples, divide by the bit depth and mutiply by the number of pixels wide the peak meter is, or something? |
22:39:20 | stripwax | ep0ch_ - sort of, the recorder/peakmeter.c code just expects a number between 0 and 0x7fff |
22:39:41 | ep0ch_ | ok |
22:40:02 | stripwax | so yeah, we average a bunch of sample data, and obtain a left and right 'volume' value between 0 and 32767 |
22:40:32 | ep0ch_ | sample data is signed? |
22:41:20 | stripwax | ep0ch_ - would that make any difference? volume would still be between and 0 and 32767 |
22:41:54 | ep0ch_ | if you have sample values, -255 and 255 average is 0 |
22:42:01 | ep0ch_ | when it should really be 255 for the peakmeter |
22:42:11 | ep0ch_ | i.e. the average of 255 and 255 |
22:43:01 | ep0ch_ | so you should ignore the sign if sample data uses it? |
22:43:16 | ep0ch_ | bah i'll look at some C code and see if i understand it :) |
22:43:21 | stripwax | ep0ch_ - ah, understood. yes, to derive the sample data obviously we need to know what 'zero value' means. |
22:43:45 | stripwax | I think I assumed sample data was 16 bit signed in my code, dunno what Slasheri does |
22:44:45 | stripwax | Hmm - interesting, he's assuming sample data is unsigned, but only deriving a volume value from samples with value > 32768. weird? |
22:45:51 | ep0ch_ | well half the values wont be calculated then |
22:46:15 | stripwax | well, they'll be calculated but wrong ;-) |
22:46:43 | ep0ch_ | should average the whole lot and add 32768 to the total maybe |
22:46:47 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
22:46:58 | ep0ch_ | bah i dunno |
22:47:19 | stripwax | ep0ch_ no, don't add 32768 - just take absolute value of each sample, and average that. |
22:47:49 | ep0ch_ | oh yeah of course |
22:50:45 | ep0ch_ | bah playback just stopped again for no reason about 2/3 of the way through an MP3. i'll put logging on from now on |
22:51:07 | ep0ch_ | was quite enjoying the tune too ;) |
22:51:19 | stripwax | ooh, logging ? where/what's that? |
22:52:16 | Bagder | logf |
22:52:29 | Bagder | enable it with the configure script |
22:53:01 | * | stripwax never even knew. neat |
22:53:19 | Bagder | logs on the remote lcd |
22:53:33 | Bagder | and offers a "dump logf buffer" function |
22:53:45 | * | stripwax has no idea where his remote is .. :-( |
22:53:53 | ep0ch_ | i need the remote??? |
22:53:57 | Bagder | you can browse the log on the main unit too |
22:54:01 | ep0ch_ | mines still in pieces :s |
22:54:04 | Bagder | ep0ch_: only if you want to see the log live |
22:54:45 | ep0ch_ | if i want it on the main screen can i change the wps to display it? |
22:54:51 | stripwax | Bagder - ah, cool |
22:54:57 | Bagder | ep0ch_: no |
22:54:58 | ep0ch_ | theres plenty of space... |
22:55:00 | ep0ch_ | ah |
22:55:02 | | Join webguest69 [0] (~18d79b85@labb.contactor.se) |
22:55:15 | Bagder | ep0ch_: unless you add the code for it ;-) |
22:55:33 | ep0ch_ | give me a couple of years to get up to speed with rockbox code |
22:56:04 | Bagder | I'll expect your patch by noon tomorrow B-] |
22:56:19 | stripwax | heh heh |
22:56:28 | ep0ch_ | :) |
22:59:54 | ep0ch_ | stripwax: back to peakmeter, if the data is unsigned taking the average of absolute values is pointless |
23:00 |
23:01:11 | stripwax | ep0ch_ - audio data is 16 bit.... if data is unsigned then 'zero' is 32768. so subtract 32768. and then it becomes signed. so you need to take absolute values... |
23:01:12 | Lear | epoch_: pcm data is signed. |
23:01:31 | Lear | at least in the iRiver... :) |
23:01:32 | stripwax | (or, equivalently, invert data if sample is > 32768) |
23:02:23 | memmem | No, the result of inverting will be off by one. |
23:03:23 | stripwax | memmem - by invert I meant 65536-x |
23:03:24 | | Quit webguest69 ("CGI:IRC (EOF)") |
23:04:25 | memmem | OK, PCM data uses two's complement representation for negative numbers. |
23:04:45 | stripwax | i.e. signed shorts |
23:05:08 | stripwax | and not unsigned shorts, which is what Slasheri's pcm vu meter code seems to use.. |
23:05:25 | memmem | Signed shorts on architectures that use two's complement arithmetic ;-) |
23:05:36 | BBub | [20:43:54] <webguest80> BBub: What if you press the joystick while on the "Disk info: Free" screen? (this will rescan free space) <- that works |
23:05:52 | BBub | i thought it would do it by itself |
23:06:08 | Bagder | do what by itself? |
23:06:17 | BBub | refresh the free space |
23:06:22 | Bagder | why would it? |
23:06:31 | Bagder | it is time and battery consuming |
23:06:51 | BBub | i only assumed it because the original firmware does it |
23:07:05 | Bagder | I didn't even know it could do that ;-) |
23:07:14 | stripwax | BBub the original firmware loads the entire directory structure on startup, which is time and battery consuming ;-) |
23:08:12 | webguest80 | This is unrelated, I believe |
23:08:22 | stripwax | Bagder - how does rockbox fw know if/when file system changes have been made in usb mode |
23:08:24 | BBub | i dont really need it anyways ;) |
23:08:31 | webguest80 | The problem lies in either iriver firmware, rockbox or your OS not updating the fsinfo block |
23:08:37 | Bagder | stripwax: it doesn't really |
23:08:51 | | Join amiconn [0] (~jens@p54BD4008.dip.t-dialin.net) |
23:09:23 | Bagder | webguest80: rockbox updates it |
23:09:31 | Bagder | windows usually does not |
23:09:42 | *** | Saving seen data "./dancer.seen" |
23:09:54 | stripwax | webguest80 - the problem lies in the fact that the OS has no way of knowing what exactly happens when the harddrive is in usb passthrough mode |
23:09:55 | Bagder | after all, they only made up FAT and wrote the spec |
23:09:58 | webguest80 | Indeed, I have a beef with Windows for lying to me about free space on more than one occasion |
23:10:28 | webguest80 | stripwax: not at all, the OS should update the FAT record |
23:10:33 | Bagder | stripwax: but the fsinfo stuff should be updated by the OS |
23:10:52 | | Quit Psy-Dead () |
23:11:41 | amiconn | hi |
23:12:21 | stripwax | Bagder/webguest80 - oh right - I misunderstood. yeah, you're right |
23:14:21 | memmem | Any chance that rockbox will be able to record MP3 at 256 kbit/s or 320 kbit/s on the iAUDIO X5 (as does the original firmware which makes heavy use of EMAC instructions)? |
23:14:46 | Bagder | memmem: we have no good mp3 encoder that runs fast |
23:15:22 | Bagder | so currently we don't see that coming any time soon |
23:15:34 | memmem | Ditto for OGG? |
23:15:43 | Bagder | yes afaik |
23:15:44 | BBub | better chances for recording in flac/wavpack ? |
23:15:53 | memmem | FLAC? shorten? |
23:15:54 | Bagder | BBub: yes indeed |
23:16:01 | BBub | oh, that sounds nice |
23:16:28 | memmem | The NoDo page says that WAV recording won't be done but that probably applies to the Archos devices only. |
23:16:37 | Bagder | yes |
23:16:47 | Bagder | wav recording will most likely be done first |
23:16:57 | Bagder | and it even already is somewhat implmented |
23:17:04 | memmem | Fine. |
23:17:14 | webguest80 | Wavpack isn't too far away either, it seems |
23:18:16 | | Quit webguest80 ("CGI:IRC") |
23:22:24 | BBub | is the waveform-switch in the recording-menu used to switch between raw pcm and pcm in a wave-container? |
23:24:41 | amiconn | Bagder: The gmini builds completely fell out the table, yet the 2 columns are still there... |
23:25:11 | | Quit Stryke` (Read error: 104 (Connection reset by peer)) |
23:25:44 | Bagder | yes, since they're still around |
23:25:52 | Bagder | the columns are based on more data than what is shown |
23:30:25 | | Part LinusN |
23:32:22 | | Join CheeseBurgerMan [0] (~youshould@tc2-225-085.altelco.net) |
23:34:58 | Bagder | I'll go away for a about a week starting now |
23:37:24 | amiconn | No localisation v2 commit before that? ;) |
23:37:33 | Bagder | no ;-/ |
23:37:58 | amiconn | I have an experimental plugin showing 13 shades of grey on iriver :) |
23:38:07 | Bagder | wow |
23:38:12 | Bagder | does it look good? |
23:38:24 | amiconn | Yes, way less flicker than on archos |
23:38:32 | Bagder | cool indeed |
23:38:44 | amiconn | ...because it flicks between 2 adjacent native grey levels, not black & white |
23:39:03 | stripwax | amiconn - that doesn't require constant CPU boost or anything silly does it? |
23:39:25 | amiconn | The experimental thing is without random pixel pattern shift, so more levels would flicker |
23:39:41 | amiconn | I hope to support 97 levels of grey in the actual lib |
23:40:13 | amiconn | stripwax: Yes it requires constant boost, unfortunately. That's why it will be plugin only, like on the archos |
23:40:20 | stripwax | fairy nuff |
23:40:26 | Rick | 97?! |
23:40:28 | Rick | hmm :o |
23:40:36 | amiconn | It's not a performance problem, but a problem of constant timer period |
23:40:39 | Rick | has rockboy been updated to support grayscale yet? |
23:40:52 | Bagder | see ya in a week |
23:40:53 | amiconn | Yes, 97 shades. |
23:40:55 | | Quit Bagder ("Off to search for that connect-resetting peer guy!") |
23:41:02 | | Join muesli- [0] (muesli_tv@Bc1f6.b.pppool.de) |
23:41:51 | amiconn | The method quickly switches between several bitplanes. The maximum number is limited to 32 to allow storing the pattern in a longword for quick access |
23:42:20 | amiconn | On archos, this allows 33 shades of grey, with the lcd being b&w only |
23:42:37 | amiconn | ((2-1) * 32 + 1) |
23:42:53 | amiconn | The iriver lcd already provides 4 shades natively, so |
23:43:01 | Rick | yummy yummy :) |
23:43:04 | amiconn | (4-1) * 32 + 1 = 97 |
23:43:55 | memmem | The X5 display supports 2^18 colors (and I confirmed that the firmware transfers 2^18 bits per pixel to the LCD controller). |
23:44:07 | amiconn | Nice :) |
23:44:24 | Rick | X5 display? |
23:44:34 | amiconn | Btw, this allows less shades of (pure) grey than my grayscale lib will support on H1x0 :-P |
23:44:53 | memmem | amiconn: The pixel data is not shifted left and is sent as two 9 bit words. |
23:44:57 | Rick | what is X5 display? H3x0? |
23:45:03 | memmem | iAUDIO. |
23:45:04 | amiconn | iAudio X5 |
23:45:07 | Rick | Oh |
23:45:11 | Rick | Never heard of it :P |
23:45:25 | amiconn | memmem: Any news concerning the display controller? |
23:45:44 | amiconn | I still think it is quite similar to the H3x0 lcd... |
23:45:58 | memmem | amiconn: I found enough to be able to initialize it (though I don't know what those commands actually do) and to write pixel data. |
23:46:57 | amiconn | We should still try to find the type, complete with a datasheet |
23:47:12 | Rick | the x5 looks slick |
23:47:17 | memmem | Of course. There are probably also some I/O pins involved. |
23:47:20 | amiconn | That will allow us to use some tricks the original firmware doesn't |
23:47:35 | memmem | such as? |
23:47:38 | amiconn | ...like (simple example) the display flip |
23:47:47 | memmem | What's that? |
23:47:54 | Rick | flipping the display |
23:47:57 | Rick | so its upside down |
23:48:13 | amiconn | All pixel based units have a mode to use the unit upside down |
23:48:26 | memmem | That could also be done in software. It's used rotated 90 degrees anyway. |
23:48:35 | | Quit Coldtoast ("Peace and Protection 4.22") |
23:48:41 | Rick | wouldn't hardware be faster though? |
23:48:48 | amiconn | That's useful from time to time, and since it uses a hardware feature of the controller, it's simple... |
23:49:43 | amiconn | memmem: Doing it in software would be quite a bit more complex |
23:49:51 | | Join yngwi [0] (~chatzilla@85-124-85-76.dynamic.xdsl-line.inode.at) |
23:50:00 | memmem | If all drawing operations go through a display buffer there's no difference. Just subtract 160 instead of adding 160. |
23:50:28 | stripwax | memmem - does that mean an extra test for EVERY pixel operation? or does it mean two functions where one would suffice? :-p |
23:50:29 | amiconn | They go through a display buffer with the same layout as the internal buffer of the lcd |
23:50:44 | amiconn | ...and it's not as simple |
23:50:57 | Rick | right...because then you would have to rearrange data |
23:51:11 | amiconn | (1) Flipping the line blocks is simple, as ou said just invert the line sequence |
23:51:12 | stripwax | ok, just submitted another useless patch - this one for Cube plugin lets you rotate the cube manually when it's paused |
23:51:15 | memmem | The iAUDIO firmware's buffer has a different format than expected by the LCED controller. |
23:51:38 | amiconn | (2) Flipping the lines itself is also simple, just read from the end decrementing the pointer |
23:52:00 | amiconn | (3) BUT the hard thing is flipping the pixels within a line block |
23:52:06 | memmem | I think we don't want to use 2 9-bit words per pixel with one color channel split between two words... |
23:52:28 | memmem | Just use a 256-byte table. |
23:52:46 | memmem | ...for b/w graphics. |
23:53:08 | memmem | However, we need 18 bits per pixel unless we find out how to select a different mode. |
23:53:16 | amiconn | I wouldn't use a palette mode for high/truecolour displays |
23:53:33 | amiconn | I would just use 18 bit mode and use 3 bytes per pixel |
23:53:44 | memmem | I was talking about a table for flipping the bits inside a byte for b/w displays. |
23:53:57 | stripwax | amiconn - but think of the Plasma-style/color cycling effects you could do in a palettised mode! :-p |
23:54:11 | Rick | stripwax: that would be fun :) |
23:54:15 | stripwax | memmem right or just do it in hardware.. |
23:54:30 | memmem | The iAUDIO firmware uses 3 bytes per pixel in RAM and converts to the format expected by the LCD controller while copying the data to the LCD controller. |
23:54:32 | | Quit Harpy (Read error: 110 (Connection timed out)) |
23:54:39 | stripwax | memmem wow, that sounds hideous |
23:55:09 | amiconn | Maybe the controller does only allow that format, but I doubt it |
23:55:24 | Rick | have you identified what lcd it uses? |
23:55:53 | amiconn | A bit of conversion is probably necessary anyway for colour lcds |
23:56:57 | amiconn | memmem: There are more efficient ways to swap bits than using a table... |
23:57:29 | memmem | All the bits (7<->0, 6<->1, ...)? Pray tell me... |
23:58:05 | amiconn | You can use a 3-staged shift approach, and that can work on 4 bytes at once, i.e. longwords |
23:58:13 | amiconn | I tried it, it work nicely |
23:58:29 | memmem | For 8-bit bytes, a table is better. |