--- Log for 17.07.105  Server: kornbluth.freenode.net  Channel: #rockbox
--- Nick: logbot_  Version: Dancer V4.16  Started: 5 days and 15 hours ago

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.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.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.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.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.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.09.20 ***     No seen item changed, no save performed.
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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.