--- Log for 10.02.110 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 13 hours ago 00.00.08 # pamaury: what are those "subtle properties" of FAT? 00.01.25 # basically, when you do an opendir or more generally an open without modify any entry, one of the parameters is useless. This allows to get rid of the 30kib buffer used before. This is subtle because it's highly implementation specific (and I hope it's true actually ;)) 00.01.55 # If you want more details, I can go on... 00.02.20 # Sigh: run test_codec on a folder, but don't exit at the end. Then plug in USB, and delete the (0-byte length) test_codec_001.txt file in root. unmount and unplug USB: "Panic deleting zero length directory entry" 00.03.06 *** Saving seen data "./dancer.seen" 00.05.23 Join piotrekm [0] (~pm@addq131.neoplus.adsl.tpnet.pl) 00.05.39 Quit captainkewllll (Quit: Page closed) 00.05.44 Quit piotrekm (Changing host) 00.05.45 Join piotrekm [0] (~pm@unaffiliated/piotrekm) 00.05.56 Quit piotrekm (Client Quit) 00.06.12 Join piotrekm [0] (~pm@addq131.neoplus.adsl.tpnet.pl) 00.06.24 Quit piotrekm (Changing host) 00.06.24 Join piotrekm [0] (~pm@unaffiliated/piotrekm) 00.06.57 # pamaury: interesting. Though I guess it's too late for me to go into details :) 00.07.53 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 00.08.45 Join akur [0] (~akur@bl11-193-76.dsl.telepac.pt) 00.08.53 # Interestingly, this patch also augments the stack usage on my device when doing a full rebuild... I need to investigate that. Perhaps it's because I put fat_dir and fat_direntry on the stack at the beginning. If something as a device with lots of directory and (preferably) a very deep directory structure, I would like to see the result. 00.09.01 Join dmb_ [0] (~Dmb@unaffiliated/dmb) 00.12.58 Quit bertrik (Read error: Connection reset by peer) 00.13.19 Quit evilnick (Ping timeout: 256 seconds) 00.14.19 Quit Kitar|st () 00.15.55 Quit pamaury (Quit: abort();) 00.20.28 # . 00.21.25 Join Kitar|st [0] (Kitr88@BSN-182-123-171.dial-up.dsl.siol.net) 00.24.50 # well my 5 broken sansa's I got for $5 arrived 00.24.58 # and I just realized I need sync cables to test anything 00.24.58 # ugh 00.26.57 # also guys I got an error and if anyone has smart code in devel no matter how buggy, i'd like to try it 00.27.03 # cause I fear the drop damaged the hd 00.31.06 # i'll get the error in a bit 00.31.41 # I bought the sansa's cause I heard rockbox has a usb debug driver so you can see what's on the lcd off the usb thru some kind of terminal 00.31.57 # also figured I could cut the dead lcd and possibly wire up another to the i/o pins 00.32.09 # New commit by 03stripwax (r24575): Whoops, get rid of V, there is no V 00.32.47 # also 00.33.03 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 00.33.14 # i'll seriously consider setting up a old p1, p2 linux box, with ssh login and sansa's left on it if any of you devels want somerthing to bang code off of 00.33.37 # flyback - hm, didn't we talk about this the other day? there's no 'usb debug lcd terminal'. 00.34.31 # well I mean like message passing over usb 00.34.33 Join Tomis [0] (~Tomis@70.134.77.131) 00.34.36 # there's a usb serial debug but I think that needs to be enabled specifically (plus device needs to be running rockbox etc already) 00.34.49 # no I am not talking about serial pins 00.34.53 # I was talking about what you just said 00.35.06 # but thx that gives me an idea 00.35.07 # :P 00.35.13 # I could probably jtag these also 00.35.15 Join DerPapst1 [0] (~DerPapst@p4FE8E678.dip.t-dialin.net) 00.35.27 # jtag probably only way, in fact :-p 00.35.53 # well I got a wiggler jtag that does +5 and +3.3 targets 00.36.06 # plus I bought a breakout board for a max30002 bidirectional logic level shifter 00.36.09 # goes down to 1.5 00.36.19 # so I can buffer the jtag outputs if the jtag pins are lower than +3.3 00.37.00 Quit DerPapst (Ping timeout: 264 seconds) 00.37.22 # really neat little chip 00.37.31 # only paid $10 for the breakout board with the chip already mounted 00.37.41 # up to 20mhz at some voltages and up to 40mhz on others 00.37.51 # which is fast enough for a slow speed wiggler jtag 00.38.25 # it's dual vcc so you don't have to deal with /direction pins and host/target modifications you just supply each side with the vcc for that side's logic level 00.38.33 # * TheSeven just spotted that there is no "Rockbox 3.5" choice for "Reported Version" in flyspray! 00.40.35 Join evilnick_ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 00.41.18 # TheSeven: That's because it's bug-free ;) 00.42.12 # TheSeven: Err, I can see "Rockbox 3.5" there... 00.42.13 Quit togetic (Ping timeout: 256 seconds) 00.42.40 Join evilnick__ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 00.42.59 # TheSeven: Hmm, it appears as an option in the advanced search, but not when you add a new task... 00.43.21 Quit evilnick (Ping timeout: 256 seconds) 00.45.03 Quit evilnick_ (Ping timeout: 256 seconds) 00.48.32 Join PaulJam__ [0] (~Paule@p54BEEDE2.dip.t-dialin.net) 00.49.01 Quit evilnick__ (Ping timeout: 256 seconds) 00.55.05 Quit DerPapst1 (Quit: Leaving.) 00.58.32 Join togetic [0] (~togetic@unaffiliated/ibuffy) 01.00.36 Join anewuser [0] (anewuser@unaffiliated/anewuser) 01.01.45 Join phanboy4 [0] (~benji@gate-22.spsu.edu) 01.02.19 Quit ender` (Quit: Life is what happens to you when you had other plans. -- John Lennon) 01.03.45 Join ansuz [0] (~ansuz@dsl093-172-019.pit1.dsl.speakeasy.net) 01.04.43 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 01.07.55 Quit ansuz (Remote host closed the connection) 01.10.44 Quit jgarvey (Quit: Leaving) 01.14.31 Quit evilnick (Ping timeout: 256 seconds) 01.16.51 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 01.18.39 Join Tomis2 [0] (~Tomis@70.134.92.60) 01.20.56 Quit Tomis (Ping timeout: 252 seconds) 01.20.56 Nick Tomis2 is now known as Tomis (~Tomis@70.134.92.60) 01.21.53 Quit evilnick (Ping timeout: 248 seconds) 01.25.30 Quit piotrekm (Quit: Leaving.) 01.26.46 Quit Tomis (Read error: Operation timed out) 01.27.56 Join Tomis [0] (~Tomis@70.134.92.60) 01.29.12 # hey 01.29.16 # if I don't make it, it's been fun 01.29.31 # roads are bad and they accidnetley rmoetely powered off a server at work so I gotta drive over to hit the button 01.30.13 # thanks for being offtopic 01.32.00 # Does anyone have sample vorbis files that contain 4096-sample or 8192-sample blocksizes? i.e. files encoded as -q -1 (negative quality) and/or files encoded from 64kHz or higher source material? 01.32.38 # Think that we should add these to the test files for vorbis, since 4096 & 8192 blocksizes are something of an outlier but invariable someone complains whenever we (.. I) break vorbis decoding.. 01.34.17 Quit shaggy-h (Ping timeout: 240 seconds) 01.35.31 # krazykit`, i might not be back, the roads are getting bad already 01.35.46 # and if you actually read what I said, I said it's been fun being in this channel 01.35.48 # but whatever 01.35.51 Mode "#rockbox +o rasher" by ChanServ (ChanServ@services.) 01.35.52 Mode "#rockbox +q *!~teac@*" by rasher (~rasher@rockbox/developer/rasher) 01.35.56 Mode "#rockbox -o rasher" by rasher (~rasher@rockbox/developer/rasher) 01.37.18 Part flyback 01.39.57 Quit MethoS- (Remote host closed the connection) 01.40.01 # New commit by 03stripwax (r24576): Complete the job done in previous revision - now MDCT has NO INIT of its own. Only remaining init now is the revtab in fft. Removed swathes of ... 01.41.16 # * linuxstb wonders how stripwax can complete a job done 01.41.23 # ha 01.41.39 # * stripwax never completes anything, really, ever ... 01.41.57 # So "Continue the job started..." ? 01.42.15 # More likely "Finish the job started, I think" 01.42.24 Quit Farthen (Ping timeout: 264 seconds) 01.42.39 # You just said you never complete anything ;) 01.42.43 # * linuxstb thinks it's getting late... 01.42.52 # hence "I think" 01.43.00 # anyway. goodnight to you also :) 01.43.11 Quit stripwax (Quit: http://miranda-im.org) 01.43.13 Join MethoS- [0] (~clemens@134.102.106.250) 01.43.37 Join Farthen [0] (~chatzilla@e179233053.adsl.alicedsl.de) 01.47.03 Quit PaulJam__ (Ping timeout: 260 seconds) 01.55.38 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 02.00.38 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 02.03.09 *** Saving seen data "./dancer.seen" 02.05.35 Quit komputes (Ping timeout: 245 seconds) 02.10.54 # stripwax: i have 96KHz files but nothing redistributable :/ 02.13.08 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 02.17.59 Quit evilnick (Ping timeout: 256 seconds) 02.20.44 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 02.22.25 Quit akur (Quit: Leaving.) 02.23.47 Quit bmbl (Quit: Bye!) 02.24.16 Quit JdGordon_ (Quit: Page closed) 02.24.40 Join gigatheme [0] (~62134578@giant.haxx.se) 02.25.07 # should be easy enough to transcode the FLAC sample file into vorbis q -1 02.25.21 Quit evilnick (Ping timeout: 256 seconds) 02.25.47 # can anyone here help me with the %Vi viewport tag for the .sbs files? 02.27.17 Quit maraz (Ping timeout: 265 seconds) 02.27.44 # New commit by 03mc2739 (r24577): Thai translation update ... 02.28.20 # %Vi|5|5|230|210|-|-|-| basically what does each section refer to? 02.28.57 # Vi|x|y|length|height|font|fgcolor|bgcolor| afaik 02.29.09 Join maraz [0] (maraz@kapsi.fi) 02.29.19 # ok, is that for the text area then? 02.29.28 # yep. 02.29.34 # the list position 02.29.44 # so i define the text's area then the images can fill the rest? 02.29.55 # with being overwritten 02.30.01 # or covered :P 02.30.06 # use the %V for the images etc just like the .wps 02.30.25 # the %Vi is just to define the list/menu 02.30.48 # if i dont fill in the |font|fg|bg| does it pull those from the .cfg 02.31.14 # yep you can just leave them as |-|-|-| if you like 02.31.18 # what are our correctness tests for mdct_exp? "audio files don't sound obviously wrong"? 02.31.26 # thanks for the help :) 02.31.35 # welcome 02.33.06 Quit gigatheme (Quit: CGI:IRC) 02.38.28 Quit Stephen__ (Quit: Leaving) 02.40.00 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 02.42.25 Part froggyman 02.46.06 Join evilnick_ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 02.48.01 Quit evilnick (Ping timeout: 256 seconds) 02.48.22 # Unhelpful: yeah 02.48.38 # i guess before we commit we should compute RMS errors 02.52.47 Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) 02.54.08 Quit evilnick_ (Ping timeout: 248 seconds) 02.54.36 Join froggyman [0] (~sopgenort@pool-72-69-210-48.chi01.dsl-w.verizon.net) 02.55.28 Join histumness [0] (~6340d5b7@giant.haxx.se) 02.57.06 Quit histumness (Client Quit) 03.09.03 Join gigatheme [0] (~62134578@giant.haxx.se) 03.10.56 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 03.11.34 # how do i specify a font for use on the .sbs? 03.12.02 # not for the file browser, but like for the time and stuff 03.13.30 # gigatheme: Rockbox only has two fonts - the small built-in system font, and the user-selected font. You can specify which one to use in the viewport definition 03.14.08 # is that the difference between 0 and 1 in the %Vi 03.14.29 # Yes 03.14.33 # %Vi|12|20|216|222<<>>|-|-| 03.14.53 # meh, i messed that up %Vi|12|20|216|222|<<>>|-|-| 03.15.03 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.147) 03.15.27 # so 0 means small system, and 1 is user? or opposite 03.15.28 Quit evilnick (Ping timeout: 248 seconds) 03.15.53 # gigatheme: 0 system, 1 user 03.16.06 # k 03.16.06 # Torne: ping? 03.16.07 # thanks 03.17.16 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 03.21.25 # wait, this 0 or 1, that would apply to the file browser correct? 03.24.10 # gigatheme: yes 03.25.01 # well i want to keep the file browser in the user font, but i also want the time deisplayed in the small system font 03.25.18 # the time will be in the .sbs 03.25.23 # you'd need to do it with viewports then 03.25.34 # or an .sbs 03.25.51 # yes .sbs is what im writing (first time :P) 03.26.40 # well, if there is "user" font in the .sbs, but you want the time to be in "system" font...the .sbs need to draw another viewport fot the time 03.26.50 # s/fot/for/ 03.27.52 # i want to put the menu and files in the user font, then i need the time, and probably volume dB, and battery precentage in the system font 03.28.48 Quit evilnick (Ping timeout: 248 seconds) 03.29.14 # the stock .sbs does this, im looking at it right here, but i need to figure out how its done 03.29.50 # well, if you look hard enough...it's right there. you're looking at Cabbie, yes? 03.30.04 # %Vi|0|8|-|-|1|-|-| this comes from the "classic_statusbar.sbs" 03.30.18 # no not for the .wps at all 03.30.29 # just for the browser stuff 03.30.54 # yes, the first two " - "'s mean the viewport is fullscreen, the 1 means it's in "user" font 03.31.30 # ok, and thats right, the files and menus are in the user font, but there is also a text clock in the top right which is in system font 03.31.31 # nope...don't listen to me...that's completely wrong :P 03.31.34 # ooops 03.31.45 # lol 03.32.33 # what they've done there is set a "UI Viewport, that uses the user font 03.32.45 # anything outside of that will use the system font 03.32.52 # ah ok 03.33.11 # that makes sense 03.33.37 Quit saratoga (Ping timeout: 248 seconds) 03.33.45 # UI Viewport lets you specify an area of the scree nto display the UI in...so that it isn;t fullscreen for example 03.34.01 # yes 03.34.13 # %Vi|1|16|238|278|0| thats mine 03.34.48 # so everything in the 238x278 square will be user font 03.34.54 # so you'd need to look at the viewports that draw the clock etc, and change the 0 to 1, and it should all be in User font 03.35.26 # *as an example 03.36.56 # %?cc<%?ca<%?St|time format|<%cH|%cI>:%cM|--:-->|> thats from classic_statusbar.sbs and it does what i want it to, but is there any reference to font there? 03.38.20 # nope 03.38.43 # the reference to font will be in the "main" viewport its dran in 03.38.55 # s/dran/drawn/ 03.38.59 # *I think* 03.39.27 # we'll i'll mess with it and see what happens 03.39.48 # maybe if i figure it out i can work on a new guide for the site 03.40.24 # It is a little outdated, well not really, it assumes a certain amount of knowledge is attained beforehand 03.40.34 # there isn;t really a "beginners guide" 03.40.44 # but there's an attempt at one :D 03.41.02 # yeah, i thought maybe id be a little ahead since ive already written 3 .wps 03.41.12 # lol apparently not though 03.41.44 # everything keeps changing with the .sbs's atm...so, that's *maybe* the reason it's been left alone for some time now. 03.42.01 # what's your target device btw? 03.42.09 # gigabeat f20 03.44.30 # gigatheme: try messing with animation....that gets tricky :P 03.44.30 Join komputes [0] (~komputes@ubuntu/member/komputes) 03.44.43 # I've got like 5/5 abandoned WPS's....LOL 03.44.57 # .gif? 03.44.57 # 5/6 rather 03.45.12 # .gif animation 03.45.15 # no, bitmap strips and conditional 03.45.24 # ah 03.45.25 # but I don't wanna put ideas in your haed :P 03.45.40 # http://themes.rockbox.org/index.php?target=gigabeatfx 03.45.47 # second over is my latest 03.45.59 # if .gif was supported...it'd take SOOOO much bloat out of my code 03.46.14 Join Zarggg_ [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 03.46.27 # what are you tring to animate? a clock? 03.46.55 Quit Zarggg (Read error: Connection reset by peer) 03.47.00 # *everything* 03.47.03 # * S_a_i_n_t grins 03.47.10 # lol 03.47.30 # playmode, AA transitional effects/...you name it, it moves :D 03.48.01 # yours is citrate? 03.48.05 # yeah 03.49.23 # you've got some slight problems with the "magic" colour (255,0,255 magenta) on your shuffle and repeat icons...or was that intentional? 03.49.49 # no, i accidently packaged the wrong file :P 03.50.13 # just reupload it with the same name, it'll replace the theme. 03.50.17 Join Rob2222 [0] (~Miranda@p4FDCB472.dip.t-dialin.net) 03.50.25 # you'll get a confirmation email, then it''l get replaced 03.50.26 # what a novel idea! :D 03.50.43 # didnt know that worked that way 03.50.50 # * S_a_i_n_t bows graciously 03.51.28 # it was added *fairly* recently, I think because admins got sick of people asking "hay, I messe *this* up, can you replace X with Y"? 03.53.43 Quit Rob2223 (Ping timeout: 252 seconds) 03.53.47 # that would get annoying 03.54.02 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 03.55.56 Join evilnick_ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 03.58.36 Quit perfectdrug_ (Read error: Operation timed out) 03.58.40 Quit evilnick (Ping timeout: 248 seconds) 03.59.27 # gigatheme: I *finally* found the thread....missed it like 4 times looking for it. 03.59.32 # http://forums.rockbox.org/index.php?topic=23648.0 should help 03.59.35 Quit phanboy4 (Read error: Connection reset by peer) 04.00.13 Quit panni_ (Read error: Connection reset by peer) 04.00.17 Quit evilnick_ (Ping timeout: 248 seconds) 04.00.21 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 04.01.16 Quit panni_ (Read error: Connection reset by peer) 04.01.32 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 04.02.03 Quit froggyman (Quit: Goodnight moon!) 04.03.10 *** Saving seen data "./dancer.seen" 04.06.10 # what does RTC mean :S 04.06.22 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 04.06.37 # Real Time Clock 04.06.56 # * S_a_i_n_t bows graciously 04.07.00 # that makes sense :) 04.07.35 # # Clock on RTC able targets, and disk access %V|-43|0|31|8|0|-|-| # align on the right with room for 5 SYSFONT digits %?cc<%?ca<%?St|time format|<%cH|%cI>:%cM|--:-->|> 04.07.41 Quit Tomis (Quit: Tomis) 04.08.00 # thats from the stock .sbs, and there it sets a viewport and uses 0 for system font 04.08.25 # that .sbs *probably* isn't the bast to learn from...as it uses negative values for the viewport declaration 04.08.37 # which can get confusion pretty quickly 04.08.44 # well, I found it did anyway 04.09.00 # yeah thats kinda weird but i its just screen width subtract value = +version 04.09.25 # 240 - 43 = 197 04.09.31 # for gigabeat 04.09.50 # ah...you are wise with the ways of the force young padawan :D 04.10.36 # starwars fan? 04.10.42 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 04.10.43 Quit evilnick (Read error: Connection reset by peer) 04.10.46 # not really.... 04.10.47 # lol 04.10.50 # lol 04.11.07 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 04.11.09 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-lwemduzemodcajhr) 04.11.50 # gigatheme: did you notice the # 04.11.59 # comment 04.12.04 # on those lines the # means they aren't read 04.12.16 # aha...so you did. 04.12.21 # yeah... i kinda got that already thanls though lol 04.12.29 # thanks* 04.12.59 # some people are like.."the code is right there!" why doesnt it work"...."remove the #"...."oh, right, lol" 04.14.42 # if i set the clock viewport "%V||0|31|8|0|-|-|" with a foreground color, will it change the system font color inside of the clock viewport? 04.15.33 # yep 04.15.54 # excellent 04.16.45 # you know off the top of your head (or deep within) how many pixels high the system font is? 04.16.46 # I should've realised you've got a large DPI'd player when you were wanting to use the sysfont 04.17.11 # * S_a_i_n_t has a nano (well 5 of them actually), ans sysfont is almost IMPOSSIBLE to read :D 04.17.30 # 8 high, 12 wide 04.17.45 # *I think* 04.17.53 # seems high 04.17.53 Quit evilnick (Ping timeout: 248 seconds) 04.18.15 # ah, i cna measure a screendump 04.18.58 # I think sysfont is just 08-Schumacher-Clean 04.19.04 # pretty sure it is anyway 04.20.24 # there is *probably* a blank pixel on top/bottom of the font as well, to accomodate for "y" and such 04.20.39 # but I'm pretty sure sysfont needs an 8px line 04.21.07 # and that each char is fixed width to 12px 04.21.42 # saratoga: don't at least vorbis and mp3 have mdct error-tolerance specs? 04.21.49 Quit TheSeven (Disconnected by services) 04.22.02 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.22.03 # well my top bar is 10px, so do i put it down 1y to center on the line, or do the invisible spaces make it 10 high and i put it a 0y 04.22.05 # Unhelpful: i don't think vorbis has any accuracy spec 04.22.11 # but mp3 does have conformance tests 04.22.12 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.22.23 # but they test the entire decoder 04.23.08 # for our purposes its probably sufficient to just test a WMA file with the new and old transform and a Vorbis file with 4096 blocks 04.23.22 # between them, all block sizes will be used 04.23.28 # gigatheme: 0y 04.24.00 # i'd say rather than tests on the audio a set of test coefficients and expected transform outputs would be good. the "expected" results could be computed via mdct on doubles, and compared to the mdct_exp outputs... +/- 1 we can dismiss as rounding error. or maybe i'm making it more complicated than it needs to be :/ 04.24.02 Quit panni_ (Read error: Connection reset by peer) 04.24.37 # the current transform is abotu as accurate as IEEE754 single precision, so it should be the same thing i think 04.26.02 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 04.26.04 # single is still 24 bits of mantissa, i believe?i was just thinking the "desired" result set ought to be generated with doubles to guarantee that no rounding errors (except from conversion to fixed-point of the output) are visible 04.27.57 # remember, i optimize for the sake of optimization... and do the same thing w/ accuracy ;) 04.28.01 # doesn't hurt, but i don't think it matters 04.28.13 # as long as you're above ~10 bits no one can tell the difference 04.29.05 # I'd be pretty surprised if this version is less then 20 bits, baring algorithmic errors 04.29.51 # and those ought to be glaringly obvious if we have compare to even outputs of our current transform 04.30.17 # given the 1/2*log2(N) rounding error accumulation rule of thumb, we should expect ~26 bits 04.30.39 # (for fourier related transforms) 04.30.41 Quit evilnick (Ping timeout: 248 seconds) 04.31.07 # * Unhelpful is actually not familiar w/ this particular rule of thumb... 04.31.34 # N = operations? 04.31.51 # points 04.31.55 # i've seen it around, but basically it just says you lose on average half a bit per level of divide and conquer in an fft like transform 04.32.01 # which i guess is kind of obvious 04.32.55 # ah, it's transform-specific? i've only worked on one transform, and i only reimplemented ijg's C exactly. 04.32.56 # i tend to think a split radix transform can do a bit better since its doing a lot fewer multiplies, but i'm not sure 04.33.31 Quit gigatheme (Quit: CGI:IRC) 04.34.34 # ah yaeh, its for any sort of efficient fourier related transform 04.34.37 # and i still wonder if perhaps a more mac-friendly algorithm might be possible... i had very few opportunities to use mac or armv6's packed dual-multiply-and-add 04.35.48 # isn't the packed MAC half accuracy? 04.37.33 # on armv6 i tend to think the biggest problem is going to be cache performance, since we don't even pay attention to that on PP/CF 04.37.49 # iPod Nano 1g (not sure if it makes a difference), where in the Dubug Info should I be looking to see if the player knows whether or not it is charging? 04.38.27 # does the debug screen actually show that? 04.39.04 # i expect it to know if you're on external power, but i'm not sure it would know what the battery is doing since IIRC that target has a hardware charger 04.39.09 # According to Torne 04.39.13 Join Tomis [0] (~Tomis@70.134.92.60) 04.39.23 # well if you know its there just look 04.39.55 # saratoga: all of the constants are 16-bit. were in the original code. as are the inputs. 04.40.06 # %?bp and %?bc arent working...and he told me to check the debug screen to see if it was registering the charge there or not... 04.40.13 # if it is there, I keep missing it. 04.40.13 # for MDCT or something else? 04.40.35 Quit anewuser (Quit: Another edition of chiptune gig WinterChip5! :O http://xrl.us/WinterChipV =ooo) 04.40.41 # ah, no, the transform i worked on for arm is ijg's jpeg idct 04.41.16 # for audio i'd say we can pretty much never use those lovely armv5e and armv6 bits :/ 04.41.58 # you probably could, but it would require some effort 04.42.14 # a lot of the old ATRAC players for instance used 16 bit precision DSPs 04.42.22 Quit Sajber^ (Read error: Connection reset by peer) 04.42.41 # and very carefully chose where to use 48 bit software emulated operations and where to use 16 bit ones in the MDCT 04.44.12 # or can you not do a packed 16x16=32,16x16=32 mul? 04.45.47 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 04.46.54 # saratoga: no, they're 16x16=32. there's also 16x32=48>>16 04.47.10 Quit Barahir (Ping timeout: 246 seconds) 04.47.12 # wow 04.47.27 # you could make that work in the mdct i think with pretty good accuracy 04.47.28 # they're all great if you can use them, since from arm9e on there's no early termination and the multiplier is 32x16 04.48.20 # i thought 9E had a fully pipelined mul? 04.48.55 # you could rescale the trig constants so they're all 15-16 bit, do the pre/post mul in steps with different scale factors to account for the prescale 04.48.59 Join Barahir [0] (~jonathan@gssn-5f756ff5.pool.mediaWays.net) 04.49.01 # some multiply instructions still have worse than 1c throughput 04.49.39 Quit evilnick (Client Quit) 04.50.26 Quit n17ikh (Ping timeout: 256 seconds) 04.50.42 # mull/mlal are 3c, mul/mla are 2c... i believe all multiplies with an operand that is explicitly half-word are 1c throughput 04.52.02 # yeah but its fully pipelined, so its just an interlock and not a stall 04.52.02 # hrm, except for smlalxy, but that's 16x16=32 with a 64-bit accumulate 04.52.41 Quit komputes (Ping timeout: 252 seconds) 04.53.13 # i wouldn't think so, those multiplies all have a further cycle of latency, so i take the table to mean that it actually takes 2 cycles to do mul/mla 04.54.31 # arm11 gets even worse w/ latency, most multiply instructions have no results available for 2c after execution 04.55.07 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 04.55.23 Join midgey [0] (~tjross@rockbox/developer/midgey) 04.55.50 # and mull goes from 1c delay for rdhi on arm9e to 1c delay for rdlo, 2c for rdhi :/ 04.56.37 # "The ARM9E adds a 32 x 16 MAC unit (two-cycle latency with single-cycle throughput)" 04.56.54 # although i admit the pipeline diagram makes it look like there should be 2 cycle throughput 04.57.05 # saratoga: but 32x32 multiply (mul) is two operations on that unit 04.57.30 # but the manual says the first half happens in the execute stage, while the second half happens in the memory stage of the pipeline 04.57.36 # i'm still tempted to try a goldschmidt divider on arm11 again, it wasn't quite as fast but i never really tuned it much... and it does much more in parallel w/ fewer stalls on results 04.57.48 # if it really used the multiplier twice i don't think they'd say the stage advanced 04.58.31 # but it's 32x16, how *can* it perform a 32x32 multiply in one pass? 04.59.10 # saratoga: i have some test_codec results for the mdctexp branch for the gigabeatf and e200 if you're interested 04.59.43 # Unhelpful: i assumed its actually two multipliers, one in the exec, and one in the mem stage 04.59.55 # midgey: sure, pastebin them 05.00.16 Quit MethoS- (Remote host closed the connection) 05.00.38 # saratoga: ah. i must admit we're at the limit of my knowledge of processor design here... the cycle timings i have came from the arm system developer's guide, which has them in very handy tables :) 05.01.02 # yeah i looked at the tables now, just am not sure what they mean :) 05.01.10 Join vegtoruci [0] (~vegtoruci@pool-96-246-120-217.nycmny.east.verizon.net) 05.02.14 # ah, the tables in the ASDG are not very hard to follow, there's a "cycles" column that they pretty clearly mean to indicate throughput, and a "notes" column with any other caveats that mentions latency on the arm9e, and also early registers on arm11 05.02.53 # longer multiply latency on arm11 *and* multiplier inputs as early regs make algorithms that do many chained multiplies rather bad on it :/ 05.02.58 # saratoga: http://rockbox.pastebin.ca/1792203 <- gigaf mdctexp 05.03.09 # http://rockbox.pastebin.ca/1792204 <- gigaf trunk 05.03.45 # i used r24576 for both, which is a bit unfair seeing as how trunk has had some optimizations to various codecs 05.04.58 # midgey: FWIW only vorbis and wma have the new mdct enabled 05.05.02 # the other codecs still use the old 05.05.31 # well then you have a lot of useless data :) 05.05.35 # both vorbis and wma are 1-3 MHz faster 05.05.43 Quit FOAD (Ping timeout: 246 seconds) 05.05.50 # midgey: update the codec performance wiki page, no one has done the gigabeat f since 2007 IIRC 05.06.06 # will do 05.06.09 # for bonus points do the % improvement column 05.06.22 # Unhelpful: i guess you're right, thats really a let down 05.06.22 # the arm11 manual is similar, it says mul/mla are 2c, mull/mlal 3c, and the tiny muls are 1c. oddly the instructions that perform two 16x16=32 multiplies are *also* 1c... perhaps the multiplier on arm11 is "really" two 16x16 multipliers which may operate in parallel? 05.07.01 # yes I assumed the option to do 2x 16x16 meant there was actually a pair of pipelined 16 bit multipliers 05.07.11 # but apparently not 05.07.24 # i suppose this would explain why PP can keep up with the newer ARM targets 05.07.37 # i always wondered why it doesn't get destroyed if the multiplier is really 4x faster 05.07.53 # well probably more like 2-3x faster if early termination is taken into account 05.08.11 # saratoga: it's still never *slower* than arm7tdmi, and you can have 1c multiplies if you can wait for the results and both inputs are 16bit, or if you want to multiply-and-shift a 32-bit value by a 16-bit one. 05.08.43 # but i suspect a *large* number of cycles in the new divider are spent stalled on arm11 05.09.06 # i wonder why cook_stereo_32 is more then two times faster then cook_stereo_64 05.09.06 # saratoga: http://rockbox.pastebin.ca/1792206 <- e200 mdctexp 05.09.14 # i wonder if the files are misnamed 05.09.21 # with only wma and vorbis this time 05.09.42 # 300.94% realtime for 128k WMA 05.09.43 # amazing 05.09.55 # my first test of the codec was only 80% realtime on PP 05.10.12 # excellent work all around 05.10.25 # i can test on h300 if you'd like, but i'd need someone to provide me with a build 05.10.40 # i haven't figured out how to compile gcc 3.4.6 on snow leopard yet.... 05.11.24 # ok, bed for me :P 05.11.35 # midgey: lets wait until the XNPROD31_R ASM for CF is fixed 05.11.45 # the results will be a little slower right now 05.12.21 # yep, i assumed as much. just ping me or leave a message in the logs 05.12.21 # i'll try and fix it tomorrow if stripwax doesn't first, i have to get some work done now 05.12.26 # ok great 05.12.36 # good to know we're faster on the F 05.12.37 Join FOAD [0] (~dok@dinah.blub.net) 05.12.48 # little more work on CF and we'll probably be faster on all targets 05.13.02 # then i guess we check accuracy and roll out the lib 05.13.09 # i have a mini2g and ipod4g i can test on if it's useful 05.13.10 # and of course switch all the other codecs over to it 05.13.15 # those are both pp5022 iirc 05.13.22 # isn't the 4G 5020? 05.13.24 # so not too different than e200 05.13.27 # that might be neat, IIRC it has less IRAM 05.13.41 # though i guess still enough that the lib will perform the same 05.14.36 # you're right on the 4g, it has a pp5020 05.19.47 # might be worth checking if it compiles and links 05.19.54 # New commit by 03jdgordon (r24578): Fix FS#10983 - r24568 was just moronic. Sorry 05.21.13 # saratoga: i'm charging the 4g right now. i'll do a build with the same revision tomorrow 05.21.34 # midgey: just checked, it links fine, so probably not worth testing 05.22.20 # the only other really interesting targets to test on are the IPod < 4G and the gigabeat S 05.23.11 # unfortunately i don't have any of those, the pp5002 targets will be interesting 05.23.48 # i'll do 3G later, need to get to work 05.23.56 # unhelpful can probably do the beast 05.25.17 Quit saratoga (Quit: Page closed) 05.41.32 Quit fyrestorm (Quit: lamers envy me like they envy bill g -- main boot xp, just the way it should be!) 05.44.38 Join flyback [0] (~teac@c-98-219-129-239.hsd1.pa.comcast.net) 05.53.08 # New commit by 03jdgordon (r24579): OK, this is hopefully the last sbs related fix. This one will fix the backdrop going garbage, and add a missing else which kugel spotted 06.03.13 *** Saving seen data "./dancer.seen" 06.25.45 Join Guest23293 [0] (~n17ikh@host-69-59-126-212.nctv.com) 06.25.55 Quit n17ikh (Disconnected by services) 06.25.59 Quit Guest23293 (Client Quit) 06.26.19 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 06.34.00 Quit dmb_ (Quit: Leaving) 06.35.50 Quit jd (Read error: Connection reset by peer) 06.36.08 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 06.36.08 Quit jd (Changing host) 06.36.08 Join jd [0] (~jd@Wikipedia/HellDragon) 06.58.46 Quit midgey (Quit: midgey) 07.00.12 Join DomasoFan [0] (~c2d0e4c8@giant.haxx.se) 07.02.17 # Hi. does someone know if the Sansa Fuze with the following model is a Sansa Fuze v1?: SDMX14R-008GK-E57 07.05.02 Quit DomasoFan (Client Quit) 07.22.10 Quit HBK (Read error: Connection reset by peer) 07.22.43 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 07.23.11 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 07.23.15 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 07.49.30 # http://imagebin.ca/img/cje-32u.bmp multifont? 07.49.33 # not quite :p 07.50.06 Quit gevaerts (Disconnected by services) 07.50.18 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 07.57.21 Join ender` [0] (krneki@foo.eternallybored.org) 08.03.15 *** Saving seen data "./dancer.seen" 08.10.12 Quit vegtoruci (Ping timeout: 260 seconds) 08.23.31 Join dmb [0] (~Dmb@unaffiliated/dmb) 08.30.39 # http://imagebin.ca/img/tarYa-a.bmp <- working multifont 08.31.37 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 08.31.54 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 08.46.02 Join JdGordon1 [0] (~jonno@c-24-22-210-83.hsd1.wa.comcast.net) 08.46.09 Quit JdGordon (Ping timeout: 256 seconds) 08.51.45 Join flydutch [0] (~flydutch@host66-209-dynamic.15-87-r.retail.telecomitalia.it) 09.00.47 Join petur [0] (~petur@rockbox/developer/petur) 09.01.09 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 09.06.39 Quit BHSPitMonkey (Remote host closed the connection) 09.12.40 # does anyone tihnk 10000 is too small for multifont for the fonts loaded by skins? (thats 10K each font) 09.13.03 Join kugel [0] (kugel@rockbox/developer/kugel) 09.15.02 # JdGordon: I noticed you're changing the settings string directly 09.15.12 # which? where? 09.15.26 # *ptr2 = '|'; 09.16.00 # no, its copied to a buffer first 09.16.33 # ptr2 = global_settings.ui_vp_config; 09.17.17 # yes, keep reading 09.17.30 # len = snprintf(ptr, remaining, "%%ax%%Vi|%s|\n", ptr2); 09.17.36 # while ((ptr2 = strchr(ptr, ','))) 09.17.47 # and ptr = buf; at the top 09.17.56 Quit Adub- (Quit: japanese men make hot trannies) 09.18.09 # ptr is the other buffer yes, but you're writing to ptr2 09.18.41 Quit JdGordon1 (Ping timeout: 248 seconds) 09.18.51 # you make the ui viewport setting look like "ui viewport: 5|1|30|2|2|ffffff|000000" 09.19.46 # do we really need an ui viewport setting anymore? 09.19.48 # no, its ptr2 is pointing inside the buf buffer 09.20.39 # huh? 09.20.42 # pixelma: IMO we never did. but yeah, we may as well keep it 09.20.51 # which is a hidden setting and therefore only known by 10 people or so :/ 09.20.52 # are we looking at the same code? 09.21.14 # yes 09.21.23 # ptr2 is pointing to the settings string 09.22.57 # yes 09.23.08 # which ois then snpriontf()'ed into ptr which points to the new buffer 09.23.30 # that doesn't change where it's pointing to 09.23.40 # it's still pointing to the settings string 09.24.11 # while ((ptr2 = strchr(ptr, ','))) 09.24.45 # are you actually seeing the |'s in the .cfg file? 09.24.57 # ah right, I'm sorry 09.25.52 Join dmb_ [0] (~Dmb@unaffiliated/dmb) 09.26.29 # I could understand dropping the ui viewport setting much much more than dropping any other theme menu items I can currently think of because colours or backdrop are easily set on device and the menu items speak for themselves. The ui viewport setting is hidden and if you would want to adjust it on device it's as complicated as editing an sbs file with just the %Vi 09.26.33 # did that commit also fix that the ui viewport is ignored? 09.27.17 # pixelma: the ui viewport is for when you don't use a sbs 09.27.54 # but it can easily replaced by using the most simple sbs 09.27.56 # removing it doesn't gain anything, it's impact on the code is about 10 lines 09.28.07 # http://imagebin.ca/img/60lPObu.bmp working multifont :) 09.28.37 # kugel: the missing else? yes 09.28.50 # pixelma: I want to add a UI for setting the ui viewport 09.29.13 # JdGordon: I rather thought about the missing trailing | that as fixed 09.29.20 # was* 09.29.26 # thats what caused the background garbage 09.29.33 # I didnt realise the setting didnt have it 09.29.41 # hence my commit message 09.29.45 # we had multifont "working" long ago so your screenshot doesn't thrill me 09.30.15 # I haven't looked at the patch but after what you're saying I'm not a fan as well (but I won't object, I want multifont as well) 09.31.10 # not sure if the intersection thing is still there which complicates things. And it also complicates understanding theme settings as you have two ways to achieve the same thing and might hit a situation where "a" doesn't work as you expect because "b" is in place and takes priority 09.31.41 # the intersection thing is gone 09.31.52 # and /me pokes his tounge out at kugel :p 09.33.21 # I dont know how you can not like this method. 0 wasted RAM if you dont use it (well almost 0 anyway), theoretically unlimited fonts 09.33.28 # makes the font cache more clever 09.36.49 # I single buffer would be most clever 09.37.55 # wtf? does the .glyphcache file only cache the glyph numbers? and not the actual glyph bits? 09.38.09 # 1 buffer would be MUCH more complicated 09.38.29 # and not ever big enough to satisfy everyone, and too big for others 09.39.02 # it could also grow and shrink with the number of fonts 09.39.13 # the lru mechanism works best in a single buffer 09.40.08 # the glyph cache probably only saves the index; it's just for letting the lru survive a shutdown 09.41.33 # yeah, it makes sense, its just thats not what I ever thought it was doing 09.42.23 # and no, a single buffer doesnt make lru any better 09.42.44 # it might make the overall buffer more efficient though\ 09.47.58 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 09.52.59 Join Bagder [0] (~daniel@rockbox/developer/bagder) 09.53.12 Quit kugel (Ping timeout: 264 seconds) 09.57.21 Join Speedy1 [0] (~Speedy@bzq-79-180-18-85.red.bezeqint.net) 09.57.22 # www.search2.net 09.57.59 Part Speedy1 10.00.15 Quit amiconn (Disconnected by services) 10.00.17 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 10.00.39 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 10.03.18 *** Saving seen data "./dancer.seen" 10.12.04 Join swilde [0] (~wilde@aktaia.intevation.org) 10.13.05 Quit AndyIL (Ping timeout: 248 seconds) 10.14.35 # pixelma: I see your point with the UI Viewpoint, but I think not dropping it as an option is more to do with not forcing people to use an .sbs 10.14.48 # *note the "I think* however. 10.15.20 Join Curulan [0] (~zarggg@2001:0:4137:9e74:0:96f8:beb1:ba3d) 10.15.26 Quit Zarggg_ (Read error: Connection reset by peer) 10.19.02 Join AndyI [0] (~pasha_int@212.14.205.32) 10.23.13 Quit AndyI (Ping timeout: 248 seconds) 10.23.52 Join AndyI [0] (~pasha_int@212.14.205.32) 10.33.42 Join PaulJam__ [0] (~Paule@p54BEC922.dip.t-dialin.net) 10.38.28 Join Zarggg_ [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 10.41.24 Quit Curulan (Ping timeout: 260 seconds) 10.42.49 # S_a_i_n_t: well, it's been discussed to drop other theme settings too. To be exact: not the setting but the menu items, the settings will still be there but hidden which is worse and the ui viewport setting didn't ever make it into the menu. 10.49.21 # to be honest, I'm not much of a fan of dropping the other theme settings from the menu... 10.49.34 # but I do think UI Viewport should stay as a .cfg option 10.49.45 # it's not doing any harm to those that don;t use it. 10.50.10 # many I'm having bad luck with ; vs. ' today... 10.53.02 Join _zic [0] (~user@91-165-251-120.rev.libertysurf.net) 10.53.41 # Oh, wait...by me saying "not dropping it as an option", I didn't mean a menu option (as I know there isn't one), what I meant was the option to configure it via .cfg that I think should stay. 11.06.36 # I also want the other menu items to stay, at least as long as there is no other way of easily adjusting colours or stuff like that (via a plugin or so). But for ui viewport and an sbs with %we and your %Vi - I don't see a difference especially if the former stays a hidden setting - and then having two things doing the same can't be good. 11.13.15 # there's probably more than one instance of "more than one way to do the same thing"...in fact there is, by that respect, anything that has a .cfg setting should be booted out of the menu. Or perhaps sleep deprivation has my thinking somewhat backward as to what you're suggesting. 11.14.09 # Uhm, "anything that has a .cfg setting should be booted out of the menu" means "remove the settings menu" 11.15.28 # that was kinda my point, but a hint of sarcasm need be implied also. 11.15.40 # more than a hint actually 11.17.14 # long story short, IMHO UI Viewport should stay in the .cfg until there's a better way to do it, and probably even if there is. 11.22.19 # huh? I think that's reverse - your "even" would be my only "if that happens then there might be one reason for it to stay". SBS is already another way to do it, not better but not worse (which is my point that other settings being cfg one only will be worse than what there is now, try chosing a different background colour if it is only a cfg file setting, getting your hex number out of thin air and only seeing the result after getting back and forth 11.22.19 # a few times usig the text editor. 11.22.45 # I did a battery bench on my clip last night - 09:02 11.24.46 # no-one explained to me yet where the difference between ui viewport and such a simple sbs is (other than maybe the %we line), adjusting coordinates on target would be exactly the same 11.25.05 # what I meant by "even if there is" is that it probably has the potential to give a lot of support related grief, like "why is my menu now only 1px wide" so on and so forth. 11.25.36 # It's probaby better (for now) if themers handle the UI Viewport 11.26.22 # how? 11.26.25 # and the difference is, not forcing people to use .sbs 11.27.01 # at the moment, if you want UI viewport, but not an .sbs..you can. 11.27.51 # but the sbs would only be "use this %Vi" as ui viewport, nothing else 11.27.51 # don;t get me wrong, I can see your point (and I think it's valid too), but there are two sides to a coin. 11.28.21 # but it still forces an action, which isn't good IMO 11.28.58 # * gevaerts still thinks that *if* independently designed .sbs and menu backdrop are supposed to be supported, the intersection method is the only working solution 11.29.01 # what action (more than setting an ui viewport)? 11.30.51 # this could go back and forth for a long time, so /me decides to drop it. 11.31.10 # I mean compared to editing the cfg file - where is a difference in "action" to editing an sbs file? 11.31.17 # whilst retaining his opinion of course. 11.31.36 # having to have an .sbs in the first place. 11.31.45 # EVERYONE has a cfg 11.31.55 # a LOT of people don't have .sbs's 11.32.29 # (apparently dropping it isn;t an opyion) :P 11.32.38 # you would have to add a ui viewport line (and have to know the syntax) 11.33.03 # UI viewport line is always in the .cfg 11.33.08 # just with no options 11.33.17 # ui viewport: - 11.36.10 # only if you save a full cfg and then I still have to know the syntax for the coordinates etc. 11.36.46 # you need to know the syntax for .sbs also...it's totally double edged 11.36.54 # nooone's going to be happy apparently 11.38.21 # be back in 5 mins... 11.38.23 Quit S_a_i_n_t (Quit: [St.] has exited mIRC™) 11.39.02 # yes, which is why I don't see a difference and sbs giving more power 11.39.58 Quit bug2000 (Read error: Operation timed out) 11.40.45 # Unless the sbs specifies the backdrop to use (does it these days? I haven't really followed closely), there should be a not-in-sbs way to specify the viewport 11.42.02 # That way *should not* be used by themes, it's the way you adjust things if whatever viewport settings that come with the sbs/skin are not compatible with the backdrop the user selected 11.42.06 # it can 11.42.29 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.240) 11.42.41 # back 11.43.30 # but if you don't specify a backdrop, the main backdrop set through the menu is used (or that was the plan) 11.43.34 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 11.44.11 # * S_a_i_n_t thinks he's missed some of this conversation... 11.45.35 # * pixelma points S_a_i_n_t to the topic 11.45.45 # i dont hear sound from rockboy - is it disabled for my target? (nano2g) 11.45.54 # S_a_i_n_t: i did tell you exactly where the battery status was btw :) 11.46.11 # S_a_i_n_t: if you didn't find it yet, the secret is that the "view battery" screen, with the graph, has multiple pages: scroll the wheel to see the others 11.46.15 # in debug isn;t that exact... 11.46.16 # ok. My view is that as long as that is supported, there should also be a non-sbs way to specify the viewport, and I think it should be as easy to use as the backdrop setting (i.e. not .cfg-only) 11.46.43 # gevaerts: exactly 11.46.46 # S_a_i_n_t: I told you to scroll down on the view battery screen 11.46.56 # gevaerts argues a point a LOT better than I do apparently 11.46.58 # so yes, it was exact :) 11.48.14 # My reason for that is that you want to be able to update a theme from the theme site without having to re-do half of your local settings again (the other half being the backdrop itself) 11.49.14 # Torne; I couldn't tell what it was I was supposed to be looking at "battery, power status, voltage delta or Last PowerHist) 11.49.44 # er 11.50.24 # is it not self-explanatory? 11.50.38 # apparently not. 11.50.58 # Aha 11.51.11 # the screen i was directing you to is ifdef'ed for IPOD_NANO || IPOD_VIDEO 11.51.15 # interesting 11.51.48 # yeaH, someone else said your theory wouldn;t work (scorche maybe?) but I wanted to ask you... 11.52.02 # F'N SEMICOLON!!! 11.52.03 # that is odd, though, i'm pretty sure it should be available 11.52.23 # which model is yours again? 11.52.34 # and I'm guessing *that's* what %bp and %bc don;t work on the Nano 11.52.42 # 1gen Nano 11.52.43 # Wait, you have a nano1g? 11.52.49 # havent tried the 2geb yet 11.52.51 # the debug screen is enabled on IPOD_NANO 11.52.55 # but I assume it's the same 11.52.55 # so it should be right there 11.53.04 # i thought you had a mini or something 11.53.19 # nope...nano 11.53.22 # 5 in fact 11.53.25 # Power status screen 11.53.42 # should list USB pwr, EXT pwr, Battery 11.53.54 # USB pwr should be obvious.. 11.54.01 # battery says charging/charged/discharging 11.54.05 # which should be obvious also :) 11.54.13 # ext pwr I believe is the 12V from the firewire pins? 11.54.53 # are those lines not there for you? 11.55.19 # no 11.55.31 # Well, er 11.55.34 # they are supposed to be 11.55.45 # nothing changes in the power status screen except the voltage jumps slightly 11.55.54 # after watching it for a few seconds though 11.55.59 # Those lines should be there all the time 11.56.06 # but the lines your talking about aren;t ther at all 11.56.14 # well they're defined for nano and video 11.56.23 # likewise the lines in power-ipod.c which return the charger status 11.56.32 # which should be what drives the wps tokens 11.56.42 # I can screendump if you want me to confirm I'm not an idiot..it may help 11.56.45 # so yes i am pretty certain it should work. 11.56.46 # just in case am 11.57.15 # the screen starts with "Power status:" 11.57.24 # then a line with "Battery: 3.6V" or whatever 11.57.25 # yes? 11.57.32 # those are unconditional for all targets so that *must* be there :) 11.57.33 # yep 11.57.41 # Hmm 11.57.48 # there should be like 5-6 more lines 11.57.48 # yes, and it just says Battery: *voltage 11.58.13 # screendump? 11.58.28 # no need.. 11.58.32 # i have a theory 11.59.17 # hm. mayhbe not. 11.59.19 # bizarre. 12.00.14 # back in a sec 12.01.04 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.240) 12.01.31 # shit, sorry...pressed X instead of minimise 12.02.12 # I have a file on the root of my player called identify_info 12.02.17 # not rb related? 12.02.27 # I've never seen it before 12.03.19 *** Saving seen data "./dancer.seen" 12.04.34 # * gevaerts accuses S_a_i_n_t_ of having selected random debug menu items :) 12.05.07 # ssssshhhhh you :P 12.05.46 # http://imgur.com/USku4.png 12.05.56 # and no, it's not photochopped :P 12.08.34 # Hmmmm...ok, so identify_info *is* Rb related...but what is it? 12.08.40 # can I kill it? 12.09.12 Join kugel [0] (kugel@rockbox/developer/kugel) 12.16.27 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 12.18.58 # Could someone please take a look at fs#10065 and my last comment on there? I would really like to see that task closed.. 12.21.03 # archivator: if nobody beats me to it, I'll have a look tonight 12.22.00 # Thanks, gevaerts :) 12.22.11 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 12.22.56 # S_a_i_n_t: OK, I cannot find any reason why the nano1g shouldn't display that info. 12.23.09 # S_a_i_n_t: it is indeed not present on any *other* ipod 12.23.10 # well...it doesn;t. 12.23.20 # guess I need to file a bug report then? 12.23.21 # only nano1g and video (nano2g has its own different info there) 12.23.49 # Ohhhh 12.23.52 # There we go :) 12.23.56 # nano1g doesn't define CONFIG_CHARGING 12.23.59 # which is why none of this works 12.23.59 # found it? 12.24.11 # * S_a_i_n_t_ was beginning to think he was going insane 12.24.25 # Hmm 12.24.38 # the 4g/color/mini1g/mini2g/video all have CHARGING_MONITOR 12.24.42 # but nano1g has nothing 12.25.05 # *should* it have it? 12.25.12 # I'm guessing so 12.25.25 # I was under the impression that all those models, including nano1g, had approximately the same charging arrangement 12.25.37 # same PCF, same charge controller, just mayhbe different GPIO pins used 12.25.41 # but i might be wrong 12.26.13 # the code for it is there in power-ipod.c 12.26.14 # but it's ifdef'ed out as a result of not having CONFIG_CHARGING 12.26.32 # try setting it to CHARGING_MONITOR in the config 12.26.35 # and see if that even compiles 12.27.07 # that may take a while...I'll get back to you :P 12.27.23 # well i can see if it compiles, if you want, but i can't test it :) 12.27.32 Quit liar (Ping timeout: 252 seconds) 12.27.57 # then it may as wel be me, I can do both 12.28.03 # it'll just take longer 12.28.32 # meh, i'm building it now 12.29.01 # send me the .diff if it works then :P 12.29.15 # works/compiles 12.29.16 # you can just have the build 12.29.21 # if you want to try it :) 12.29.50 # thank the "friendly neighbours" 12.29.51 # :P 12.30.18 # dammit, my tranfer rate is shocking was supposed to come before that 12.30.48 Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) 12.31.29 # linuxstb: do you know why nano1g doesn't have CONFIG_CHARGING defined? 12.31.40 # rockbox builds, i'll let it do the rest and make you a zip 12.32.28 # upload it somewhere, don't bother with DCC...you'll get pissed off by my shitty transfer rate 12.33.07 # * S_a_i_n_t_ solved his semicolon problem by remapping the keyboard, prying both keys off and switching them :D 12.33.18 # better than learning to type properly :D 12.33.35 # Torne: r16124 might half-explain this 12.33.36 # s/better/easier/ 12.33.39 # upload? doesn't every computer everywhere have a webserver? 12.34.46 # this is a "....buh?" moment for me. 12.34.52 # gevaerts: hm. the video/nano have different gpios 12.35.01 # but the code implies strongly that the video/nano work identically 12.35.12 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 12.36.13 # So the question is why it wasn't enabled by r8966 12.36.19 # r19315 added nano support to power-ipod.c 12.36.23 # but didn't change CONFIG_CHARGING 12.37.38 # S_a_i_n_t: http://whitefang.wolfpuppy.org.uk/temp/rockbox-nanocharging.zip 12.38.09 # Torne: I've no idea. Has it never been enabled? 12.38.15 # linuxstb: it's neve rbeen enabled 12.38.30 # r16124 implemented charging monitoring for 4g/mini/color 12.38.37 # video came at some differnet point 12.38.48 # then 19315 changed the ifdefs to make the video code cover nano as well 12.38.58 # but nothing ever turned on CONFIG_CHARGING for nano so that code isn't used 12.39.06 # i guess S_a_i_n_t can try it for us 12.39.13 # yay! 12.39.17 # usefullness! 12.39.18 # what else does CONFIG_CHARGING affect? is there any chance it could make stuff go horribly wrong? 12.39.47 # bah....nano's (ipods in general) are unbrickable 12.40.02 # besides the hammer (and my newfound coffee) method 12.40.22 # that nano never recovered....R.I.P 12.40.49 # Torne: I've no idea about the power management stuff. I wouldn't have expected it to make much difference on the ipods, apart from cosmetic things like charging indicators. 12.41.21 # Yah, it's only monitoring 12.41.28 # That's not insignificant 12.42.13 # so this *is* the reason my %bc/bp tags are broken?!? 12.42.20 # yes, this is exactly the reason 12.42.27 # aha... 12.42.35 # currently the nano1g does not support *any* kind of charging status whatsoever 12.42.40 # because it's not been turned on :) 12.42.45 # * S_a_i_n_t_ finally found a bug of interest, and not annoyance 12.42.54 # the code is there and it compiles 12.42.59 # so i guess it's just whether it *actually works* 12.43.05 # i.e. displays the right status 12.43.16 # I'll let you know in 10mins or so. 12.46.52 # have you got something that provides 12V firewire power, also? 12.47.07 # if so it would be good to check whether the EXT power changes appropriately when you insert that 12.47.12 # car chargers usually do? 12.47.44 # no, and nano isnt firewire anyway. 12.48.29 # No, but it still accepts 12V power on the pins used by the firewire cable 12.48.32 # all the ipods do 12.48.42 # the data lines don't exist, no 12.48.46 # Hm 12.49.01 # FS#6891 suggests that the code *isn't* right and that the nano has different GPIOs for this 12.49.04 Quit Tomis (Read error: Operation timed out) 12.49.09 # so yes there is alrady a bug for this 12.49.25 Join Tomis [0] (~Tomis@70.134.92.60) 12.49.38 # ah...so this wont work? 12.49.45 # It might 12.49.46 Quit PaulJam__ (Read error: Connection reset by peer) 12.49.48 # It depends who is right :) 12.50.05 # we'll see very soon 12.50.10 # FS#10591 has a patch which does exactly what i have just done, dreamlayers evidently was also assuming tha tthe code already in svn works 12.50.45 # FS#6940 is also relevant 12.50.46 # so, hm 12.50.53 # there have been three different patches that claim to fix this 12.50.54 # all different :) 12.50.56 # HOORAY :) 12.51.09 # yay! ....not 12.52.18 # so i guess the next question is does anyone have a nano1g and both usb/firewire chargers and can get a multimeter appropriately attached? :) 12.54.24 # Oh wait, no 12.54.34 # the patches are all using the same GPIO pins as the current code after all 12.54.46 # the ipodvideo code got changed since these patches were written :) 12.55.23 Quit Hadaka (Ping timeout: 276 seconds) 12.55.56 # so if this works for you we can probably commit it and close out all three of those bugs 12.58.12 Join watto [0] (~watto@193.203.81.165) 12.58.51 # fingers crossed... 12.59.03 # transer 12.59.35 # (usb) is slooooooow for some reason... 13.00.30 # usb transfers being slow on ipods is a known issue, no? 13.00.43 # the rockbox build is made of loads of tiny files, which is a worst-case for USB mass storage anyway 13.01.11 # yeah...nano2g is about 100% faster than 1g 13.01.34 # for transfer that is. 13.01.52 # I never experienced much speed difference between the two 13.02.12 # Torne: Apple's emergency disk mode is known to be slow on the nano1g and video. 13.02.14 # i have, DRAMATIC difference 13.02.36 # I don't use the emergency disk mode, but I do use the disk mode 13.02.45 # or are they the same 13.02.47 # linuxstb: wait, on the video? 13.03.02 # Galois: yep 13.03.03 # i've not noticed it being slow 13.03.10 # ahwell *shrug* 13.03.23 # i was talking about using rockbox usb, anyway 13.03.45 # well, either way, rockbox usb or disk mode, it's as fast as any other usb device for me 13.03.47 # fwiw...so was i 13.04.02 # Galois: "emergency disk mode" is the disk mode built into Apple bootloader in the NOR flash (accessed by pressing SELECT+PLAY when booting, or if Rockbox reboots into it). The other disk mode is the version in Apple's main firmware. 13.04.29 # * gevaerts ignores all USB speed reports that do not have actual numbers and a description of the testing method 13.04.41 Join Hadaka [0] (~naked@naked.iki.fi) 13.05.52 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 13.05.54 # Torne: sorry man, debug still has the one option 13.06.04 # er 13.06.17 # battery that is... :D 13.06.20 # that's definately impossible ;) 13.06.37 # er...hang on 13.07.25 # you fixed it!!! 13.07.25 Join MethoS- [0] (~clemens@134.102.106.250) 13.07.43 # you mean the wps tokens work? 13.07.50 # what about the debug menu? 13.08.02 # usb power, ext power, battery, charging, headphone! 13.08.09 # Yup, that's what's supposed ot be there :) 13.08.15 # YAY! 13.08.25 # my ipod did a "first something" 13.08.30 # * S_a_i_n_t_ feels speciasl 13.09.03 # wow....3 bugs with one commit...that's gotta be a first, or close to a record :D 13.09.12 # Well, don't jump the gun 13.09.18 # ..er, not that it's committed yet 13.09.22 # i presume usb power toggles on and off when you plug and unplug the cable? 13.09.26 # and battery says charging/discharging? 13.09.35 # it sure does 13.09.40 # yep 13.09.46 # can you check that it correctly reports when the battery is charged? 13.09.48 # (ish) 13.10.11 # best method to do this woul dbe boot the OF and let it charge there until the OF says charging is done, then start RB again and plug cable back in, give it a few mins 13.10.44 # ok, but it may take a while... 13.10.48 # will do however 13.10.50 # i'm willing to assume the firewire power pin is handled right, since it's done the same on video and in the patches for the other issues, but none of them address the charged status 13.10.52 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 13.10.58 # which is different code 13.11.14 # thanks 13.11.56 # (check both the debug menu state and the wps for that, btw) 13.13.10 # ok....wil do, btw...is disk-mode god enough for the "charg in OF" bit? or actually boot into the OF necessary? 13.13.16 Join DerPapst [0] (~DerPapst@p4FE8F013.dip.t-dialin.net) 13.13.24 # disk mode will do if it actually tells you when the battery is charged 13.13.26 # i dunno :) 13.13.38 # it does so on the 2g at least 13.13.38 # yeah...sweet 13.14.03 # * S_a_i_n_t_ feels usefull for a change 13.14.12 # is there really a "charged" status reported by the hardware? i have the impression that on the 2g they just determine that by the battery voltage and current readings 13.14.12 # * S_a_i_n_t_ likes this new feeling :D 13.15.03 # TheSeven: well, the code for the PP ipods does GPIOB_INPUT_VAL & 0x01 13.15.07 # for all models apart from Color 13.15.16 # (and 1g/2g) 13.15.26 # Hmmm....seperate topic, but last time I checked I noticed that the 2g reported "estimated time left" as 4000 minutes or so...that can't be right? no? 13.16.14 # TheSeven: and as far as i've observed that reports accurately for the video 13.16.25 # 4882 minutes even, at 100% 13.16.28 # see charging_state in power-ipod.c 13.16.30 # * TheSeven blames that on nobody having calibrated it yet 13.17.09 # * TheSeven would actually like to do a rework of the whole rockbox power management code 13.17.37 # well off you go :) 13.17.47 # I was waiting for that :P 13.18.03 # i'm only going to rework usb charging 13.18.09 # the rest will have to be someone else ;) 13.18.28 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 13.18.43 # we need to account for things like the inner resistance, and i would like to base the runtime estimates on real current readings for targets that have them 13.19.24 # the latter would be nice, but i'd be a bit cautious about how you average ti 13.19.49 # e.g. playlists that include a variety of codecs with drastically different boost ratios 13.19.55 # Torne: yes, one of the problems of that is that measuring the current will cause additional current to be drawn, and thus included in the measurement 13.20.03 Quit DerPapst (Ping timeout: 272 seconds) 13.20.09 # well, i didn't mean that :) 13.20.11 # but yes 13.20.28 # i mean more the case where you have an album in something expensive, and one in something cheap.. 13.20.38 # is the estimate going to shift by many hours depending which album the playlist has reached? :) 13.20.40 # Torne: codecs won't really matter as mp3, wma, vorbis and flac all play realtime without needing to boost 13.20.57 # and i don't think other codecs are popular enough to be an issue... 13.20.58 # also the disk spinup frequency with flac.. 13.21.01 # and so on 13.21.04 # i dunno. i'm just speculating 13.21.09 # it may be not that much of a problem 13.21.48 # anyways, I think it will always be more accurate than what we're currently doing, which is just assuming that it will always take the same current 13.22.14 # the bigger problem is, that when charging, the battery voltage will quickly be at 4.18V, but that doesn't tell *anything* about the charge it has taken with li-po batteries 13.22.25 # right. 13.22.38 # * S_a_i_n_t_ is *really* glad he took this problem to IRC instead of the forums... ; 13.23.20 Join DerPapst [0] (~DerPapst@p4FE8EBB2.dip.t-dialin.net) 13.23.30 # we could fix that by finding out the approximate inner resistance of that battery and "fixing" the voltage reading according to the current 13.24.00 # * TheSeven needs to check whether that is linear for lipos though 13.24.08 # and *really* glad for the existence of the lifeform known as Torne 13.24.09 # well, that part is definately beyond me :) 13.30.52 Part wookey_ 13.37.26 Join perfectdrug_ [0] (~marko@p5B0EC836.dip.t-dialin.net) 13.37.53 Quit antil33t (Read error: Connection reset by peer) 13.38.00 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 13.39.04 Join Omlet [0] (omlet05@171.102-240-81.adsl-dyn.isp.belgacom.be) 13.53.17 Quit Galois (Remote host closed the connection) 13.53.40 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 13.53.50 Quit Galois (Client Quit) 13.54.26 # wow, someone uses frotz a lot, on the forums 13.54.36 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 13.55.50 # New commit by 03mc2739 (r24580): Updated Portuguese Translation ... 13.56.00 # i do too, i just don't post about it. for me, IF on my ipod is better than...errr, somethingelse hat's good ;) 13.58.17 # did anyone ever try ffmp3 with rockbox? 13.58.28 # the ffmpeg guys says its faster than libmad at least 13.58.59 # S_a_i_n_t_: actually playing existing IF wasn't what i had in mind for frotz at all, but hey, it's a freebie feature :) 13.59.29 # what did you have in mind? 13.59.33 # Bagder: So's our decoder :) 14.00.04 # yes, but our is libmad based 14.00.09 # afaiu 14.00.20 # yes, and saratoga constantly complains about it 14.01.14 Join Sajber^ [0] (~Sajber@h-65-75.A213.priv.bahnhof.se) 14.01.54 # * kugel is scared by ffmp3.com 14.03.20 *** Saving seen data "./dancer.seen" 14.08.49 Quit AndyI (Ping timeout: 248 seconds) 14.11.23 Join GeekShado_ [0] (~Antoine@185.189.204-77.rev.gaoland.net) 14.11.32 # * Bagder talked to the friendly people in #ffmpeg-devel 14.11.46 # I'll post a follow-up on the mailing list on that 14.12.40 Quit linuxstb (Ping timeout: 245 seconds) 14.13.55 Quit GeekShadow (Ping timeout: 265 seconds) 14.14.06 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 14.16.05 # Torne: so you feel all useful now? :) 14.17.20 # gevaerts: heh, it's nice to know that somoene cares 14.17.33 # and it might encourage me to implement more of the missing features sooner 14.17.46 # and if jd gets multifont to work.. ;) 14.18.36 # S_a_i_n_t_: I was intending to use it as a platform to actually develop menu/button based games 14.18.53 # S_a_i_n_t_: e.g. things with JRPG-style combat 14.19.08 # so, text based, but not text adventures in the usual sense 14.19.24 # or, choose-your-own-adventure style things 14.19.34 # there are various libraries for inform that help to do some of that 14.19.36 # kugel: Are you sure saratoga complains about our mp3 decoder? I thought he was happy with it, especially as he has made it dual-core. I know he (and anyone else who has looked at it) complains about libfaad (the AAC decoder), are you perhaps confusing them? 14.19.38 # and i was going to maybe write some more. 14.20.09 # thus it might eventually be possible for people with limited programming ability to write certain kinds of games for rockbox :) 14.21.48 Join AndyI [0] (~pasha_int@212.14.205.32) 14.22.43 # linuxstb: yes, dual core makes it fast on PP, but not on the rest of the targets 14.23.08 # I thought preglow took care of that long ago? 14.23.12 Quit Rob2222 (Quit: Rob2222) 14.23.59 # mp3 is slower than wma and ogg on the rest 14.25.29 Quit AndyI (Read error: Connection reset by peer) 14.26.13 # so maybe ffmpeg's codec is an idea after all 14.27.55 Quit piotrekm (Quit: piotrekm) 14.28.06 Join AndyI [0] (~pasha_int@212.14.205.32) 14.30.06 Quit Tuplis (Quit: hetkinen...) 14.30.15 # Torne: ok...so what am I doing? OF reports the battery is charged, so I connect under RB and see if RB thinks it's charged (after some minutes) also? 14.32.58 # yeah 14.33.08 # it might sag slightly from 100% while you reboot to RB 14.33.15 # so you might have to give it a sec to finish topping up the battery 14.33.19 # success! 14.33.23 # but it should hopefully report charged within a short time 14.33.26 # commit away 14.33.39 # Well, that sounds good to me :) 14.33.50 # me too ;) 14.33.58 # the behaviour of the code in svn is already identical to the past patches for this issue 14.34.04 # so the only change needed is to actually turn monitoring on. 14.34.16 # i shall do it momentarily :) 14.34.42 # thanks man...you made a feature of my wps...and cabbie actually, actually work! 14.35.07 # does this mean i gt a spot in the credits? 14.35.08 # jk 14.36.24 # that, (the monitoring thing) sems WAY too obvious a thing for the ammount of people that "apparently 14.36.44 # looked at it" to miss...o? 14.36.56 # well those FS# all had various people propose fixes 14.37.24 # but i would assume that the intersection between "people who could test it" and "people who are committers" and "people who noticed the FS# entries" was probably empty :) 14.37.48 # ahhhh...then came me :) 14.39.11 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 14.39.31 # I *still* (and probably forever will) find it *really* cool that this Nano was a first to do something :D 14.39.44 # * S_a_i_n_t_ pats his trusty 1g Nano affectionately 14.39.51 # New commit by 03torne (r24581): Enable charging monitoring for the Nano 1G. ... 14.40.16 # and scours at the bits of his coffee-ridden 2g 14.40.19 # grrrrr. 14.45.05 Quit shaggy-h (Ping timeout: 240 seconds) 14.46.52 Quit linuxstb (Ping timeout: 260 seconds) 14.50.59 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 15.09.35 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.15.04 Quit S_a_i_n_t (Disconnected by services) 15.15.57 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 15.15.59 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.0.240) 15.16.52 Quit HBK (Read error: Connection reset by peer) 15.17.40 Quit antil33t () 15.17.56 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 15.21.08 Join Tuplis [0] (~jani@adsl-77-109-221-158.kymp.net) 15.21.50 Quit linuxstb (Ping timeout: 245 seconds) 15.22.19 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 15.22.35 Quit HBK (Read error: Connection reset by peer) 15.23.11 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 15.26.04 Quit HBK (Read error: Connection reset by peer) 15.26.09 Join KBH [0] (~hbk@HBK.broker.freenet6.net) 15.26.54 Quit kugel (Ping timeout: 265 seconds) 15.27.11 # how often does "viewers.config" change...realistically? Despit the "don't edit viewers.config" thing, I have, and wonder how often I need to update/or bother to check to update it. 15.27.46 # why do you need to edit it in the first place? 15.28.13 # it's included in the build zip, so "every time you install a new build" 15.28.26 # to get viewers icons working in the "Open With list" 15.28.31 # ...a cheap workaround 15.29.50 # viewer icons in "Open With" are applied incorrectly, or not at all...editing viewers.config is a cheap fix for that. 15.30.10 # S_a_i_n_t: according to SVN, it is changed every ~2 months average 15.30.15 Join HBK- [0] (~hbk@HBK.broker.freenet6.net) 15.30.32 Nick HBK- is now known as HBK (~hbk@HBK.broker.freenet6.net) 15.30.47 # Aha....so "not very often" or, "when/if I notice something breaks" 15.30.49 # thanks. 15.31.03 # the changes are usually just new plugins 15.31.39 # yeah, I'm probably the only one with icons for Frotz :D 15.32.36 Quit HBK (Read error: Connection reset by peer) 15.32.43 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 15.33.04 Join Rob2222 [0] (~Miranda@p4FDCB472.dip.t-dialin.net) 15.33.25 Quit KBH (Ping timeout: 258 seconds) 15.33.41 # the last change of it was the addition of Frotz, btw :-) 15.34.43 # even though I use "open with" very rarely, I *hate* seeing things in there with black squares or no icons at all...so I bypassed that untill someone with brains finds a propper/the correct/ fix. 15.34.49 Quit HBK (Read error: Connection reset by peer) 15.35.04 # that's one of the things that made me notice it :D 15.35.14 # *frotz that is 15.35.32 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 15.35.54 # New commit by 03FlynDice (r24582): Sansa Clip+: Unset B0 correctly in dualboot.S 15.36.18 # Not that I don;t have brains myself, I'm just not a coder...I could probably have a stroke and be a better coder than I am now. 15.36.38 # then do something about it :-) 15.36.50 # what? have a stroke? 15.36.51 # :P 15.36.57 Quit HBK (Read error: Connection reset by peer) 15.37.00 # * S_a_i_n_t knew what you actually meant :D 15.37.01 # well, if that helps? ;-) 15.37.38 # One of my problems is trying to learn too many languages (coding) at once 15.37.47 # I should just stick with C 15.37.56 # but I get distracted VERY easily 15.37.57 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 15.38.05 # * TheSeven shoves that discusson to #rockbox-community 15.44.30 Join vegtoruci [0] (~vegtoruci@pool-96-246-120-217.nycmny.east.verizon.net) 15.46.56 Quit HBK (Read error: Connection reset by peer) 15.47.25 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 15.48.14 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 15.48.46 Join KBH [0] (~hbk@HBK.broker.freenet6.net) 15.50.28 Quit KBH (Read error: Connection reset by peer) 15.51.02 Join KBH [0] (~hbk@HBK.broker.freenet6.net) 15.52.12 Quit HBK (Ping timeout: 258 seconds) 15.52.33 Quit evilnick_B (Quit: Page closed) 15.55.01 Quit KBH (Read error: Connection reset by peer) 15.57.46 # is someone here who understands the subtrack handling in nsf ? 15.58.40 # i understand that it switches subtracks on trackskips if you are in repeat-one mode. but there is also internal playlist handling which i dont understand. 15.58.56 # i want to use the same/similar subtrack handling for the asap codec. 16.03.22 *** Saving seen data "./dancer.seen" 16.03.23 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 16.03.26 Join HBK [0] (~hbk@rrcs-97-77-49-215.sw.biz.rr.com) 16.04.33 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 16.06.06 # New commit by 03teru (r24583): time menu: stop scrolling before leave the screen. 16.21.01 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.22.15 # saratoga: i assume you mean *testing* on beast? also i'm still not really clear on how you would be able to use the 16x16 and 16x32 multiplies without losing accuracy... surely multiplying by constants truncated at 16 bits will introduce errors at around that precision 16.24.36 # there's a ? missing somehow... the other thing you might want to know about is that if you're making any use of smull or smlal and discarding the bottom word of the result, armv6 can do that without producing the low word in a register, and with the same throughput and latency as mul/mla 16.24.51 Quit grndslm (Remote host closed the connection) 16.25.25 Quit Zarggg_ (Read error: Connection reset by peer) 16.34.16 Quit AndyI () 16.37.21 Join captainkewlllll [0] (~2669ecc2@gateway/web/freenode/x-sfhkmlohslcqebov) 16.41.53 Quit Tomis (Ping timeout: 252 seconds) 16.42.48 Join AndyI [0] (~pasha_int@212.14.205.32) 16.48.01 Join Tomis [0] (~Tomis@70.134.90.242) 16.48.23 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 16.53.54 Quit Tomis (Read error: Operation timed out) 16.54.13 Join Tomis [0] (~Tomis@70.134.83.103) 16.55.11 Part watto 16.59.13 Quit Bagder (Quit: It is time to say moo) 17.01.03 Join watto [0] (~watto@193.203.81.165) 17.01.28 Join jgarvey [0] (~jgarvey@cpe-071-070-228-143.nc.res.rr.com) 17.15.11 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.19.21 Part evilnick_B 17.19.24 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 17.20.15 Quit Zagor (Quit: Clint excited) 17.25.44 Quit AndyI () 17.26.00 Quit robin0800 (Remote host closed the connection) 17.31.36 Join AndyI [0] (~pasha_int@212.14.205.32) 17.32.15 Quit S_a_i_n_t (Quit: [St.] has exited mIRC™) 17.42.24 Part watto 17.45.03 # * TheSeven might have spotted why the channel swapping is happening 17.46.32 # will a pcm_more_callback_type always return an even number of samples? 17.46.45 # (i.e. always start with the left channel) 17.47.26 Join watto [0] (~watto@193.203.81.165) 17.47.33 Quit linuxstb (Ping timeout: 265 seconds) 17.48.17 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 17.49.36 Join pamaury [0] (~pamaury@ALyon-551-1-36-230.w80-9.abo.wanadoo.fr) 17.53.16 Quit linuxstb (Ping timeout: 246 seconds) 17.53.45 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 17.54.55 Quit Sajber^ (Read error: Connection reset by peer) 17.55.21 Join Sajber^ [0] (~Sajber@h-65-75.A213.priv.bahnhof.se) 17.57.02 Quit teru (Quit: Quit) 18.01.28 Quit n17ikh (Ping timeout: 260 seconds) 18.03.24 *** Saving seen data "./dancer.seen" 18.04.44 Quit petur (Quit: work->home) 18.06.09 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 18.10.20 Join komputes [0] (~komputes@ubuntu/member/komputes) 18.19.40 Quit HBK () 18.21.49 Quit AndyI () 18.23.27 Quit togetic (Quit: WeeChat 0.3.0) 18.24.04 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-uxeftoofekqjpbkk) 18.24.14 Join togetic [0] (~togetic@unaffiliated/ibuffy) 18.25.28 Quit togetic (Client Quit) 18.25.42 # linuxstb: without dual core (AMS, Gigabeat, Nano2G) libmad is probably slower then libfaad 18.25.55 # but yes, I complain about libfaad a lot ;) 18.26.04 Join togetic [0] (~togetic@unaffiliated/ibuffy) 18.27.14 # i suggested this as a possible GSOC project: http://www.rockbox.org/wiki/SummerOfCode2010#MPEG_Codec_Optimization 18.30.51 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 18.33.55 Join AndyI [0] (~pasha_int@212.14.205.32) 18.37.22 Join desowin [0] (~desowin@atheme/member/desowin) 18.37.39 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.38.02 # android seems to have grown a bit since you created that gsoc ideas page 18.38.51 Join Zarggg [0] (~zarggg@2001:0:4137:9e74:0:4388:beb1:ba3d) 18.41.45 Join petur [0] (~peter@d54C6F9B2.access.telenet.be) 18.41.45 Quit petur (Changing host) 18.41.45 Join petur [0] (~peter@rockbox/developer/petur) 18.42.47 # AlexP, nice to see your clip battery bench 18.43.03 # bertrik: Yeah, it wasn't bad 18.43.54 # Seems odd that you and I got much higher than the other one there 18.46.54 # yes, indeed, especially because runtime seems to be normal in the OF 18.47.13 # I'm trying to look into that, but it's a bit hard to get a grip on it 18.47.31 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) 18.49.44 # yeah, I can imagine 18.49.45 Quit archivator (Ping timeout: 245 seconds) 18.50.54 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 18.52.42 # bertrik: are you still looking at meizu's these days? i have an unused m6sl that would love to get a new life like my nano2g did after getting rockbox 18.53.36 # topik, I'm not really active lately for the meizus. I do have a M6SP and a borrowed M3, but not an M6SL that I can work on 18.54.32 # i read on the forum thread you had quite some progress 18.55.01 # the main firmware for the m6sl probably does not compile, but you can probably get the bootloader compile with a limited amount of work, the display does not work at all yet AFAIK 18.55.30 # i tried to compile the bootloader and meizu_dfu but both didn't 18.59.27 # fair amount of m6sp stuff in the s5l8700 files, but not much m6sl 19.04.55 Quit bluebrother (Disconnected by services) 19.04.56 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 19.05.12 Join DumbSpammer [0] (~re@AntiLiberal-1-pt.tunnel.tserv9.chi1.ipv6.he.net) 19.06.18 Join Casainho [0] (~chatzilla@87.196.59.58) 19.09.21 Mode "#rockbox +o gevaerts" by ChanServ (ChanServ@services.) 19.09.32 Kick (#rockbox DumbSpammer :you know why) by gevaerts!~fg@rockbox/developer/gevaerts 19.10.02 Mode "#rockbox -o gevaerts" by ChanServ (ChanServ@services.) 19.10.22 # gevaerts: No ban? 19.10.36 # Bagder: would you mind deleting that from the logs? 19.10.42 # he probably won't come back anyways 19.10.43 # A good idea 19.10.46 # AlexP: I don't know. If he comes back, yes 19.10.57 # and yes, I think that should be removed from the logs 19.11.02 # TheSeven: I know, but principle - if you come in just to spam then instant ban 19.11.19 # AlexP: feel free 19.11.23 # nah :) 19.11.34 # as he is probably doing that on a lot of channels, one might want to contact freenode staff 19.13.16 # B4gder: you too 19.21.12 # topik: meizu_dfu builds fine here 19.21.29 # from the dir it is in? it complains about missing usb.h for me 19.21.43 Quit FlynDice (Remote host closed the connection) 19.21.56 # you're missing libusb-dev then 19.22.35 # good point. it compiles rightaway now 19.22.46 Join JdGordon_ [0] (~836b006a@gateway/web/freenode/x-iqqcwanrpzgvehlr) 19.27.21 Join Strife89 [0] (~michael@168.16.237.214) 19.27.27 Quit kugel (Quit: exit(0);) 19.28.00 Quit pamaury (Ping timeout: 264 seconds) 19.30.30 Quit togetic (Ping timeout: 265 seconds) 19.31.08 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.41.52 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 19.42.49 # New commit by 03b0hoon (r24584): Packard Bell Vibe 500: Improve/fix scrollstrip scrolling. The idea was taken from the ipod's clickweel source. 19.45.35 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 19.45.42 # Hello 19.46.06 # hi piotrekm 19.46.26 # if you have time, i would like you to test some things regarding the lcd issue... 19.46.35 Join Tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 19.46.44 # i might, i suppose 19.47.16 # one quick question before: is the "tsst" (short white noise) on the beggining of track playback a nano2g-specific issue? 19.47.22 Join fml [0] (~53ecea55@giant.haxx.se) 19.47.43 # JdGordon: ping 19.48.14 Quit Farthen (Disconnected by services) 19.48.22 # TheSeven: any special instructions for today, or should I just re-download the files? 19.48.35 Join Farthen_ [0] (~chatzilla@e179234137.adsl.alicedsl.de) 19.48.37 Nick Farthen_ is now known as Farthen (~chatzilla@e179234137.adsl.alicedsl.de) 19.49.05 # i would first have a check if this also happens when the lcd init code is run through ibugger 19.49.06 Quit vegtoruci (Ping timeout: 240 seconds) 19.49.11 # that would ease debugging 19.49.38 # ok, so first i'll reboot to linux 19.49.42 # i'll prepare an image for you soon, need to fix something first 19.50.22 # JdGordon: (for the log) if, as we know now, the font cache only stores the glyph codes and not the glyphs bitmaps, wouldn't it be better to just have one glyph cache for all fonts? Why do we need separate caches? 19.50.44 # well yeah 19.50.48 # although, maybe not 19.51.02 # I origionally thought it does store the glyphs bits which is why I did it this way 19.51.10 # TheSeven: Anyway, I'll be back in about 40minutes. 19.51.19 Quit piotrekm (Quit: piotrekm) 19.51.32 # with more than one font loaded, its likely that their used glyphs wouold be different 19.51.57 # one mighyt only be used for numbers, anther might only be used for text 19.52.10 # and then there's the possibility of windings :p 19.52.16 # http://forums.rockbox.org/index.php?topic=23863.msg161967#msg161967 <- interesting picture as it shows a daughterboard with an "M5" marking. I suppose it's an X5V then (without the radio) but don't know if the loose wire has to so with it and if it should be this way 19.52.32 # JdGordon: it's not unlikely. But on the other hand, it's very likely that the sets will be roughly the same. Chars are used for displaying text after all. 19.53.02 Join vegtoruci [0] (~vegtoruci@pool-96-246-120-217.nycmny.east.verizon.net) 19.53.17 # yes, so I might go back and simplify that completly 19.53.34 # probably change it to only cache the user font and not bother at all with the skin fonts 19.54.17 # JdGordon: I think we can cache all fonts, no need to handle the UI font in a special way. 19.54.54 # New commit by 03b0hoon (r24585): Packard Bell Vibe 500: Enable ATA DMA as in r24405. 19.55.00 # are you talking about the .glyphcache file? or the actual in ram cache? 19.55.09 # New commit by 03kugel (r24586): Bubbles: Don't save scores when quit without saving is selected and reduce splash duration 19.57.31 # JdGordon: both 19.57.33 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 19.57.36 # what is gained by combining the glyph cache? combining means being potentially wrong and destroying the per-font glyphcache 19.57.51 # (I mean the .glyphcache files) 19.57.52 Quit FlynDice (Remote host closed the connection) 19.58.30 # the on disk cache is tiny, so the only reason to not use a seperate one for each font is to cut down on junk files 19.58.46 # the inram cache NEEDS to be seperate because the bits are actually stored there 19.59.47 # JdGordon: aha! Then we need separate caches indeed. Disk space doesn't matter 20.00.01 # the inram cache could be combined 20.00.21 # it can, but the gain isnt worth it 20.00.27 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 20.00.27 # it just needs a font index in the lru nodes, and it actually has an unused field 20.00.39 # isn't worth what? 20.00.47 # that doesnt work when each font has different glyph sizes 20.01.01 # ?? 20.01.04 # the wait and the effort and the extra ram usage 20.01.06 # kugel: the entries would be of variable size which is not supported now 20.01.36 # kugel: since the bits are also inside 20.01.58 Quit evilnick_B (Quit: Page closed) 20.02.00 # it is supported 20.02.23 # kugel: I don't think so 20.02.23 # the lru node has a data pointer and a size field 20.02.57 # archivator: I'm test-compiling things now. There are a few keypad issues that i need to look into 20.03.22 # kugel: ok, if you really want it done that way then go for it, in the mean time, my way works, and is almost ready, and we dont have to deal with issues of dropping X glyphs to make room for Y other fonts glyphs 20.03.27 *** Saving seen data "./dancer.seen" 20.03.45 # kugel: and how is that data managed? It has to be of a const size 20.04.10 # JdGordon: yea, but with constant disk spinning because 10k seems pretty low 20.04.22 # hardly 20.04.34 # (I havnt tested on target yet) 20.04.52 # 10k is how many 12x12 glyphs? 20.05.08 # 1000/(12x12/8) ? 20.05.12 # 70 or so 20.05.34 # thanks, so easily enough for most people's secondary font 20.05.50 # 55 actually 20.06.27 # fml: why? 20.06.41 # That's not a lot 20.07.08 # rasher: for the secondary font? its plenty 20.07.17 # How do you figure? 20.07.18 # even if its closer to 45, still plenty 20.07.21 # kugel: look at the code. It's handled as an array, i.e. fix sized entries 20.07.25 # Ahem. 10k would be 10000 20.07.48 # It's entirely plausible that the secondary font will be needing the same glyphs as the main font 20.08.01 # But then, plain /8 is incorrect either, as the bitmaps cannot contain fractional bytes 20.08.02 # waaaaaaaaaah! 20.08.04 # ok, 568 20.08.05 # I can imagine the user fonts are used for bigger fonts so that the menu font isn't too huge, then 12px is a bad estimate 20.08.07 # someone broke nano2g playback! 20.08.25 # amiconn: that would mean (16x12)/8? 20.08.31 # yep 20.08.39 # ok, 426 then 20.09.00 # 10k is a number I pulled fairly randomly, we can increase that if its feeled we need to 20.09.10 # ok 400 glyphs IS plenty 20.09.23 # 140 glyphs for a 24x24 font 20.10.06 # I wouldn't underestimate the overhead from the cache management either 20.10.07 # That's too much IMHO 20.10.38 # it could probably be 10% less due to that 20.10.39 # kugel: with a few lines of code we can get exact numbers 20.10.52 # 10% of 426 is still only 42 20.11.03 # worst case is 300 20.11.06 # or 100 20.11.29 # fml: the RAM being used for fonts is preallocated for skins anyway so its not a waste 20.12.02 # JdGordon: ok then 20.13.16 # has anyone looked at the latest patch? should I simplify it and move the skin_font_*() stuff into firmware/fonts? 20.14.04 # the only downside doing that is a fwe extra font structs in firmware/ but it should make the code ismpler 20.14.35 Quit amiconn (Disconnected by services) 20.14.37 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 20.14.45 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 20.14.45 Quit pixelma (Disconnected by services) 20.14.59 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 20.15.00 # fml: you seem correct 20.15.02 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 20.15.24 # CC apps/codecs/asap.c 20.15.26 # make: *** No rule to make target `/home/theseven/rockbox-trunk/apps/codecs/libasap/anylang.h', needed by `/home/theseven/rockbox-trunk/build/nano2-app/apps/codecs/libasap/acpu.o'. Stop. 20.15.35 # make veryclean 20.17.15 Quit archivator (Ping timeout: 245 seconds) 20.18.24 # JdGordon: I wouldn't handle fonts diferently at the firmware level. Make them equal. A font just gets a buffer for storing its cache. The caller must care about the buffer. Then the font buffer can be in the skin buffer or in the playback buffer (if we want it that way) or... 20.19.22 # Imo the proper solution would be a single font buffer for all fonts 20.20.01 # JdGordon: one font is special in the sense that it's the UI font and has its buffer in the core rockbox. Other fonts get the buffer from the skin. This can be changed later without changing the firmware. 20.20.04 # I agree, but nobody is going to do it, and JdGordon's approach seems good enough 20.20.33 # * amiconn disagrees 20.20.58 # At the firmware level, all loadable fonts should be equal 20.21.00 # kugel: I think with the energy and speed JdGordon has it will be done in two, no, one hour 20.21.12 # fml: so yeah, thats how I've done it now, but its got a vit too much special handling for the ui font 20.21.40 # This is important on devices with more than one display 20.22.02 # amiconn: you mean all but the system (inbuilt) font? Then I fully agree. 20.22.03 # I agree that one buffer is better, but noone has done it and looks like they are going to 20.22.12 # * JdGordon_ totally forgot about multiple screen fonts :p 20.22.16 # Each display should be able to set its own ui font. That's in fact what's annoying me most 20.23.07 # I don't really need more than one font per display, but the single font for all lcd gets annoying, especially if there's a large difference in lcd size 20.23.37 # Think e.g. H300 main and remote, or even more obvious m:robe 500 and remote 20.23.39 # amiconn: ..which is always there 20.25.14 # JdGordon_: markun said that he did a bit of work on the font caching. Unfortunately he didn't get around to committing it 20.25.15 # so I'm tempted to duplicate the user font handling for the remote (and just make sure the right FONT_UI is loaded for the display if the fonts are different), that wll double the buffer usage 20.26.54 # one buffer pretty much means coming up with a way to get entries of differing size into it 20.27.04 # yes 20.27.24 # which is what has been the problem the whole time 20.27.35 # also coming up with a good buffer size to use 20.27.45 # The single buffer method has advantages if the theme has some special-use fonts 20.27.49 Join moos [0] (moos@rockbox/staff/moos) 20.28.15 # i'd say maybe something like what buflib does - there's a table of offsets to the actual buffer items (quick access, one extra indirection vs direct array lookup) but the buffer items themselves are of arbitrary sizes. 20.28.27 # Think e.g. of an fm theme for users not caring about the station name. It would use a huge font for frequency display 20.28.37 # actually it's not an offset table, but a pointer table 20.28.55 # Of that huge font, only the digits, '.' and maybe 'M', 'H' and 'z' are needed 20.29.06 # Unhelpful: that doesnt solve the problem of figuring out which glyphs to drop to make room for a different one 20.29.48 # Unhelpful: The pointers also cost 4 bytes extra per entry. But sure, it would probably already be an overall gain with a medium-sized proportional font 20.29.53 # i.e you dont want to just drop the oldest one which is larger than the needed space, that one might be really really frequently used 20.30.17 # amiconn: that's what i'm thinking, a proportional font will rather quickly save when it caches narrow characters 20.30.21 # JdGordon_: You just drop from oldest to newest until you have enough free space 20.30.32 Join stooo [0] (~sto@f051006239.adsl.alicedsl.de) 20.31.13 # and the buffer size? 60K is obviously too small 20.31.31 # buflib could also be reworked a bit to support unaligned data - right now it's 32-bit aligned so 1) users never have to worry about allocation alignment 2) each item has a pointer to its table entry for easy update on compaction 20.31.32 # 100K? probably too small for people that want 3 fonts, too big for those that only want one 20.31.32 # why? 20.32.54 # 60K is how much we allocate now for one font, so it stands to reason that it's not enough for 2+ 20.32.59 # amiconn: and after each drop you compact the buffer? 20.34.12 # Yes, I think that's necessary 20.34.36 # wont that get very slow? doing lots of memcpy? 20.34.40 # JdGordon_: I'd assume that if people use more than one font, in many cases the extra fonts will be used for only a few words 20.34.41 # You might also track gaps and only compact if no large enough gap is left, but that tracking might be too much overhead 20.35.11 # JdGordon_: It needs memmove. Compared to the disk access, this memmove is blazingly fast 20.35.17 # gevaerts: agreed, which is why I did 10K not the full 60K 20.35.29 # Btw, on lowmem swcodec the font buffer is 10k, and on archos even just 4k 20.36.01 # I would make that depend on lcd size. Larger lcds are likely to need larger fonts, hence a larger font buffer 20.36.07 # So we'd need yet another mini malloc 20.36.21 # why? 20.37.36 # amiconn: that's what buflib does already, compact-on-failure. also handles are allocated from the buffer so that there's not a fixed number of handles. 20.37.59 Join phanboy4 [0] (~benji@gate-20.spsu.edu) 20.38.01 # hmm 20.38.13 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 20.38.41 # search for allocation is done by walking the buffer items - since they each have an allocation size in their "header" they can be treated as a linked list. as an optimization a pointer to the lowest free buffer is maintained. 20.38.57 # so is this just all talk? if someone is actually going to do this then I'm happy to sit on my patch, but if its just going to stay talk (like it has been for years) then I dont see any reason to wait once my patch is ready 20.39.24 # archivator: I think I'll disable fft on touchscreen targets for now 20.39.50 # Unhelpful: Hmm. How does that perform if there are 1000 items or so? 20.40.20 # And does it reuse gaps? 20.40.22 Join piotrekm [0] (~pm@unaffiliated/piotrekm) 20.40.49 # JdGordon_: Imo getting that right is a requirement for multifont 20.41.39 # amiconn: it depends on how out-of-date the gap information is, and i've never really tried to benchmark or stress-test it. but the lower-bound pointer for a free buffer is updated on each allocation. the worst case is if an allocation uses all of the lowest-address gap, since this means that the lower-bound pointer will actually point to a non-gap 20.41.43 # gevaerts: I was actually considering dropping the current oscilloscope-inspired keymaps and try menu-based configuration... Shouldn't be too much work but I'm afraid it might make the plugin less usable 20.41.46 # I agree that a single buffer is better, but this same conversation happens at least once a year and there has been no movement 20.41.52 Join fleebailey33 [0] (fleebailey@unaffiliated/fleebailey33) 20.41.54 # hello again 20.42.05 # TheSeven: no i'm availabe 20.42.11 # archivator: I'm about ready to commit, with a note that keymaps need more work 20.42.13 # i primarily optimized it for fast retrieval rather than allocation, but the allocation should be quite speedy in the typical case 20.42.26 # Tell me if I should wait 20.42.32 # * amiconn thinks we need more devcon-like hacking sessions 20.43.07 # gevaerts: no, by all means, commit it. I don't have time to do any serious refactoring right now... menu-based config was just a thought.. 20.43.32 # gevaerts: oh, and thank you :) 20.44.05 # the same optimization is used in the handle table, so that allocating a free handle starts with the lowest possible handle number 20.44.20 # New commit by 03gevaerts (r24587): New plugin: FFT, A frequency analyzer plugin ... 20.45.52 # archivator: if you could work on a manual patch, or at least a bit of text, that would be very welcome! 20.46.23 # euw, typedefs :( 20.46.33 # gevaerts: I'll see what I can do. I've never touched LaTeX though :( 20.46.59 # kugel: imported code 20.47.08 # hm 20.47.35 # archivator: we probably need a line in CREDITS for that external code 20.47.46 # if it's imported, why are there no (c) headers? 20.48.59 # "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution" 20.49.03 # uhm 20.49.26 # where are you seeing that? 20.49.41 # ok, standard BSD apparently 20.49.52 # yes, it is. 20.49.55 # kiss_fft.c 20.51.05 # archivator: did you lack a malloc()? we have one for codecs and plugins 20.52.03 # kugel: I don't remember ever needing a malloc but I could be forgetting something. What do you have in mind? 20.52.29 # How do we handle credits for single-person projects where the author didn't contribute directly? The main name list, or the team list at the end? 20.52.34 # I saw some #define *_MALLOC mallic and #define *_FREE free, so I just though 20.52.36 # thought 20.53.16 Quit flydutch (Quit: /* empty */) 20.53.31 # gevaerts: I think we add them to the people's list, that's what happened with the timestretch feature 20.53.38 # ok 20.54.16 # if someone doesn't want to be named he shouldn't release code to the public :) 20.54.21 # New commit by 03gevaerts (r24588): Add Mark Borgerding to CREDITS, for kiss_fft which is used by the fft plugin 20.54.54 # well actually, the license says we have to add him if I read it correctly :) 20.55.14 # kugel: I didn't put too much effort into cleaning that library. I think the OPENMP stuff is still there.. 20.56.05 Part watto 20.56.15 # I also saw "this kiss fft can't use malloc" in a .c file 20.56.38 # kugel: Ah, yes. I remember now. It's not that it can 20.56.47 # 't but rather that I didn't want it to. 20.57.48 # the library in its current form does not depend on core rockbox but only on the fp_sincos implementation. i wanted to confine all dependencies on core rockbox to the actual plugin. 20.58.13 # our malloc isn't core :p 20.59.38 # gevaerts: Could you quick-check something on your D2? 20.59.45 # sure 20.59.57 # (APE, testing just -c2000 and -c3000 is sufficient) 21.00.01 # kugel: then I must have been seriously confused :) In any case, malloc isn't really needed - the allocation was made static as the size of the transform was fixed at compile time 21.00.25 # I want to make sure the armv5te does actually behave as described before doing more complex stuff 21.00.33 # Want a patch or a build? 21.00.36 # well, your patch was maybe longer on the tracker than the time we have it 21.00.39 # a patch is fine 21.01.12 # gevaerts: is this fft plugin (it's great tirst of all) meant to have some config, refresh time for example? i wonder if it's only because of the unbound keys 21.01.13 Quit TheSeven (Read error: Connection reset by peer) 21.01.30 # piotrekm: ask archivator 21.01.35 # piotrekm: no, not really. It refreshes as often as it gets data. 21.01.37 # piotrekm: archivator can answer all questions about it! 21.01.40 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 21.01.42 # thanks 21.01.54 Quit Casainho (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115133306]) 21.02.06 # I wonder if it can also analyize line in stuff? 21.02.09 Quit fml (Quit: CGI:IRC) 21.02.23 # https://amiconn.dyndns.org/~jens/ape_armv5_sp_test.diff 21.02.55 # gevaerts: With this patch, APE should decode at the same speed or a little bit faster than SVN on D2 21.03.11 # (a bit faster due to more registers left for gcc to play with) 21.03.21 # TheSeven: in case the last message didn't arrive, i have some time now to test 21.03.24 Quit linuxstb (Ping timeout: 264 seconds) 21.03.48 # kugel: in theory, yes. I'm not sure how to switch between pcm output and line in mode. Can you record and have something playing at the same time? Sorry for the silly question, I've never recorded anything on a DAP.. 21.06.57 # piotrekm: i uploaded a file called ibugger.bin to my server, can you check if the lcd driver used by that works? 21.07.40 Quit stooo (Ping timeout: 245 seconds) 21.07.47 # if yes, get inithw.bin and run sudo python control.py upload 22000800 inithw.bin && sudo python control.py execute 22000800 22000800 21.08.04 # run that within ibugger *loader*, so don't run control.py startup before 21.09.01 # ok 21.11.32 # amiconn: playback is still fine, test_codec results as soon as I stop doing things wrong 21.11.53 # damn, just had another FTL crash 21.12.15 # You don't need to test correctness, I'm doing that on my beast (using the armv5 vector math of course) 21.12.37 # TheSeven: see a mandelbrot;) 21.12.49 # sounds like the driver works 21.12.52 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 21.12.56 # what does happen if you run inithw.bin? 21.13.07 # will do that in a moment 21.14.10 # inithw gave white screen 21.18.17 # amiconn: c2000 317%, c3000 213% 21.18.22 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 21.18.47 # Ah, very good. So armv5 actually behaves as described :) 21.19.03 # * amiconn starts working on the actual improvements 21.19.31 Quit kugel (Remote host closed the connection) 21.21.50 Quit linuxstb (Ping timeout: 245 seconds) 21.23.48 # archivator: we're about to add a very well optimized FFT to the library FWIW 21.24.46 # saratoga: I'm aware of that, I'm waiting for it to go upstream and I'lll switch to it (if it's meant to be used by plugins, that is). 21.25.43 Quit Tomers (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]) 21.25.44 # ok cool 21.25.51 # its in the mdct branch if you'd like to try it 21.26.27 # piotrekm: hm, not good 21.26.39 # but at least we can test it easily now 21.26.43 # saratoga: is the api stable? I.e., can I start switching to it now? 21.26.51 # TheSeven: does it mean something else than lcd init is broken? 21.27.29 # no, it probably is the lcd init, and we can now try to track the issue down 21.27.52 # ok 21.28.47 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 21.40.14 # archivator: its not even exposed to plugins at the moment, but if you add it to plugins.h I doubt anyone will change it now 21.40.41 # its actually just a function used by our new MDCT, so we didn't need to expose it 21.40.55 # i wouldn't worry too much, we can always do this later 21.41.32 # Right. I might work on this when I find the time (uni has been proving somewhat time-consuming :) ) 21.41.44 Quit FOAD (Ping timeout: 260 seconds) 21.42.08 # should be quite simple unless your fft is doing something special (reordering or scaling) 21.43.12 Join FOAD [0] (~dok@dinah.blub.net) 21.45.07 # saratoga: it's doing scaling at the end of each iteration to prevent overflow. Other than that, it's pretty much taken from the books verbatim. 21.47.15 # meh. i don't even get my nano to play back *anything* any more 21.47.24 Quit piotrekm (Ping timeout: 246 seconds) 21.49.01 Join piotrekm [0] (~pm@unaffiliated/piotrekm) 21.49.46 # TheSeven: you mean it's permanently broken? 21.50.18 # no, looks like somebody broke a bunch of things with a recent commit... 21.50.29 # and it's reacting really weird 21.50.45 # right now it failed to rolo a new build because of a checksum error? 21.51.05 # oops, and there suddenly is a file called "tagna6i.conf)g" 21.51.09 # i have the latest commit on mine and it works fine, with mp3s at least 21.51.12 # erm, wtf... 21.51.41 # well, i have enabled undervolting and boosting, but that was working fine before... 21.51.46 # *not latest, 24587 21.51.53 # TheSeven: disk corruption much? 21.52.13 # undervolting? 21.53.09 Join mt [0] (~mtee@rockbox/developer/mt) 21.55.22 Quit Strife89 (Quit: Going home.) 21.56.55 # Unhelpful: it also keeps prefetch/data aborting 21.57.55 Join froggyman [0] (~sopgenort@pool-72-69-210-48.chi01.dsl-w.verizon.net) 21.59.32 Quit phanboy4 (Quit: Leaving) 22.00.17 Quit ender` (Quit: 'And you have to shout -' He tried to remember some far-off reading. '- er, bonsai. Yes. Bonsai!' -- Terry Pratchett: Reaper Man) 22.03.31 *** Saving seen data "./dancer.seen" 22.14.23 # argh, that channel swapping issue is driving me mad 22.14.41 # i have files where it seems to swap like 5 times a second, and others that don't swap at all 22.20.55 # New commit by 03theseven (r24589): Fix iPod Nano 2G channel swapping issues 22.25.28 Quit archivator (Quit: Leaving) 22.25.32 # thanks TheSeven 22.27.57 # wow 22.28.02 # thanks TheSeven 22.29.56 Join Strife89 [0] (~michael@adsl-154-2-168.mcn.bellsouth.net) 22.33.40 # well, that was a trivial one 22.37.09 # TheSeven: you know that it also fixed the white noise appearance on the beginning of tracks? 22.37.41 # or not... i said that too early 22.37.43 Join Jaykay [0] (~chatzilla@p5DDC764A.dip.t-dialin.net) 22.38.42 Quit JdGordon_ (Ping timeout: 248 seconds) 22.38.44 # it's better than was anyway;) 22.39.04 # TheSeven: Can FS#10812 be closed? 22.40.33 Quit captainkewlllll (Quit: Page closed) 22.40.49 Join Buschel [0] (~ab@p54A3DCBE.dip.t-dialin.net) 22.41.21 # piotrekm: i never have noise at the beginning of tracks... 22.41.33 # strange 22.41.43 # AlexP: thanks, was digging through flyspray right now to find it 22.41.58 Quit mt (Remote host closed the connection) 22.42.06 # we really need a way to list all bugs for a given targetr 22.42.09 # target* 22.42.12 Join JdGordon_ [0] (~836b006a@gateway/web/freenode/x-xhpxrbgutegziryi) 22.42.19 # i get it in some albums, but when played on pc this doesn't occur 22.42.39 # Yeah - I was looking for that just now but it doesn't seem to appear in the advanced search bit 22.43.27 # piotrekm: i sometimes get parts of other tracks etc. played for an instant when skipping around 22.44.02 # B4gder: When you get a second could you put me so I can assign flyspray things to myself? I'm not in the list of people to assign things to and a couple of times I wanted to give myself things 22.44.30 # TheSeven: i think i wasn't precise again, this occurs only when one track ends and another begins, not if i manually skip 22.45.06 Quit Omlet (Read error: Connection reset by peer) 22.45.13 # AlexP: checking... 22.45.18 # ta 22.45.47 # AlexP: so you have no "assign to me" button then? 22.46.00 # oh, er, maybe - one mo :) 22.46.43 Join Omlet [0] (omlet05@49.145-242-81.adsl-dyn.isp.belgacom.be) 22.47.30 # B4gder: Sorry, yes - I didn't notice that and was trying to do it via the list when you edit the task :) 22.47.39 Quit Farthen (Ping timeout: 256 seconds) 22.47.48 # oh well, issue sorted then I guess! ;-) 22.47.52 # yep :) 22.48.12 # Not sure how I didn't spot that button - it is right next to close task which I use quite a bit :) 22.48.35 # you've been SO focused on that close! 22.48.41 # :) 22.50.23 # B4gder: is there any way to add the player type to the filter options in flyspray's advanced search? 22.51.53 # not that I know of, no 22.52.26 # (besides patching flyspray) 22.52.31 # right 22.52.38 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 22.55.55 # heh, I *think* I may have found a way to get rid of those boosting glitches 22.56.19 # what about just switching the ARM core to fastbus mode instead of tampering with the prescalers? 22.56.23 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 22.57.13 # TheSeven, I think that's what we do for the as3525 targets 22.57.27 Join Strife89|PalmTX [0] (~cstrife89@adsl-154-2-168.mcn.bellsouth.net) 22.58.08 # we may want to additionally clock down the system bus, but as soon as the cpu and the bus are using the same clock, I don't think the freqswitch will cause any issues 23.01.42 Quit Strife89|PalmTX (Client Quit) 23.03.57 # B4gder: what did the ffmpeg people want from us? 23.04.24 # wma, mdct and ape came up in the discussions 23.04.43 # I couldn't really comment on the details, as I don't know them... 23.04.46 # do you have the logs? 23.04.55 # i don't think they log their channel 23.05.14 # ehm, I don't right now as I did it from my other computer which is shut off atm 23.05.19 # ok 23.05.19 # We have a person called "Phinitnun Chanasabaeng" and another called "Pinitnun Shanasabang" in CREDITS. Are they actually different people? 23.05.44 # i've given merging our code a lot of thought and basically decided it wasn't practical, so i'm curious what they were thinking exactly 23.05.50 # saratoga: ask them, they're friendly and many in that channel ;-) 23.05.58 # haha thats not been my experience 23.06.32 # last time i asked the answer was something like "go away and stop forking ffmpeg" 23.06.43 # ouch 23.07.05 # although in fairness they were talking about AAC, and we don't even use their aac decoder, so the guy probably just didn't know what he was talking about 23.07.13 # maybe they didn't realise how serious you are about it 23.07.54 # the ffmp3 is a no brainer, and in fact its been proposed as a potiential GSOC project for this year 23.08.04 # the same for ffaac 23.08.10 # ok 23.08.16 # although they overestimate their improvements over libmad 23.08.25 # i think i saw 15% on x86 over libmad 23.08.28 # I somehow suspsected that 23.08.39 # which puts them somewhere around "astonishingly slow" 23.08.40 # they claimed ~50% 23.08.55 # you sure they didn't mean libfaad? 23.09.03 # yes 23.09.09 # they're about 50% faster then libfaad and people mix up it with libmad sometimes since they rhyme 23.09.28 # we explicitly talked about mp3 then so I'm quite sure 23.09.37 # FFmpeg: 22.3s libmad: 24.2s mpg123: 9.5s 23.09.50 # http://multimedia.cx/eggs/gcc-of-multimedia/ 23.10.00 Quit anewuser (Quit: Another edition of chiptune gig WinterChip5! :O http://xrl.us/WinterChipV =ooo) 23.11.31 # although they've obviously got some algorithmic improvements, so its worth seeing if we can steal them 23.11.56 # do they actually want their fixed point mdct back? 23.12.18 # i remember reasonably efficient fixed point mdcts being propose to them before and going no where 23.12.58 # i assumed they weren't interested 23.13.08 # they do, but I'm not sure for what purpose exactly 23.13.50 # hm, fastbus saves ~4mA 23.13.55 # mt's cook decoder is basically a dusted off set of patches for fixed point code in ffmpeg 23.14.01 # and no glitches any more :-) 23.14.05 # TheSeven: the arm9 bus mode? 23.14.14 # yep 23.14.26 # wow, nice! current consumption was already pretty low on the nano 2g, right? 23.14.30 # combined with his own rm parser and a lot of optimization of course 23.14.40 # 21/22 vs. 25/26 mA 23.14.50 # fastbus is where you run the clocks at integer multiples right? 23.15.21 # no, that's synchronous 23.15.31 # fastbus = arm runs at bus clock 23.15.58 # synchronous doesn't work for me, even when they are running at integer multiples 23.16.06 # so how do you boost? 23.16.17 # by switching between asynchronous and fastbus 23.16.20 # ah 23.16.27 # thats probably something we should check on ams then 23.16.33 # (and additionally clocking the bus down to 50MHz when in fastbus mode) 23.16.45 # how does IRAM work on the 2G? 23.16.57 # is it off the AHB or some special bus 23.17.03 # probably ahb 23.17.10 # it needs 2 cycles per access IIRC 23.17.19 # isn't the AHB really slow 23.17.33 # i thought its a 16 bit bus with multiple cycle access times 23.17.33 # AHB is 100MHz, ARM is 200MHz 23.17.45 # so that'd be no better then 4 clocks 23.17.52 # hm, iirc AHB is 32bit... 23.18.05 Quit _zic (Ping timeout: 245 seconds) 23.18.06 # but it may well be a different bus 23.18.16 # ah ok 23.18.39 # the one on AMS is either amazingly slow, or else the IRAM is really slow 23.20.55 # the as3525 calls AHB the "the advanced *high-speed* bus" 23.21.22 # the ARM9TDMI also says it has a fast 4 cycle multiplier 23.21.40 # trust nothing arm tells you 23.22.09 # I have no reason to believe it's slow 23.24.14 # oops, my nano is starving for cpu power, the menu is *very* sluggish, but it just doesn't want to boost (stays at 47MHz) 23.25.01 # but it's still playing back realtime, only had 2 little gaps during that track (mp3) 23.26.59 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 23.28.00 Quit GeekShado_ (Read error: Connection reset by peer) 23.29.39 # gevaerts: Could you test a new patch? This time with real speed improvements... 23.29.48 # sure 23.30.22 # http://amiconn.dyndns.org/~jens/ape_armv5_fused.diff 23.30.57 Quit Omlet (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 23.32.19 # Please test -c2000 and -c3000 speeds first. I expect around 7% speedup for -c3000. If that works, you could do a full test; this will be the final version except some #if 0'd junk 23.33.00 Quit piotrekm (Quit: Leaving.) 23.33.51 # * amiconn would be interested in the raw test_codec output as well, i.e. not rounded 23.35.55 # saratoga: well, average 4 cycles? 23.36.08 # * JdGordon_ points everyone to the mailing list 23.36.24 # pixelma: amiconn: any chance you can test the fm patch on hwcodec+rec soonish please? 23.36.46 # I'm at the pointt where its ready for commit 23.37.38 # amiconn: c2000 220.01% 23.37.47 # 330.01 that is 23.39.25 Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) 23.39.40 # amiconn: c3000 220.92 23.39.48 # rasher: domonoky: does anything need to be done for the theme site to accept fm skined themes? or will they just work (but not verify them) untill magic scripts are fixed? 23.40.16 # JdGordon_: it will accept them. 23.40.47 # to get them verify i just need to add extensions (if checkwps takes them without problems) 23.41.36 # checkwps shouldnt have any problems, I dont tihnk it checks extensions 23.41.43 # does the theme site verify the .cfg? 23.42.29 Quit Buschel () 23.43.54 # JdGordon_: just to clarify once more, "coming from the skin buffer" is talking about the skin usage, right? i.e. if it gets added to the plugin API, plugins would provide the RAM? 23.44.37 # gevaerts: right now, no plugins would use the skin buffer also 23.44.57 # but thats something that can change 23.45.13 # gevaerts: That's in fact reasonable. When estimating, I didn't take the other stages into account 23.45.25 # So filter speedup is ~9%, as it should be 23.46.02 # the problem with passing extra buffers in is what happens when a plugin loads font A, and something else also loads font A? right now A is only loaded once and not unloaded untill both unload it. but if the first buffer points into the plugin buffer it will break 23.46.10 # that shouldnt ever happen though 23.46.13 # Could you please do the other compression levels as well (including -c1000 - sometimes shifting code around changes speed due to cache influences) 23.46.56 # amiconn: running now. It just started on c5000. I'll pastebin the output file once it's done 23.47.03 # JdGordon_: right now it's not exported, so there is of course no issue :) 23.47.13 # thx 23.47.22 # JdGordon_: no it doesnt check the config at moment. 23.47.35 Join pamaury [0] (~pamaury@ALyon-551-1-36-230.w80-9.abo.wanadoo.fr) 23.47.48 # I see your point, but what if a WPS uses the full buffer, and then a plugin starts? Does the WPS get reloaded afterwards? 23.47.52 # that is a todo for the future. is there are list of allowed settings for themes ? 23.48.04 # gevaerts: yes, but even when it is, the skins are the only things loading fonts, and that cant happen when a plugin is running (simply because it uses the plugin buffer to read the skin file :) ) 23.48.13 Quit pamaury (Client Quit) 23.48.39 Join pamaury [0] (~pamaury@ALyon-551-1-36-230.w80-9.abo.wanadoo.fr) 23.48.48 # domonoky: no, but the list is fairly static so if its just a file in svn we can update it as needed 23.49.06 # JdGordon_: ok, so a plugin can never fail to load a font because a the user happens to like complex wpses? 23.49.35 # it can now, 23.49.59 # yeah, so plugins do need to pass in a buffer somehow 23.50.09 Quit domonoky (Read error: Connection reset by peer) 23.50.49 # I think so, yes 23.51.15 # Apart from that, I agree that a multi-buffer approach now is better than a nice single-buffer appoach in three years 23.52.17 # also, with a sufficiently complicated theme a plugin could fail to load a font because the theme uses up all the font slots 23.52.39 # unless we can come up with a better way of storing the font pointers 23.53.15 # If possible, I'd look for a way for plugins to have their own font slots and only share the two main ones 23.54.04 # or we could restrict font slots per user 23.54.09 # so we use a callback for the lcd drivers to get the font from the plugin? 23.55.37 # hm, yes. The lcd drivers shouldn't really have to know about plugins... 23.56.27 # maybe we just up the font slots to something like 20 and assume noone will be able to fill that 23.56.38 # 17 avialable for the apps/ layer ought to be plenty 23.57.23 # I'd reserve a few explicitely for plugins then 23.57.43 # how many? 3? 4? 23.58.01 # * amiconn thinks this sounds more complex than a single font buffer 23.58.17 Quit pamaury (Quit: abort();) 23.58.39 # amiconn: yes, but unless someone actually says they are going to code it then this is what we have 23.58.45 # 3 or 4 is plenty, yes. The only plugin that we know really wants more fonts just needs one more after all 23.58.50 # also, seperate buffers means less likelyhood of cache thrashing