--- Log for 12.02.110 Server: wolfe.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 9 hours and 9 minutes ago 00.01.41 # what's the best way to svn sync a branch with trunk? 00.01.41 # anyone here on ubuntu? 00.02.10 # pixelma: do you think the new tags all make sense? I'm happy to add/remove/change as needed, and we shold get them mostly good before commit 00.02.17 # pamaury: sounds good 00.02.21 # I'm thinking of just copying all the latest files from trunk over the top of the (stale) files in my branch and doing a massive svn commit. But, that won't handle any stale files in my branch that have since been deleted from trunk right? 00.02.49 # pamaury: pictureflow has a similar problem, it uses fill_tags() but not find_index() 00.03.12 # has anyone asked ohloh to fix up their enlistment? B4gder ? 00.03.12 # would be nice if you could tell how much faster find_index() compared to get_metadata() is 00.03.21 # kugel: so it doesn't work when db is not in ram ? 00.03.37 # pf calls get_metadata() if fill_tags fails 00.03.54 # ok 00.04.37 # checker - is your WPS issue something to do with ubuntu? (I don't see the connection myself) 00.04.38 # although find_index() also uses ramcache when it's enabled. if you need the index only I'd just use that in the first place 00.05.29 # i added a file in to a .zip using the ubuntu archive manager, then unpacked the .zip onto my gigabeat, now i have problems :P 00.05.35 # checker - if your rockbox basically works fine, but shows 'BM6' on the screen, then maybe your wps contains just the text "BM6" perhaps? If on the other hand your rockbox is crashing, you probably need to tell us more info... 00.05.46 Quit JdGordon_ (*.net *.split) 00.05.46 Quit saratoga (*.net *.split) 00.05.56 # checker - unfortunately this is #rockbox not #ubuntu-archive-manager-bugs .. :( 00.05.59 # JdGordon_: haven't looked into detail. I first thought it was a bit much maybe they are all needed (thought I remembered a discussion about reusing artist etc. tags but at the same time I remember being unable to decide if e.g. a station name equals artist or album) 00.06.19 Join JdGordon_ [0] (~836b0052@gateway/web/freenode/x-netztotbusamhqac) 00.06.19 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-uxeftoofekqjpbkk) 00.06.26 # is there a way to get the fmr name (without the full path)? 00.06.29 # checker - why didn't you just copy the file to your gigabeat? (why add it to the zip and then unpack the .zip onto your gigabeat?) 00.06.47 # you could just restore the original zip file, and then just copy your updated file over, no? 00.06.59 # because luckily, i tested the .zip before uploading it to the theme site 00.07.16 # ah, theme zip. ok. (now we're getting somewhere :-) 00.07.22 # pixelma: the fmr is the presets file yeah? you want to display it on the skin or use it somewhere else? 00.07.24 # wps... 00.08.04 # JdGordon_: display it in the skin 00.08.22 # checker - so, um - you made a bad theme zip and now it doesn't work. how do we help? 00.08.36 # ... you dont 00.08.38 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 00.08.41 # but I need to get a basic one to be loaded first :\ 00.08.46 # i have a little eabi compilation problem (nano 2g target), and would be gratful for help - http://pastebin.ca/1794048 00.09.00 # checker - I'd like to, just not sure how .. 00.09.01 # stripwax: sweet mdct ;) 00.09.07 # mt - thanks! :) 00.09.16 # what would a .zip to a file that would cause it to bug 00.09.25 # mt - any ideas on how to sync the whole branch to trunk? 00.10.11 # New commit by 03tomers (r24611): fft plugin: add touchscreen key-mapping and enable plugin for touchscreen targets 00.10.43 # checker - sorry, I can't understand the question... (was it missing a verb?) 00.10.55 # do 00.10.55 Quit shaggy-h () 00.11.03 # ah 00.11.03 # pixelma: I'll add it, it shuold be easy enough to get to 00.11.07 # stripwax: We're going to use this mdct from now onwards, right ? (i.e, the old one is going to be dropped now?) 00.11.24 # checker - well, you could always unzip it onto your ubuntu machine and see if the contents match what you thought they would be? 00.11.57 # mt - there's at least one more thing to do - get rid of the awful fft initialisation (revtab) 00.12.27 # checker - e.g. using diff, etc. 00.12.46 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) 00.13.31 # mt: ping 00.13.39 # or just rebuild the zip file from scratch and start again (making sure that the files you zip up are correct to begin with). I don't think there's inherently something bad about a .zip file that could corrupt a file and/or make rockbox freak out with a weird wps, unless the files in the zip are just faulty. (But I can't speak for ubuntu archive manager) 00.14.01 # tomers: ping 00.14.10 # reply from ohloh staff was damn quick, we shuold be getting updated again 00.14.11 # file wasnt, the zipper somehow messed up the encoding on it, fixed now 00.14.27 # encoding on the .wps file 00.14.40 # JdGordon_: ugh sorry, I misspelled the actual file name of the fms. It loads now... 00.15.08 # so BM6 means the encoding is incorrect on the .wps :P 00.15.17 # JdGordon_: on the M5 00.15.27 # but ondio is totally blank? 00.15.37 Quit checker (Quit: CGI:IRC) 00.15.53 # checker - "BM6" isn't an error message. It probably means that the first printable characters in the wps are B, M, and 6. 00.16.07 # (if it's messed up the encoding, that's possible, certainly) 00.16.29 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 00.16.39 # * stripwax could be wrong, but usually rockbox error messages have words in them, and has never seen a wps error like that. JdGordon can probably confirm .. ? 00.17.10 # yea, BM6 is a error in the wps text 00.17.15 # or mistake 00.17.57 # FlynDice: pong 00.18.17 # mt: did you see my forum reply? 00.18.23 # JdGordon - as in, rockbox shows "BM6" if your wps is garbaged? are there any other "BM" error messages? 00.18.28 # * stripwax learns something new 00.18.40 Quit anewuser (Quit: Another edition of chiptune gig WinterChip5! :O http://xrl.us/WinterChipV =ooo) 00.18.54 # no, the wps text has an error which doesnt break the parser but displays that as text 00.19.03 # JdGordon_: yes, Ondio shows a blank screen (there was no file name error on that one, I just checked again) and it also showed a blank screen with the default while no fms was set 00.19.06 # stripwax: What's the problem with syncing ? (I'm thinking of just copying what we did and apply the changes by hand then commit, if so, I can do that tomorrow) 00.19.13 # FlynDice: I'll check 00.19.50 # mt - syncing FROM trunk TO branch. how do we make branch less-stale 00.20.00 # kugel: pong 00.20.10 # pixelma: ok, thats wierd, I cant tihnk why nothing shows, except if the skin load is inside a !HWCODEC block, which would be bloody stupid :p 00.20.16 Quit kramer3d (Quit: Leaving) 00.20.20 # mt - including deleting files from branch that are no longer in trunk 00.20.52 # JdGordon - as in the .wps file probably has some garbage in it including a string that looks like BM6 - right? 00.20.59 # yes 00.21.08 # JdGordon - phew, cool. 00.21.10 # JdGordon_: uhm, no comment :P 00.21.13 # * petur updates a tracker entry of 2006 with a new patch 00.21.18 # heh 00.21.32 # mt: have you tried holding the pwr button for 10 secs or so to reset I need to head out be back in 30 mins 00.21.35 # FlynDice: Yes I tried a long power-button press to reset it, but it didn't work. 00.21.53 # stripwax: Sorry, misread your words. 00.21.55 # * pixelma should be careful after making own stupid mistakes 00.22.21 Quit petur (Quit: Zzzzz) 00.22.30 Quit Adnyxo (Quit: Leaving) 00.22.34 # JdGordon_: just throwing out an idea - could there be something wrong with viewport ("colour") handling? 00.22.44 Quit moos (*.net *.split) 00.22.44 Quit Sajber^ (*.net *.split) 00.22.44 Quit DerPapst (*.net *.split) 00.22.44 Quit ranmachan (*.net *.split) 00.22.45 Quit Topy44 (*.net *.split) 00.22.51 Part domonoky 00.22.57 # mt - not ready for trunk yet, as I'm unhappy with the fft init. mdct should be totally stateless in my opinion and tables should be constants really 00.23.02 Join DerPapst [0] (~DerPapst@p4FE8F3E1.dip.t-dialin.net) 00.23.12 Join Sajber^ [0] (~Sajber@h-65-75.A213.priv.bahnhof.se) 00.23.18 Join moos [0] (moos@rockbox/staff/moos) 00.24.03 # maybe we just don't bother sync branch yet.. that's probably easier anyway. 00.24.10 # hmm... and what about RFMSs btw.? 00.24.15 Join ranmachan [0] (ranma@yumi.tdiedrich.de) 00.24.19 # stripwax: svn merge? 00.24.39 # pixelma: well, I thought of that a while ago, but isnt the ondio mono? 00.24.41 # kugel - that works across branch/trunk? neat! 00.24.50 # sure it's meant for that 00.25.01 # JdGordon_: it is 00.25.03 # kugel - ah, great! 00.25.13 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 00.25.16 # OH.. um.. 00.25.24 # does the inbuilt on use viewports? 00.25.27 # * JdGordon_ cant remember 00.25.58 Join Topy44 [0] (~topy@my.fastsh.it) 00.26.15 # which "one"? 00.26.30 Quit Adnyxo (Remote host closed the connection) 00.26.37 # the hardcoded one 00.26.53 # if it does then its probably failing to load because of extra garbage on the %V line 00.26.59 # hardcoded FM screen, or something else? 00.27.16 # yes, that one 00.27.24 # apps/recorder/radio.c 00.27.46 # New commit by 03tomers (r24612): fft: fix red 00.27.53 Quit Schmogel (Read error: Connection reset by peer) 00.28.01 # no, it doesnt 00.28.29 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 00.28.36 # I still use custom_statusbar.sbs there (and already went back to a patchless build now) 00.28.41 Quit pamaury (Quit: abort();) 00.29.05 # pixelma: can you build checkwps for the ondio and pass the inbuilt one to it? maybe its using a bad tag 00.29.57 # http://pastebin.com/m94f4c85 00.30.15 # http://pastebin.com/m60ed0a62 00.30.21 # the first one is missing a > 00.30.25 # don't know, haven't used it so far. How do I do that? 00.30.58 # ok, new plan 00.31.43 # ok.. build checkwps (its one of the configure options for the target) 00.31.57 # then just ./checkwps.ondio filename.fms 00.32.04 # the first past is correct, not the second 00.32.21 # can you have %pm in a conditional? 00.32.32 # I thought it had to be on its own line 00.32.58 # why are the colons in the language strings? 00.34.10 # you could still get the same effect with conditional viewports (the %pm/prerecord info) 00.34.19 # that's nasty! 00.34.29 # (the colon thing I mean) 00.35.27 # yeah, unnecessary 00.35.48 # and might hurt if you want to use it in a different way 00.36.02 # (the colons) 00.36.09 # kugel: to make RTL langs easier to deal with 00.36.22 # iirc anyway 00.36.59 # pixelma: oh, it doesnt like %pm? ok hmm 00.37.16 # and we cant use conditional viewports here because it should work inside the ui viewport 00.37.19 # wherever that is 00.37.25 # haven't checked but that's what I always thought 00.37.32 # for RTL? really? 00.37.54 # pixelma: exactly, I would like to do it in a different way 00.40.37 Quit JdGordon_ (Quit: Page closed) 00.41.51 Join checker [0] (~621342a9@giant.haxx.se) 00.44.59 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 00.46.51 Quit checker (Quit: CGI:IRC (EOF)) 00.48.44 # hrm, svn merge sounds easy but I imagine it would cause a few problems here. I'll just wait until branch mdct is "finished" and port it back into trunk 00.49.16 # you need to merge in trunk anyway 00.49.19 # mt - one thing, then, to do is to move the remaining codecs to using the newmdct if they're currently using the old tremor mdct. Would you have time to look at that 00.49.32 # otherwise you mess up trunk 00.49.39 # kugel - true, or could make the (small handful of) changes manually no? 00.49.57 # sure, but that means losing versioning 00.50.08 # I can't imagine which problem svn merge would cause 00.50.10 # ah. true 00.51.07 # kugel - well, it seems like svn doesn't track the merges, and that you have to manually tell it which revisions to merge diffs from. which sounds like a bit of a manual headache if a) the merge goes wrong or b) I specify the wrong revisions 00.51.16 # building checkwps fails in firmware/export/debug.h for me. Since the patch doesn't seem to touch this file, my guess is "maybe cygwin?" 00.51.26 # I'm not a hardcore svn user, so if it's easy I'll happily let someone else do it :) 00.51.28 # stripwax: Sure. will look at that tomorrow. 00.51.30 # depends on the version. newer svn tracks merges 00.51.37 # oh, neat-o 00.51.41 # newer = >1.5 I think 00.51.42 # mt - cool! 00.52.25 # it's possible that you need to specifiy the revision for the first merge, but I doubt you need it after then 00.52.28 # kugel - so I could just "svn merge trunk branches/mdctexp" with no other args and it would know what it is supposed to merge with what? 00.52.42 *** Saving seen data "./dancer.seen" 00.53.01 # you could just try. you do the merge locally so nothing really bad can happen anyway 00.53.12 # kugel true 00.53.40 # and on that note, goodnight .... 00.54.04 Quit stripwax (Quit: http://miranda-im.org) 00.55.28 Quit togetic (Read error: Operation timed out) 00.55.52 Quit Tomis (Read error: Operation timed out) 00.57.28 Join Tomis [0] (~Tomis@70.134.86.166) 01.00.28 Quit bmbl (Quit: Bye!) 01.05.00 Quit amiconn (Disconnected by services) 01.05.01 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 01.05.17 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 01.05.18 Quit pixelma (Disconnected by services) 01.05.23 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 01.05.29 Quit FlynDice (Remote host closed the connection) 01.05.35 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 01.07.02 # New commit by 03tomers (r24613): fft: fix yellow 01.07.20 # kugel: your blacknblue_glass theme seems to be odd with current svn 01.07.39 Quit Tomis (Read error: Connection reset by peer) 01.08.10 # sbs elements seems to be missing 01.08.26 Join Tomis [0] (~Tomis@70.134.86.166) 01.10.06 # kugel: I would think that the colons are part of the lang strings for (non-latin) language where using a colon would be unusual or even wrong 01.10.17 # *languages 01.10.35 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 01.11.06 # * amiconn would not expect colons in e.g. chinese or korean 01.11.14 # kugel: http://img140.imageshack.us/img140/4802/dump100212010736.png 01.11.21 Quit tomers (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20100106054534]) 01.12.03 Join komputes [0] (~komputes@ubuntu/member/komputes) 01.12.04 # note playback is stopped and it doesn't stop the progressbar 01.12.12 # perfectdrug: there's no sbs 01.12.28 # oh 01.12.40 # so it is from your other theme still? 01.12.42 # the blacknblue glass for e200 is a tad bit outdated. it doesn't have the relevant lines for deactivating the sbs 01.12.57 # yea, leftover 01.12.59 # which i loaded before 01.13.19 # I wanted to update it today which was the reason I messed with the download counter :) 01.13.47 # yes and your mention made me try your theme out :D 01.14.00 # :p 01.15.20 Part toffe82 01.17.28 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 01.19.56 # JdGordon: save theme settings produces "sbs: /.rockbox/wps/-.sbs" instead of "sbs: -" for no sbs, is that right? 01.23.17 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 01.32.20 Quit dmb (Ping timeout: 252 seconds) 01.40.57 # JdGordon: it's going to be a busy night, but what did you want? buflib-related stuff? 01.48.32 # perfectdrug: should be updated now 01.49.08 # New commit by 03mc2739 (r24614): Turkish translation update ... 01.51.03 Quit saratoga (*.net *.split) 01.56.19 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-uxeftoofekqjpbkk) 01.59.10 # kugel: helvR10.fnt is renamed in the font package 02.00.08 # Unhelpful: no, 02.00.12 # AA question 02.00.21 # JdGordon: shoot :D 02.00.45 # is there anything in playback which would cause things to break if you try getting an AA in the fm screen, so audio is stopped? 02.00.54 # it looks like it shouldnt, but its apparently causing problems 02.02.00 # JdGordon: i'm not completely sure how AA is retrieved for rendering.. i only know about loading :/ 02.02.13 # bah, ok 02.04.32 # but, no, i can't imagine why it ought to break, surely this is similar to wps while playing a track with no AA? 02.05.02 # i guess the first question is, "how does it know what the buffer handle for the AA is?" 02.05.30 # right, it should be getting -1 or something because there is no aa 02.07.34 # perfectdrug: argh, thanks 02.10.14 Quit Sajber^ (Read error: Connection reset by peer) 02.10.48 # kugel: i can imagine a lot more themes are outdatet this way, but no one notice because they have the old fonts still around, i guess "works with 3.5" or checkwps doesn't check against this 02.11.21 # no, because it could be a custom font as well 02.12.19 # yes but then it has to be included 02.12.30 Join moos_ [0] (moos@85-171-102-158.rev.numericable.fr) 02.13.08 Quit moos (Ping timeout: 258 seconds) 02.13.10 Nick moos_ is now known as moos (moos@85-171-102-158.rev.numericable.fr) 02.16.01 # perfectdrug: should be good now :/ 02.17.19 # JdGordon: well, doesn't the albumart load function fail? 02.19.33 # looks fine now:) 02.19.58 # strangely the update function didn't work 02.28.29 # kugel: what is the cross icon for it is always on and looking at your wps it is for crossfade, but you just declare 4 modes and not 5 02.29.32 # amiconn: if we made the audio buffer a buflib (with some extensions), and we wanted to use buflib for a more flexible glyph cache, i imagine that would have its own buffer and allocator? 02.31.29 # my idea regarding dynamic plugin buffer was that the plugin buffer would still have a fixed start or end address, and would be allocated by moving one end or the other of the main buffer 02.31.31 # perfectdrug: is there a new mode? 02.32.00 # i don't know I'm looking at the customwps site 02.32.06 # it's off here 02.32.27 # it should be for crossfade yes 02.32.46 # Unhelpful: No own allocator 02.33.18 # hrm? so each glyph would be a buffer object also? 02.33.19 # it doesn't seem to go on actually 02.34.06 # "Automatic Track Skip Only" is new according to customwps history 02.34.23 # yea, blue_dude added it some weeks ago 02.34.38 # although perhaps buflib-as-buffer ought to be proven on its own before any worry is given to buflib glyph cache and plugin buffer 02.35.15 Quit DerPapst (Quit: Leaving.) 02.37.22 # i guess i was mainly thinking that the glyph-cache buffer will fragment much more quickly than the main buffer, and need compaction far more frequently. 02.37.38 # Unhelpful: as I understand: buflib would only provide the audio buffer, the buffering within that buffer would still be managed by buffering.c? 02.38.05 # kugel: *something* like that, maybe? ;) 02.38.38 # i don't think we're able, now, to move the buffer of the currently-playing track, are we? 02.39.25 # kugel: %?xf<|%xdv|%xdv|%xdv|%xdv> fixes it 02.43.09 # strange, it's never on here 02.45.52 # i have a clean build i formated 3 hours ago and always uninstalled your theme before testing a new one 02.46.20 # nevermind, works now 02.46.38 # * kugel is too lazy to upload it again 02.47.03 Join Tomis2 [0] (~Tomis@70.134.86.166) 02.47.08 # will do tomorrow 02.47.16 # the fuze's version has the same issue then, I guess 02.47.25 Quit Tomis (Read error: Connection reset by peer) 02.47.26 Nick Tomis2 is now known as Tomis (~Tomis@70.134.86.166) 02.50.44 Quit piotrekm (Quit: Leaving.) 02.52.45 *** Saving seen data "./dancer.seen" 02.55.13 Quit komputes (Remote host closed the connection) 02.58.46 Join Rob2223 [0] (~Miranda@p4FDCA0BC.dip.t-dialin.net) 03.02.00 Quit Rob2222 (Ping timeout: 240 seconds) 03.03.54 Join Strife89 [0] (~michael@adsl-154-22-187.mcn.bellsouth.net) 03.12.29 Quit FlynDice (Remote host closed the connection) 03.14.49 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 03.15.06 Quit Tomis (Read error: Operation timed out) 03.15.44 Quit FlynDice (Remote host closed the connection) 03.16.19 Join Tomis [0] (~Tomis@70.134.86.166) 03.18.57 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 03.19.04 Join togetic [0] (~togetic@unaffiliated/ibuffy) 03.20.47 Quit Casainho (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115133306]) 03.21.29 Quit Tomis (Read error: Connection reset by peer) 03.22.24 Join Tomis [0] (~Tomis@70.134.103.151) 03.23.31 Quit ______dmb (Read error: Connection reset by peer) 03.24.31 Join dmb [0] (~Dmb@unaffiliated/dmb) 03.27.58 Quit MethoS- (Read error: Connection reset by peer) 03.29.12 Join TopyMobile__ [0] (~topy@f048167247.adsl.alicedsl.de) 03.31.35 Quit TopyMobile_ (Ping timeout: 264 seconds) 03.41.24 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 03.41.41 Quit Adnyxo (Ping timeout: 258 seconds) 03.49.36 Part froggyman 03.59.34 Join dmb_ [0] (~Dmb@unaffiliated/dmb) 04.00.18 Quit saratoga (Ping timeout: 248 seconds) 04.09.16 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 04.13.07 Join checker [0] (~621342a9@giant.haxx.se) 04.13.34 # anyway to load a progress bar vertically? or even better, radially? 04.14.26 Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) 04.18.16 Quit phanboy4 (Read error: Connection reset by peer) 04.18.47 Join kadoban_ [0] (~mud@cpe-24-93-17-195.rochester.res.rr.com) 04.18.51 Quit kadoban (Write error: Broken pipe) 04.21.06 Quit TheSeven (Disconnected by services) 04.21.19 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.21.25 # checker: not yet 04.21.30 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.21.40 # New commit by 03mt (r24615): Add support for Sony OMA file format. Currently only supports ATRAC3 (without DRM), and seeks. Tested on sansa ... 04.22.10 # radially is "better"? 04.22.39 # yeah id say so 04.22.44 # looks cooler at least :P 04.23.46 # by radially you mean what, an arc? a pie-chart sort of circle thing? either is wasting rather a lot of space :/ 04.24.33 # circle, can surround a button 04.24.54 # but vertical is more practical 04.25.44 # .gif support would be best :D 04.27.21 # not really, with a bar we can easily show as much resolution on the progress bar as the space allows. with a gif we only have X frames. 04.27.50 # a gif that loads the same as the .bmp currently does 04.28.50 # it'd add a little life to it 04.29.16 # i'm not even sure what you mean by that. :) 04.29.50 # surely "loads the same as a bmp does" would not give you any new options 04.29.50 # for the progress bar, basically imagine a .gif file loading the same way as they do now. 04.30.08 # by load, i mean how it loads the image as the time progresses 04.30.15 # Now we beat VLC in OMA playback. B) 04.30.40 # so, you'd get what, the ability to *animate* the completed portion of the progress bar? 04.30.57 # no, it would be animated as it loads 04.31.49 # you could make a vista-like shine shoot across it for example 04.32.38 # http://www.romanw.com/progress_bar.gif check that out, 04.32.40 # ... i'm still not really sure what you mean. so we'd load an animated gif, and draw a *portion* of it based on the amount played, and that portion would cycle through the frames of the animation? 04.33.05 Quit mt (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]) 04.33.19 # yes cycle through all frames of animation, but only the correct portion (based on time), is visible... 04.34.18 # well, good luck convincing anybody that we need that :) 04.34.45 # lol, im just saying its better than a radial progress bar :P 04.36.32 # ...yes, but the progress bar we have now is also better than radial. it presents information. and you can make it a color or graphic. also updating the LCD repeatedly to run an animation will kill batteries. 04.37.24 # for some people, action on the screen is more desirable than excess battery life 04.37.45 # the .gif would also present the same information 04.37.59 # and you could make it a color or graphic :P 04.38.52 # then go ahead and write a gif loader and progress bar animator :) 04.39.07 # would i had half a clue as to how 04.42.18 Join Barahir_ [0] (~jonathan@gssn-5f7549a1.pool.mediaWays.net) 04.45.35 Quit Barahir (Ping timeout: 252 seconds) 04.47.28 Quit antil33t (Read error: Connection reset by peer) 04.47.33 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.254) 04.48.15 # hey St., thanks again for checking that .wps, works great now :) 04.48.32 # no problems man :D 04.48.36 # happy to help 04.48.56 Quit piroko (Quit: Reconnecting) 04.49.10 # and it does look good...I'll have to admit that, even *before* I fixed it up I could see it looked quite nice 04.49.14 Join piroko [0] (~jeremy@pohl.ececs.uc.edu) 04.49.20 # now it looks nice, and works :-P 04.49.26 # lol yes 04.50.32 Quit checker (Quit: CGI:IRC) 04.50.41 Join checker [0] (~621342a9@giant.haxx.se) 04.51.10 Quit checker (Client Quit) 04.51.19 # Added FS#11000 <--- "slightly annoying kill you almost instantly" sky/terrain drawing issue in plugin/game chopper.rock 04.52.47 *** Saving seen data "./dancer.seen" 04.54.12 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 04.54.51 # S_a_i_n_t: screenshot? :D 04.55.07 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 04.57.20 # perfectdrug: I'll try and pull off a screenshot from the simulator (assuming the SIM has the same error (fingers crossed)), but my timing would need to be pretty bloody good lol, so no promises :-P 04.58.10 # thats what i thought, just a joke, but if you can manage fine:) 04.58.25 Join Recursive [0] (~Recursive@173-23-120-113.client.mchsi.com) 04.58.39 # Am I correct in the understanding that you can just format an ipod and then use ipodpatcher to install a new apple firmware image? Instead of going through the mess around with having to use iTunes (and not having to install iTuens again actually... :P) 04.59.09 # Is there any project that supports alternative OS's on the iPod Nano (3rd generation, the fat one), or has it not been hacked at all yet? 05.00.33 # perfectdrug: I figured it was a joke...there a *wee* hint of sarcasm there, but I actually think I *may* be able to do it if I get someone else to play chopper on the sim and hover over "PrtScr" myself waiting to strike :-P 05.02.31 # ah ok and i figured there was "a *wee* hint of sarcasm there" also:) good night 05.02.45 # Hello? 05.02.58 # Recursive: no 05.03.10 # Recursive: Well, there is no Rockbox port for it yet...if that's what you're asking. 05.03.19 # snap! 05.03.25 # Yeah, but I'm asking if there's anything for it 05.03.33 # Googling around suggests it hasn't been cracked 05.03.53 # that would be offtopic here 05.04.14 # Yeah, but where else am I going to ask? 05.04.29 # that's hardly a reason to ask here? 05.04.37 # * S_a_i_n_t suggests google 05.05.42 # BING 05.06.03 Quit perfectdrug (Quit: perfectdrug) 05.06.09 # you could always "ask Jeeves" too :P 05.06.57 Quit AndyI (Ping timeout: 248 seconds) 05.07.18 # Is there some app that will dump button events? 05.07.31 # Like 'xev' for rockbox? 05.08.20 # ranmachan: i don't think so... and i'm not even sure how you'd do that, the available buttons are different on each target. 05.09.50 # pixelma: oh crap, the rec sim shows the fms which means its a target problem :< 05.16.02 # Unhelpful: so whats the current issues with buflib? did you read the logs before? is buflib in a state where we could do what we want? 05.16.59 # JdGordon: well, i suspect there are one or two places where its bufer gets corrupted. it currently lives in pluginlib. and i have no idea how we'd let a codec know that its buffer has moved. 05.18.01 # also buflib doesn't currently support the "give me all available space, i'll give back what i don't use" usage, but could do so fairly easily 05.18.25 # if it can shrink blocks then thats not really an issue 05.18.34 # even then we can work around it 05.18.51 # replacing every alloc system with a single one would be sweet though 05.21.39 # for buffer_alloc we'd want to add support for a group of contiguous, rarely-moved allocations at the start of the buffer, and specifically for collecting free space between those and other allocations in order to place a new allocation *there* instead of wherever it can fit 05.22.08 # * Unhelpful is pretty sure that no allocation resizing is implemented 05.23.25 # resizable buffer_alloc would also need a callback mechanism - if a buffer_alloc user generally assumes the buffer won't move, then a callback can be used when it *does* move, to fix up any pointers etc. 05.26.15 # not automagic behind the scenes resizing, but being able to explicitly say resize this handle to size X 05.26.28 # and there's the whole issue of moving the currently-playing file's buffer. on single-core this could be done just like buffer_alloc allocations, a callback in which the codec fixes all of its pointers. for multi-core the COP *must* be stopped and forced to update any of *its* pointers. 05.27.38 # JdGordon: i wasn't suggesting anything automagic... but if you have a stack of "static" buffers and the one on the bottom requests a resize, you can either move all of the others, or re-allocate that buffer somewhere else and create fragmentation (which you wouldn't be able to fix without moving those buffers around) 05.27.55 # right now buflib has no concept of a buffer you can't/shouldn't move 05.33.24 Join saratoga [0] (saratoga@dunes.bme.duke.edu) 05.33.44 Quit saratoga (Changing host) 05.33.44 Join saratoga [0] (saratoga@rockbox/developer/saratoga) 05.34.08 Quit yosafbridge (Quit: Coyote finally caught me) 05.34.15 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 05.34.37 # * JdGordon has a "which screen?" menu working for font loader 05.34.53 Quit yosafbridge (Remote host closed the connection) 05.35.09 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 05.35.26 Quit Horscht (Quit: Verlassend) 05.51.45 Quit evilnick (Ping timeout: 248 seconds) 05.56.08 # OK, I've figured out (from the wiki) that I definitely *can* install an .ipsw file using ipodpatcher...but my question is this, "when an iPod displays the crappy 'Restore using iTunes' message" is it necessary to format the disk (iTunes appears to do so)? I'd rather not loose all my music/data if I don't *have* to. 06.09.24 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 06.21.29 Quit kugel (Ping timeout: 240 seconds) 06.21.36 Quit kramer3d (Quit: Leaving) 06.21.51 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 06.25.30 Join podkast [0] (~bla@dsl-63-54.aei.ca) 06.26.16 # I saved my playlist in a .m3u file on my player but when i load it using rockbox, the order is randomized everytime i load the .m3u file... how do i keep it in the same order? 06.29.54 # turn off shuffle mode 06.30.27 # ah forreal thanks :) but how do i keep my playlist playing over and over, repeat -> all or shuffle? 06.31.50 # ok i got, its repeat all 06.31.55 # thanks! 06.41.21 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 06.42.49 Quit podkast () 06.46.22 Quit dmb (Read error: Connection reset by peer) 06.46.48 # * JdGordon is tempted to commit multifont already 06.52.50 *** Saving seen data "./dancer.seen" 06.56.27 Quit BHSPitMonkey (Remote host closed the connection) 06.57.50 # * S_a_i_n_t doesn;t see why not... 06.58.38 # is it still using 2, 3 , 4 etc. ? Or did you end up defining it some other way? 06.59.08 # * S_a_i_n_t hopes it's still numbers so he doesn;t have to redo his new WPS's again :P 07.09.52 Quit S_a_i_n_t (Quit: [St.] has exited mIRC™) 07.10.27 # yeah, it will stay numbers 07.10.33 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.254) 07.31.16 Quit S_a_i_n_t (Read error: Connection reset by peer) 07.35.25 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.75) 07.36.58 Part piroko 07.37.49 # the Recorder has no radio... ;) I'm currently compiling an OndioFM sim just in case 07.38.01 # the fm recrorder does 07.38.21 # but you didn't say so :P 07.38.30 # actually, have you got time to play now 07.38.31 # ? 07.39.40 # no, got to get ready for work. I can let my computer compiling in the meantime but testing would need more attention 07.39.47 # can you change apps/recorder/radio.c line 984 to just "if (1)" and try again 07.40.45 # thats the only line which could cause problems on target and not sim 07.40.57 # multifont also has only seen testers on Sansas and Ipods, right? Nothing with an lcd remote even? 07.41.27 # and no other architecture 07.41.42 # I just tried on h300+remote 07.42.15 # and i did the font for screen submenu thingy 07.47.26 # hmm... the radio screen works in the OndioFM sim but I first got crashes when going to the radio - with "bitmap too large for buffer: 45 bytes", unfortunately I haven't looked which theme was set before (built on top of a very old sim) 07.47.40 Quit liar (Ping timeout: 245 seconds) 07.48.04 # then its probaly not an issue 07.48.06 # but the skin buffer usage info was very weird anyways as it contained three lines 07.50.18 # what do you mean with "it" there? 07.50.54 # your whole comment there. if you copied ontop of a very old sim who knows what could have caused that 07.51.40 # ok 07.52.14 # * Unhelpful still likes the idea of flags/types of some sort for a "core" buflib, which may introduce other bits into the buffer header that the buflib "knows" about, and perhaps does something with 07.52.58 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 07.53.01 # for example there could be flags for things loaded from files, and for things with dimensions, and if either of those is set the buflib would check for an existing buffer object that matches :) 07.53.03 # of the shipped themes on the Archoses, iCatcher is the biggest wrt skin RAM usage and even if I load that, the radio screen shows now and doesn't crash the sim 07.53.50 # ok cool, so its only on target :/ 07.56.12 # this could lead to AA loading once per album and per size 07.57.26 # cool 08.01.05 # but... it would also require somewhere to *store* the flags field, although we could do something funny like limit length to 2^24 blocks and store flags in the low 8 bits of the size... otherwise every allocation would cost another 4B :/ 08.01.49 # 2^24 should be enough blocks... 08.02.10 # and do some sort of hash on the filenames and store that as extradata? 08.02.51 # well, we already store full filenames in the current buffer, don't we? i think they're part of the linked-list entry header :) 08.03.28 # we do? 08.03.42 # i thought we did? :) 08.04.23 Join dmb [0] (~Dmb@unaffiliated/dmb) 08.04.40 # yeah, struct memory_handle has a char path[MAX_PATH] field.. 08.04.51 # hmm 08.05.08 # lets start simple though :p 08.07.25 # yeah, refcounts and merging items are a bit much to start with... but i think that the initial version *should* have optional header fields that the audio buffer can use for the filename and such 08.07.51 # and then other things that are bufalloc'd save MAX_PATH bytes :) 08.07.59 Quit Recursive (Ping timeout: 256 seconds) 08.08.29 # how about a 4 byte extradata field which if anything needs more than that, stores another handle id? 08.10.42 # and the meaning of extradata is known only to the thing that allocated the item? 08.10.52 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 08.11.07 # yeah 08.11.28 # JdGordon: just realised that there is a big difference between this sim FMS and the target FMS (or how it should be). The sim doesn't show peakmeter or pre-recording. The info for drawing %pm is pulled from the MAS afaik , so not a big surprise it cam ne drawn correctly in the sim. There is a fake %pm for the WPS though but I don't know if there are differences between how radio/recording or playback draws the peakmeter and gets the info for doing 08.11.28 # so 08.12.02 # you got cut off, but yes, I know there is a difference 08.12.18 # which is why I've been nagging to get real testing on target 08.13.34 # JdGordon: so then the buffering code would be responsible for uniquifying files, if we want to do that later? and the extradata could hopefully be made optional somehow? 08.13.54 # * pixelma wonders how a %pm works in an sbs when in the radio or recording screen but has to postpone testing until later 08.14.12 Quit kramer3d (Ping timeout: 264 seconds) 08.14.29 # btw. I wasn't able to build checkwps so maybe you'll try that yourself 08.14.56 # * TheSeven is confused by mt's red 08.15.04 # is that a build system fluke? 08.15.28 # it doesn't look like one at the first glance, but i can't explain how it could happen otherwise either 08.15.37 # Unhelpful: we could do something like find_handle(callback) where the callback return true if the current handle is the one it wants? 08.16.13 # since when do we build the database as a lib? 08.16.20 # or binary even 08.16.52 # JdGordon: but then we would not only be walking the whole buffer to find a matching handle, but *also* calling a callback for each. :/ 08.17.26 # not if handles are given a user id or something, then only those are sent to the callback 08.17.26 # the target appears to *be* the standalone database tool? 08.18.22 # JdGordon: and that's even more data that might potentially be stored in *every* handle header :/ 08.19.01 # extradata is 4 bytes? 3 for a handle id, 1 for user id 08.19.04 # stuff like this makes me think even more that a buflib-glyph-cache ought to have its own buffer... so that every buffer walk doesn't hit a few hundred glyphs in the buffer, etc. 08.20.05 # we could even keep a linked list of a "users" handles 08.20.11 # or the user could 08.20.29 # how complicated do we want to make this? :D 08.22.19 # * Unhelpful hands JdGordon the Gloves. (http://thedailywtf.com/Articles/The_Complicator_0x27_s_Gloves.aspx) 08.23.58 # actually, buffering could initially allocate a list of handles-it-owns, and use that to do its own deduplication. and anything else that wants to could do the same. 08.25.06 # if we make allocations resizable there is no good reason that this list needs to be a linked-list, it can be a simple array :) 08.25.10 # hehe 08.25.41 # I only care about shriking, growing could be difficult 08.26.10 # wouldnt buffering store a linked list of handles anyway so it knows the correct order? 08.26.43 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 08.26.43 Quit Zagor (Changing host) 08.26.43 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.30.51 Nick kramer3d_ is now known as kramer3d (~kramer@unaffiliated/kramer3d) 08.39.42 # unless anyone has any major objections I'm going to commit multifont (10984) over the weekend 08.39.53 # if we decide its worth doing some optimisations that can happen after 08.39.58 # but I dont think its worth it 08.48.54 # JdGordon: buffering right now stores the information itself in a linked list, doesn't it? 08.49.30 # and growing wouldn't be terribly harder than shrinking - it should be very similar to compaction, as it's still a matter of moving existing allocations around. 08.50.27 Quit TheSeven (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]) 08.52.26 # * Unhelpful thinks the hardest problems will be mostly in doing this at all - making buffer_alloc allocations movable so that we can usefully clear or shrink them, making the currently playing track movable so that we can compact, and not just compact around, it. 08.52.52 *** Saving seen data "./dancer.seen" 08.52.54 # stuff like deduping track/AA buffers, or using buffer objects for glyph cache, is all just window dressing :) 08.58.59 Join flydutch [0] (~flydutch@host66-209-dynamic.15-87-r.retail.telecomitalia.it) 09.01.04 Join ender` [0] (krneki@foo.eternallybored.org) 09.11.19 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 09.15.13 Join petur [0] (~petur@rockbox/developer/petur) 09.44.32 Quit bmbl (Ping timeout: 252 seconds) 09.56.52 Quit CaptainKewl (Ping timeout: 260 seconds) 09.57.37 Quit mc2739 (Ping timeout: 252 seconds) 09.59.26 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 10.01.32 Join Sajber^ [0] (~Sajber@h-65-75.A213.priv.bahnhof.se) 10.29.32 Quit kramer3d (Ping timeout: 260 seconds) 10.31.38 Join LinusN [0] (~linus@rockbox/developer/LinusN) 10.37.15 Join _zic [0] (~user@91-165-229-6.rev.libertysurf.net) 10.44.50 Join watto [0] (~watto@193.203.81.165) 10.52.54 *** Saving seen data "./dancer.seen" 11.18.10 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 11.19.06 Quit Sajber^ (Read error: Connection reset by peer) 11.31.58 Join Zarggg_ [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 11.35.00 Quit Zarggg (Ping timeout: 240 seconds) 11.46.51 # gevaerts: you know that one of the proposed buflib uses is lots of small allocations/deallocations (glyph cache), right? ;) 11.48.48 # Unhelpful: yes, and I don't think that's a good idea :) 11.49.22 # although I might be wrong of course 11.49.39 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 11.49.46 # ah. reasons? the main problems i see are that lots of objects in buffer means possibly a long walk to find free space 11.50.21 # The problem I see is that basically we want as much RAM as possible for the audio buffer, so in a trivial naive implementation, each allocation means that another one has to go/shrink 11.50.24 # i don't think we'd see a horrible number of compactions happening if the glyph cache has its *own* buflib. 11.52.48 # the narrower the distribution in size of allocations, the more likely a recent free will fit a new allocation. otoh the audio buffer being fragmented by glyph cache abuse could mean quite a lot of compaction when a space can't be found for audio data and lots of tiny holes get squished together. 11.52.54 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 11.56.14 # of course the glyph cache will never be very big in total, so compaction should be reaonably fast if those bits are the only issue 11.58.15 Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) 11.58.41 # yes, but in the best case compaction is one call to memmove per hole, worst case one per allocation above the lowest hole. i think the latter is how buflib currently does it, and to be honest i'm not sure the former is an improvement - it would require a second walk through each segment of contiguous allocations to fix up all of their handles, and that would probably be less cache-friendly than moving each buffer and then fixing its handle, 11.58.41 # since that way we're always moving up the buffer. 12.00.26 # and i'm still not entirely sure how we will handle moving buffers that the COP accesses. although "COP never accesses buffer directly" might be feasible, if the COP threads can always be processing data that has come from some earlier calculation done on main core. 12.03.19 # I'd actually handle glyph cache using a two-layer system, i.e. give it its own pool 12.04.36 # that's pretty much what i'm suggesting, buffer_alloc some space for glyph cache, and run an allocator there. 12.06.02 # for codec COP use, I'm pretty sure that we can probably get away with "don't move the buffer that the codec is currently working with" 12.09.34 # if we make it a bit more flexible about how it finds space, i'd say definitely. things might get tricky in places - part of what i want to do is things like the ability to resize buffers that currently use buffer_alloc and can only be sized at startup, or to carve the plugin buffer out of the audio buffer on plugin startup and leave it for audio buffering when no plugin is running. these are both tricky and may *require* moving the 12.09.34 # currently-playing buffer, so i think we may need a method for that, but if it's called infrequently it won't be a big performance hit, and if it's usually the result of a user interaction, any skipping it might cause will likely go unnoticed. "oh, i made that happen" pretty much. 12.10.24 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 12.11.13 # we already see this if WPS AA size changes during playback... but right now it forces a rebuffer to do that, and that's much worse than possibly having to stall the codec briefly. 12.12.57 # resizing buffers doesn't have to mean moving a locked buffer, as long as you don't resize the locked one, and you assume that no buffer is larger than 1/3 of RAM 12.14.31 # at least I think it's 1/3. Maybe my numbers are wrong and it's 1/4, but I don't think that matters right now 12.15.21 # that doesn't help with the plugin buffer of course. I don't really see a good solution for that one 12.16.37 # gevaerts: i don't see how that would get you out of moving any specific buffer. the plugin buffer will be particularly tricky because unless we implement a relocating loader, it needs a fixed address. 12.17.58 # * gevaerts sees it, but he finds these things hard to explain :\ 12.18.08 Quit _zic (Remote host closed the connection) 12.19.10 # hm 12.19.23 # * gevaerts thinks that maybe it's hard to explain because it's not entirely correct 12.19.44 # Can I pile on more assumptions? 12.20.41 # the plugin buffer case i think makes it impossible to *always* avoid moving the current file buffer... since it could happen to overlap that fixed space. but a relocating loader has also been proposed, and would have other benefits (plugins could potentially short-call core functions, and at least would not have to load core function addresses from a table, among other things) 12.20.45 # are they reasonable? 12.21.05 # I don't know :) 12.21.23 # I'm not going to solve the plugin buffer right now, but I'll have a go at the others 12.23.25 Join MethoS- [0] (~clemens@134.102.106.250) 12.23.27 # If (a) you never resize the currently-playing buffer, (b) no single buffer is larger than half of the RAM that's used for audio (*including* buffers used for audio), and (c) you're allowed to drop (or shrink) not-actively-used audio buffers, I think you can do it 12.27.28 # (a) is only a requirement because obviously you can't resize the buffer that's at the end of the heap without moving it, and (b) and (c) together allow you to always find room for your resized buffer 12.28.30 # I think (c) is reasonable because without that you have to reserve space for non-audio allocations which defeats the point of the entire exercise 12.28.44 # I don't know how realistic (b) is 12.30.50 # by "resize" you mean "grow"? 12.31.27 # yes. Shrinking isn't very interesting :) 12.33.30 # (c) is a basic assumption of this whole plan, isn't it? the whole idea is that we can fill the buffer completely and then dump some audio when we load a bigger skin, or run a plugin that wants to grab some extra memory, or something like that. 12.34.20 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 12.39.23 # yes 12.47.15 Quit xavieran (Ping timeout: 245 seconds) 12.49.28 Join Kitr88 [0] (~Kitr88@BSN-182-71-114.dial-up.dsl.siol.net) 12.50.04 Quit Rob2223 (Quit: Rob2223) 12.50.48 Join DerPapst [0] (~DerPapst@p4FE8F1B2.dip.t-dialin.net) 12.51.53 Quit Kitar|st (Ping timeout: 240 seconds) 12.52.06 # Is it a known bug that scrolling text from the WPS doesn't disappear when USB is connected? I get the USB screen with the artist and album still scrolling... 12.52.39 Quit GeekShadow (Read error: Connection reset by peer) 12.52.57 *** Saving seen data "./dancer.seen" 12.53.44 Quit Kitr88 (Ping timeout: 252 seconds) 12.55.46 Join xavieran [0] (~xavieran@ppp118-209-153-106.lns20.mel6.internode.on.net) 12.57.53 Join moos [0] (moos@rockbox/staff/moos) 12.59.37 Join Kitar|st [0] (Kitr88@BSN-182-86-145.dial-up.dsl.siol.net) 13.07.36 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.11.04 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.11.19 Quit kramer3d (Ping timeout: 246 seconds) 13.11.40 # New commit by 03teru (r24616): chopper: fix FS#11000: Drawing issue with steep mode. don't change level while in game. 13.15.49 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 13.16.03 # Am I to assume I need to generate *all* manual screenshots for my plugin by hand? 13.16.35 # No automated way to build all the simulators and take a screenshot? 13.17.41 Join teru0 [0] (~teru@KD059133108225.ppp.dion.ne.jp) 13.17.54 Quit teru0 (Client Quit) 13.18.37 # archivator: unfortunately not 13.18.40 Quit teru (Ping timeout: 246 seconds) 13.18.44 # it's a nice idea though 13.19.28 # I guess you'll have to manage without screenshots for now. 13.19.48 # Also, we need a way to convert #ifdef-based keymaps into LaTeX. 13.19.49 Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) 13.23.42 # I was working on it, but failed 13.24.14 # rasher: the first or second part? The ifdef parsing shouldn't be too hard.. 13.24.16 # FS#10575 and FS#10571 13.25.09 # Ah, what was the problem? 13.26.18 # I was trying to add a STARTPLUGIN event to the event queue, but it didn't quite pan out 13.26.33 # I was getting it and starting the plugin from the wrong context or something like that 13.27.43 # So the plugin would crash, or not accept keypresses 13.27.58 # But starting the plugin by stuffing the appropriate keypresses in the button queue pretty much worked 13.28.09 # Not terribly ideal though 13.29.31 Join Sajber^ [0] (~Sajber@h-65-75.A213.priv.bahnhof.se) 13.30.13 # I see. I might look into it, it'd be pretty cool if we got it to work consistently. 13.30.25 # Indeed! 13.31.11 # I've about exhausted my coding skills at this point 13.39.15 Join Rob2222 [0] (~Miranda@p4FDCA0BC.dip.t-dialin.net) 13.40.12 # archivator: log(x) isn't too hard. use __builtin_clz(x) to get log2(x), and then you can use some tricks to get a few more bits. if you know your possible input range then scaling to fit the screen won't be hard. i can give you a hand with this if you want, i've worked on fixed-point logs for aac a bit, and the algorithm i was working on could add a scale with fairly small cost if the scale can be determined at compile time. 13.40.23 Join wind [0] (~7ba9867b@giant.haxx.se) 13.40.38 Join Casainho [0] (~chatzilla@87-196-74-13.net.novis.pt) 13.41.31 # Unhelpful: thanks but I'm afraid it will have to wait. Can't put too much time into this plugin right now.. :( 13.41.47 # hello :-) 13.42.22 # can someone please explain to me what are "manifols" on 3D? looks like that can give problems when processing the STL on skeinforge 13.43.00 # archivator: well, i'll take a look anyway ;) 13.43.32 # Out of curiosity, is there a manual build for every target in tools/configure? I'm basing the manual entry for fft on the oscilloscope and I have quite a few more keymaps than the oscilloscope.. 13.44.21 # (sorry worng channel) 13.44.38 # Unhelpful: I'm afraid you won't like the math in there. I never did clean it up properly and right now it just clips when the result overflows. If you figure it out, it would be most appreciated :) 13.46.10 # archivator: hrm. do you know what the actual peak value would be? 13.47.06 # oh, dur... this is a frequency/amplitude plot, isn't it? the peak value is determined by your fft size... 13.47.22 # well, the maximum coordinate, that is. 13.48.14 # The maximum amplitude you mean? 13.48.34 Quit krazykit (Ping timeout: 258 seconds) 13.49.30 # It shouldn't be determined by the fft size. However, it *is* bounded by the algorithm. 2^11 I think was the upper bound. I never did calculate it properly, it was just a good enough bound for practical reasons. I think it's tighter than that though. 13.49.52 # i thought we were talking about log-scaling the frequency axis of the plot? 13.51.05 # Ah, I thought you were looking at the calc_magnitudes bit. Then yes, the maximum frequency is determined by the transform. 13.51.21 # Well, not exactly. 13.52.02 # The Nyquist frequency is the maximum frequency. The value in the last bin kinda represents Nyquist/FFT_SIZE frequencies 13.53.25 Quit kramer3d (Quit: Leaving) 13.53.27 # well, anyway, we're talking about log-scaling N input points to N output points, with both known. an LUT might cover this, really. ;) 13.54.05 # New commit by 03teru (r24617): "remote_control: don't use goto. 13.55.06 Join krazykit [0] (~kkit@ppp-70-236-33-106.dsl.ipltin.ameritech.net) 13.56.02 Quit kaniini (Quit: (@Syvere-Home) täytyy sanoo et noi applen tuotteet on niin ultimaalisen paskaa laatua et ihmetyttää kyl et miten ihmiset ostaa noita) 13.56.09 Join kaniini [0] (~kaniini65@dyn75-70.yok.fi) 13.58.07 # * Unhelpful wonders if a bresenham's-like formulation of log2(x) exists/is possible 13.59.41 # that would be ideal, you'd do some heavy math once to get initial values and then be able to update the bin to plot from for each screen pixel rather quickly 14.13.01 # New commit by 03kugel (r24618): Convert RINGBUF_* macros to inline functions, saving binsize and improving type safety. 14.14.38 # how does inline functions save binsize compared to macros? 14.15.39 # by not being inlined anymore? :) 14.16.39 Quit Strife89 (Read error: Connection reset by peer) 14.17.06 Join Strife89 [0] (~michael@adsl-154-22-187.mcn.bellsouth.net) 14.17.43 # New commit by 03mc2739 (r24619): Fix red caused by r24615 14.18.07 Quit Rob2222 (Read error: Connection reset by peer) 14.18.31 # the H300 database red looks very weird but has been compiled on the same machine so far 14.18.40 Join Rob2222 [0] (~Miranda@p4FDCA0BC.dip.t-dialin.net) 14.18.57 # ah, someone just committed a fix 14.20.32 # there's only one "database" target (and I didn't even know such a thing existed) 14.25.21 Join Schmogel [0] (~Miranda@p3EE21BD4.dip0.t-ipconnect.de) 14.29.08 # New commit by 03mc2739 (r24620): Updated Chinese translation ... 14.31.34 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 14.32.24 Quit dfkt (Disconnected by services) 14.32.31 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 14.33.48 # dionoea: it's still inlined 14.33.55 # I checked bloat-o-meter 14.35.00 Quit kugel (Disconnected by services) 14.35.03 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 14.35.06 Join kugel [0] (~kugel@e178113128.adsl.alicedsl.de) 14.35.18 Quit kugel (Changing host) 14.35.18 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.36.56 # B4gder: I think it's mainly by letting gcc optimize argument-expressions more cleverly. if you pass an expression (a+b) it's expanded everytime the parameter is used in the macro. with inline, it will be only computed once, then "passed" to the inline 14.37.58 # that sounds like speculation to me ;-) 14.38.31 # but I'm fairly sure actually :) 14.38.45 # why would it do worse just because it does it many times? 14.38.49 # it is spec-ulation in the sense that the spec guarantees that :) 14.39.27 # hm does it? Maybe I'm misunderstanding the exact issue 14.39.36 # B4gder: because it's better to do an addition only once instead of thrice 14.40.14 # proves the compiler is still pretty stupid I guess 14.40.41 # I think we can all agree gcc isn't exactly superhuman 14.41.03 # (((p)+(v)) right, but it wasn't _because_ you made it inline 14.41.29 # it was because you changed the logic 14.41.31 # to be fair 14.41.39 # no 14.41.42 # yes 14.41.50 # I checked binsize with plain converting 14.41.52 # you could've made that logic in the macros too 14.42.04 # and after making it more readable. it didn't make a difference 14.42.06 # not that I would favour that, I prefer inlines 14.42.46 # yah, B4gder is right, but it's way uglier if you do that in a macro :) 14.42.52 # oh yes 14.42.57 # it would be terrible 14.42.58 # as I said, bloat-o-meter was my friend. it showed the "logic change" didn't make any difference, and that it's still inlined 14.43.07 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 14.43.22 # your conversion to inline changed the logic - to the better 14.43.37 # I hope so :) 14.44.08 # but w.r.t to binsize, plain converting gave the same saving 14.44.57 # you mean converting and maintaining all the operations on multiple places? 14.46.09 Join froggymana [0] (~187b533e@giant.haxx.se) 14.46.21 # I mean http://pastie.org/821730 14.46.46 # Clearly gcc isn't right in its head 14.46.54 # so what did it save in that case? 14.47.37 # the same 14.47.59 # so then your explanation about the "less additions" is wrong? 14.48.28 # this isn't very important, it just puzzles my curiosity 14.48.41 # no, it shows that my explaination is right :) 14.49.05 # if that pastebin saved binsize, and it uses the same amount of operations, how can that then be? 14.49.36 # it would rather show that gcc is better to "collect" expressions within the scope of a function than within the scope where the macros were used 14.49.54 # the additions are evaluated before "calling" the inline functions. that doesn't happen in macros. since there's no other code change it must be the less additiopns 14.50.34 # in your pastebin they are not evaluated before calling them 14.51.00 # sure, due to the fact that it's an inline function (what gevaerts noted) 14.51.14 # but so is a macro 14.51.26 # more or less 14.51.58 # a macro is text insertion. the parameters are inserted as they're written 14.52.31 # basically like an inlined function! 14.52.58 *** Saving seen data "./dancer.seen" 14.53.26 # an inline function should still be a function, which has guarantees about multiple evaluation of argunments 14.53.32 # nah, inline functions work more like compiling the function as is, and then inserting that binary code where it would've been called. so in the callers all computations for arguments would happen 14.54.33 # that's not exactly how inline functions work though 14.54.57 # but I'll drop this now anyway and go to pretend I'm working 15.00.02 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 15.04.15 # grml, something in buffering is horribly broken (not related to my commit) 15.13.13 Quit DerPapst (Quit: Leaving.) 15.17.59 # I don't get it. I protect against overwriting the next handle but it's getting garbled 15.22.07 # the question is why the handle is added at all if it doesn't fit 15.22.36 # it looks like there's always 1 handle at the end for next track metadata no matter of whether the previous one finished properly 15.37.44 # which shouldn't happen according to add_handle()! 15.40.16 Quit Sajber^ (Quit: Leaving.) 15.40.41 # it seems I can get around the segfaults/dataaborts but the next track info is still garbage 15.41.38 # maybe the wps doesn't handle it properly 15.41.54 # New commit by 03teru (r24621): jpeg,png: some minor changes. 15.43.03 Join Sajber^ [0] (~Sajber@h-65-75.A213.priv.bahnhof.se) 15.43.15 Quit Sajber^ (Client Quit) 15.43.22 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 15.49.48 Quit froggymana (Quit: CGI:IRC) 15.53.17 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 16.01.13 # interesting. the wps is using the static mp3entry struct because the next track id3 isn't buffered. when skipping to 5s before the end of the current track, and back again it's magically using a buffered mp3entry struct (even though it didn't fit when playing the track for the first time) 16.01.46 # I would expect it to use the static struct again after switchting back 16.04.18 # so it looks like the next track metadata is getting buffered when skipping to the end, but not invalidated again when skipping back 16.08.58 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 16.11.04 Quit teru (Quit: Quit) 16.22.06 Quit GeekShadow (Read error: Connection reset by peer) 16.33.04 Quit zumbi (Ping timeout: 260 seconds) 16.39.44 Quit wind (Quit: CGI:IRC (EOF)) 16.45.54 # I think I have a sort-of fix 16.47.13 # this is all strange, I'm not sure my fix is corret 16.47.17 # but it seems to work 16.47.30 # JdGordon: ping 16.48.23 # JdGordon: (for the logs) the wps isn't notified when the track is rebuffered (e.g. by skipping back with a low-mem audio buffer), it needs to refresh it's metadata 16.53.00 *** Saving seen data "./dancer.seen" 16.55.21 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 16.56.23 Quit Tomis (Quit: Tomis) 16.59.21 Join wojtek1991 [0] (~wojtek199@77-253-35-69.adsl.inetia.pl) 16.59.30 # hello 16.59.47 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 16.59.55 # could you tell me how can I make my own dictionary for rb? 17.01.36 # wojtek1991: http://www.rockbox.org/wiki/PluginDict 17.02.02 # I have read on forum but theres not many 17.02.04 # I have read on forum but theres not many 17.02.06 DBUG Enqueued KICK wojtek1991 17.02.06 # I have read on forum but theres not many 17.02.09 # I have read on forum but theres not many 17.02.10 *** Alert Mode level 1 17.02.10 # I have read on forum but theres not many 17.02.15 *** Alert Mode level 2 17.02.15 # I have read on forum but theres not many 17.02.23 # wojtek1991: that kind of behavior will get you banned 17.02.24 # I have read on forum but theres not many 17.02.25 # I have read on forum but theres not many 17.02.25 *** Alert Mode level 3 17.02.25 # I have read on forum but theres not many 17.02.25 *** Alert Mode level 4 17.02.25 *** Alert Mode level 5 17.02.25 # I have read on forum but theres not many 17.02.26 *** Alert Mode level 6 17.02.26 *** Alert Mode level 7 17.02.26 # I have read on forum but theres not many 17.02.27 *** Alert Mode level 8 17.02.27 # I have read on forum but theres not many? 17.02.28 *** Alert Mode level 9 17.02.28 # I have read on forum but theres not many 17.02.28 *** Alert Mode level 10 17.02.28 # I have read on forum but theres not many 17.02.28 *** Alert Mode level 11 17.02.28 *** Alert Mode level 12 17.02.28 # I have read on forum but theres not many 17.02.34 # I have 17.02.35 # I have 17.02.38 # stop it 17.02.50 Quit wojtek1991 (Client Quit) 17.09.08 Join HontoniLinux [0] (~chatzilla@188.74.103.132) 17.09.48 # FS#11004 17.12.29 *** Alert Mode OFF 17.13.23 # Heya, earlier today I got a sansa e280 so I figured I'd install rockbox on it now. In linux it showed up as the device "sg0" which it wouldn't let me mount with the error "not a block device". 17.13.46 # sg0 is indeed not a block device 17.13.50 Quit Zagor (Quit: Clint excited) 17.14.42 # So I now booted into Windows 7 and it finds the device nicely and I can browse the system, however instead of assigning it a drive letter it lists it as the "portable device" Sansa e280 under which I can access the filesystem. 17.15.00 # you haven't followed the instructions. you need to set it to MSC mode instead of MTP 17.15.31 # Oh woops. Sorry about that. 17.15.43 # Let me go back and read/have a go at it. 17.16.36 Join NickK [0] (~5660e554@giant.haxx.se) 17.16.58 Join wojtek1991 [0] (~mail@77-253-35-69.adsl.inetia.pl) 17.17.11 # Torne: Cheers that did it, thanks :). 17.17.52 # Hey guys I got a question. Every time Im playing a song that i want to skip, i can't do so 17.17.53 Join stavrob [0] (~sam@78-105-125-218.zone3.bethere.co.uk) 17.18.13 # i press the next button but it just fast forwards 17.18.39 # oh and I got an ipod 5ht gen by the way 17.18.48 # hi everyone, i am using rockbox 3.5 with the latest bootloader on an ipod 5.5g 80GB. I am trying to get the HID working but whenever I plug in a usb cable it just immediately boots into the ipod firmware 17.19.04 # stavrob: the release builds don't use our usb mode 17.19.12 # install a current development build 17.19.16 # stavrob: which means there is no HID 17.19.24 # note that usb file transfers may be slower, and charging may nt work properly 17.19.26 # Does anybody know how to make dictionary file for rb? 17.19.33 # Torne: someone might want to change the 3.5 release notes in that case i think then 17.19.43 # where? 17.20.10 # in the whats new section it says: Added switchable USB HID keypad modes. (FS#10468) 17.20.15 # yes. 17.20.25 # and we did 17.20.28 Join funman [0] (~fun@rockbox/developer/funman) 17.20.39 # it just happens that your particular player doens't have it enabled 17.20.45 # it is on other devices. 17.20.58 # ah. i see. maybe a note should be added about that then i suppose 17.20.59 # does anyone have the same problem not being able to skip to the next song? 17.21.16 Quit petur (Quit: beer time!) 17.21.16 # NickK: maybe you have "prevent track skipping" enabled? 17.21.34 # stavrob: lots of features listed only work on players which can support them 17.21.54 # nobody? 17.22.08 # wow I feel pretty stupid now. Thanks a million Stavrob 17.22.09 # Torne: well its listed in the ipod 5.5g manual as well so thats why i was confused when it didnt work 17.22.12 # wojtek1991: You didn't ask a question 17.22.23 # scroll up? 17.22.27 # I did 17.22.28 # stavrob: it shouldn't be 17.22.36 # stavrob: which manual? 17.22.42 # evilnick_B: he did, it's just the same question he asked earlier, which you already answered. 17.22.53 # Torne: http://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildch8.html#x11-1370008 17.23.00 # its in section 8.5.8 17.23.03 # stavrob: yes, that's the manual for the current development version 17.23.04 # I asked about dictionary for for plugin 17.23.08 # which does indeed have USB HID 17.23.09 # wojtek1991: http://www.rockbox.org/wiki/PluginDict 17.23.14 # GodEater: Ta 17.23.29 # Torne: aha i see 17.23.46 # alas it is also in the release manual. 17.23.58 Quit parafin (Read error: Operation timed out) 17.24.04 # it shouldn't be, but hey :) 17.24.09 Quit saratoga (Quit: Java user signed off) 17.24.19 # why is it every time I select a song to play in the database, It says "searching" followed by a countdown 17.24.25 # Torne: well i doubt many other people will have the problem, its quite a niche use 17.24.38 # Its too complicated. I must prepare file but how to get it 17.25.00 Join parafin [0] (parafin@paraf.in) 17.25.06 # gevaerts: apparently undefining USE_ROCKBOX_USB doesn't disable the hid feature 17.25.17 # gevaerts: so the 3.5 release manual still thinks it has HID 17.25.47 # If I have binary file whats I should do then 17.25.56 # wojtek1991: It should be explained on the wiki page, but if you say exactly which bit is causing you problems then someone may be able to help 17.26.10 Join pamaury [0] (~pamaury@ALyon-551-1-70-117.w92-137.abo.wanadoo.fr) 17.26.34 Join Farthen [0] (~chatzilla@e179233129.adsl.alicedsl.de) 17.26.34 # gevaerts: should usb_hid maybe be inside the #if defined(HAVE_USBSTACK) && defined(USE_ROCKBOX_USB) in features.txt? 17.26.44 # wojtek1991: if you already have a binary file then you don't have to generate anything, so I don't understand your question 17.26.58 # stavrob: sure, but it should've been removed automatically, so the features file might be wrong :) 17.27.54 # oh no, now rockbox has control of my mouse 17.27.57 # how do i get it back lol 17.28.03 # evilnick_B: although, that wiki page says nothing about where your place the dictionary file on the player. 17.28.06 # Well on this page is written that I must have file .dec and .index but I havent got prolog version 17.28.08 # and I certainly have no idea. 17.28.20 # my version has only .binary files 17.28.36 # oh no, my mistake, it does. 17.29.00 # wojtek1991: where did you get your file? 17.29.21 Join utchybann [0] (~papier@ede67-1-81-56-102-26.fbx.proxad.net) 17.30.39 # its Polish file from university wordnet project 17.31.17 # ranmachan: (answering to the forum) i think we should use i2c registers to detect usb 17.31.25 Quit NickK (Quit: CGI:IRC (EOF)) 17.32.16 # wojtek1991: Does this part help? "The input format for rdf2binary is very simple at this moment. It's one line per word, starting with the word, then a tab and then the description. The only thing you should be aware of when creating this files is that they must be in alphabetical order, and all words should be in lowercase. " 17.33.43 # ok I understand 17.34.03 # and where put it? in file anything.desc ? 17.34.13 # funman: That's the AS3514 register then, right? 17.34.19 # yes 17.36.05 # perhaps we should also use this method in mkamsboot' dualboot.S but an i2c driver would be larger 17.36.16 Part wojtek1991 17.36.52 Join wojtek1991 [0] (~mail@77-253-35-69.adsl.inetia.pl) 17.37.05 # sorry my connection f***d down 17.37.16 # funman: BTW I think the OF handles LCD brightness using software PWM on the c240v2 17.37.29 # could you repeat you reply? 17.37.43 # wojtek1991: see http://www.rockbox.org/irc/log-today 17.37.55 # thanks 17.37.57 Join zumbi [0] (~zumbi@77.230.237.25) 17.38.04 # DCD15 has no effect and if I wave the sansa I can see the flicker (except for the highes brightness setting, where it's on continously apparently) 17.39.16 # sorry for spamming before I had a silly client 17.39.40 # well where I have to put this data? I meant name of file 17.39.54 Quit TheSeven (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]) 17.40.14 # evilnick_B are you there? 17.40.55 # wojtek1991: I am, but I haven't tried this myself yet, so am seeing if there's any other advice I can give 17.41.07 # ok 17.41.38 # what is wrong with current rockbox usb support that prevents it from being included in releases? 17.41.57 # On ipods 17.41.58 Join komputes [0] (~komputes@ubuntu/member/komputes) 17.42.00 # yes 17.42.04 # It is enabled on other players 17.42.10 # It is mainly due to charging 17.42.12 # oh ok i didnt know that 17.42.32 # Ipods don't charge properly under Rockbox, so can actually slowly discharge when being used over USB 17.43.17 # ah. what about if you plug it in and hold down menu at the same time so it goes into charge mode. does that actually not charge it then? 17.43.25 # It does, but again slowly 17.43.38 # ranmachan: do you want to patch usb_detect() ? I can test on clipv1 and fuzev1, and some developers here have an e200v2 17.44.01 # funman: Already on it :) 17.44.10 # nice :) 17.44.51 # i just got a clip+ but i want to understand what went wrong with JdGordon and mt's Clip+ before trying any code on it 17.45.12 # or with mt's one 17.45.33 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 17.45.33 # * funman slaps kugel for not reading the full sentence 17.45.38 # wojtek1991: From what I can work out, those instructions are to firstly convert two files wn_g.pl and wn_s.pl into an .rdf file 17.45.40 Join toffe82 [0] (~chatzilla@ppp-71-130-79-140.dsl.frs2ca.pacbell.net) 17.45.52 # stavrob: It is fine if you want to continue using it, but if you want a quick charge the Apple firmware is quicker 17.46.15 # AlexP: what about if you plug it into a charger 17.46.19 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 17.46.20 # stavrob: But this is being worked on, so at some point hopefully it'll be possible 17.46.23 # stavrob: Not sure 17.46.24 # wojtek1991: And then to run rdf2binary on that .rdf file to get the .index and .desc files - which are the ones to be placed in ./rockbox/rocks/apps on the player 17.46.25 # kugel: i will check my assumption that we can address 1MB of RAM, but I seriously doubt it would be different between 2 Clip+ since it worked for FlynDice 17.46.28 # * kugel puts his head in shame 17.47.07 # is rss channel with subversion posts? 17.47.14 # wojtek1991: But I have no idea how to go from your .binary file 17.47.33 # ...to the required .index and .desc 17.48.26 Join addikt1ve [0] (~addikt1ve@79.84.41.214) 17.48.28 # hi 17.48.54 # my Nano 2G tells me "Use iTunes to restore" 17.48.55 Quit Farthen (Read error: Connection reset by peer) 17.48.57 # looks like it crashed :) 17.49.00 # what shall I do? 17.49.22 # * funman would "Use iTunes to restore" 17.49.34 # one the other side. How to make .desc and .index file myself 17.49.59 # if I would write all phrases myself 17.50.44 # wojtek1991: Maybe you could try d/ling the .desc and .index files linked to from the Wiki page and see if you can figure out how to add to/alter them? 17.50.58 # wojtek1991: evilnick_B already told you 17.51.07 # I'm having some trouble with the system locking up, let's see if it works properly if I use ascodec_lock/unlock... 17.51.07 # ok I try 17.51.19 # AlexP: To be fair, that wiki page isn't terribly clear 17.51.26 # wojtek1991: Does this part help? "The input format for rdf2binary is very simple at this moment. It's one line per word, starting with the word, then a tab and then the description. The only thing you should be aware of when creating this files is that they must be in alphabetical order, and all words should be in lowercase. " 17.51.34 # wojtek1991: And then to run rdf2binary on that .rdf file to get the .index and .desc files - which are the ones to be placed in ./rockbox/rocks/apps on the player 17.51.49 Join Farthen [0] (~chatzilla@e179233129.adsl.alicedsl.de) 17.52.06 # evilnick_B: I haven't read it, but it seemed fairly reasonable from that 17.52.17 # ranmachan: also don't forget rockbox will reboot to OF when usb is plugged unless you press center button (i believe it is center) 17.52.27 # ok I got 17.53.10 Quit Farthen (Read error: Connection reset by peer) 17.53.20 # What aobut writing plugins? Ansi C? Where can I get compiler for wndows? 17.53.25 # Is this taking it too far? http://fpaste.org/Bd4Q/ 17.53.32 # funman: That part works so far. 17.53.38 # Itutomatically generated from the source file. 17.53.44 # It's automatically * 17.54.10 # wojtek1991: http://www.rockbox.org/wiki/DevelopmentGuide 17.55.01 # But if go into my pimped 'show port status' which also accesses ascodec it locks up... D'Oh. adc_read of course automatically takes the lock, need to move the lock down... 17.55.58 # locking multiple times shouldn't be a problem afaiu 17.56.39 # i think locking the same mutex several times in the same thread is allowed 17.56.45 # funman: It is if you try to take the lock twice because you called ascodec_lock and then call adc_read :) 17.56.51 # provided you unlock it the same number of times afterward 17.57.32 # Hmm, ok, anyway I moved the lock down, let's see if it helps... 17.58.18 # firmware/kernel.c:mutex_lock() just increases refcount and returns if the mutex is alreayd locked by the calling thread 17.59.28 # * kugel pm'd matsch about fs#11004 17.59.54 Part LinusN 17.59.57 # thanks man 18.00.04 # I try 18.01.07 # archivator: i don't understand what this is 18.01.13 # Hmm, if I comment out usb_detect the port dump works. If I don't go into the port dump screen the usb detect works. 18.01.30 # archivator: nice 18.02.12 # ranmachan: hm perhaps usb detection is called from the kernel tick, where mutexes can't work 18.02.16 # funman: a button table for the manual, generated from the source file. 18.02.21 # because the isr isn't a thread 18.02.33 # power-as3525.c also doen't take the ascodec_lock for some reason 18.02.38 # archivator: then it is nice, writing manual button tables is boring .. 18.03.03 # Tell me about it, I couldn't even do one :( 18.03.38 # ranmachan: ascodec_*() do take the lock 18.03.58 # funman: It does work with the lock in usb_detect as long as I don't use the port debug menu where I also take the lock. 18.04.24 # funman: Ah ok, I thought I'd have to take it because it's used in adc_read, but it makes sense if you can take it twice. 18.04.30 # Ok, so I don't need to take it. 18.05.11 Quit Casainho (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115133306]) 18.06.01 # usb_detect() seems to be called from apps/main.c... 18.06.20 Join DerPapst [0] (~DerPapst@p5797CBF8.dip.t-dialin.net) 18.06.31 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 18.06.38 # FlynDice: unlike the clipv1/v2, the clip+ OF enables a fixed set of peripherals (which doesn't include GPIO) in CGU_PERI immediately after reset, perhaps that could play and we should disable CGU_PERI before branching to OF and wait a bit ? 18.06.58 # Ah and also in firmware/usb.c 18.07.31 # ranmachan: usb.c is the usb tick, so perhaps we have a problem there 18.08.14 # Yep, it's called from usb_tick 18.08.54 # Icanr get setup.ini.sig from rockbox.org 18.10.27 # if the tick isr happens in the middle of an ascodec operation we can't use ascodec_*() in the isr 18.10.51 # and we can't use mutex_lock() since the operation can't finish before the isr has returned 18.11.28 # does anybod have setup.ini.sig for cygwin? 18.13.11 # wojtek1991: Using VMWare should be a lot faster 18.13.26 # wojtek1991: More of a download initially, but it'll build quicker 18.14.15 # mutexes can't be used in isrs afaik 18.15.27 # we could use a status bit and do not run ascodec_*() if an operation is in progress 18.17.01 # Or just check if the i2c_lock is taken and use a nonlocking i2c_read? 18.17.34 # there's no "nonlocking" i2c read 18.17.45 # you can only have one operation active at a time 18.17.50 # Or maybe add a thread for the usb detection and 18.18.25 # i would add a bool ascodec_active(void); and use the previous state if it returns true 18.19.50 # That won't work since you still would have to use the lock-taking ascodec_read from within interrupt context if it's not active if I'm not mistaken? 18.19.51 # couldn't you just post to a thread from the usb tick; the thread would then read and change a variable which is read by the next usb tick? 18.20.45 # hm i'm not sure what happens if you use mutex_* in isr 18.20.52 Quit HontoniLinux (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 18.21.04 # I'd have suggested adding a thread which polls less often than usb tick, set the global from there and just return the variable state. 18.21.42 # What's the tick frequency? 18.21.54 # funman: it will simply freeze 18.22.29 # if a thread owns the mutex, then the isr will wait for the mutex being released. that can't happen in interrupt context so it will wait forever 18.22.41 # ranmachan: 100Hz 18.23.31 # kugel: but in this scenario we could only take the lock if it's not taken yet 18.23.40 # I'd assume 10Hz would be sufficiently fast for usb presence polling :) 18.24.20 # iPod nano 2g tells me I have to restore it using iTunes. What shall I do? 18.24.31 # addikt1ve: restore it using iTunes 18.25.03 # funman: wait 18.25.13 # * kugel thinks the thread is more promising 18.25.24 # how can I use iTunes under linux? 18.25.25 # :) 18.25.27 # kugel: and less of a hack 18.25.30 # addikt1ve: you can't afaik 18.25.53 # and that's EXACTLY why I'm asking my question once again: what shall I do? :) 18.26.08 # find someone with itunes 18.26.09 # find a computer running windows and install itunes 18.26.28 # do I really need to do such a thing? 18.26.56 # if you want it working again, kinda yes 18.26.57 # is there any rss channel with Subversion posts? 18.27.05 # can gtkpod restore an iPod? 18.27.21 # wojtek1991: you mean wihch announces commits to the rockbox source? 18.27.22 # wojtek1991: i don't think so but there is http://www.rockbox.org/recent.shtml#svn 18.27.39 # addikt1ve: ask gtkpod people but i don't think so 18.27.46 # wojtek1991: there's a mailing list which is effectively the same 18.28.00 # gonna take a look 18.28.13 # ok but I would like to add it to my webpage 18.28.19 # Ok, I've whipped something up, let's see if it works... 18.28.29 # well 18.28.35 # actually my iPod isnt showing up 18.28.38 # I know how to do it with rss but what about mail list? 18.29.12 # wojtek1991: you can look at svn://svn.rockbox.org/rockbox/www/ in our page does it 18.29.27 # http://svn.rockbox.org/viewvc.cgi/www/ 18.29.39 # addikt1ve: google has a couple of hits on 'restore ipod without itunes' 18.29.49 # funman: BTW how about using an interrupt instead? After all the hardware can generated one on usb status change... 18.30.24 # i don't know how to use interrupts with as3514 18.30.29 # topik: that's what I was looking for 18.30.33 # the i2c module isn't documented 18.30.39 # looking at* 18.30.43 # please forgive my english 18.30.53 # the registers names are in the datasheet but not their content (bits) 18.30.57 # ranmachan: you mean using the gpio change to initiate a i2c read? 18.31.06 # TheSeven would probably say it can be done by writing some of his special voodoo to the ipod directly 18.31.21 # it would still have to show up as an usb device though 18.31.47 # I give up 18.32.57 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 18.33.28 # kugel: Well the problem is I couldn't find a gpio for usb status on my device. 18.34.12 # kugel: But as3525 datasheet says the as3514 part can generate an interrupt if the usb_status in irq_enrd_0 changes. 18.34.54 # if you find how to setup interrupts with i2c, fine 18.35.34 # i think it's doable with a bit of reverse engineering 18.35.36 # ranmachan: have you tried changing the polarity of the pin before reading? 18.35.40 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.36.14 # kugel: more details on the issues you mentioned 18.36.14 # ? 18.36.18 # kugel: No, I tried debug view I/O ports as is. 18.36.33 # the old button driver of the fuze/e200v2 needed to write a 0 to all relevant pins before reading, otherwise it just wouldnt work 18.37.05 Part topik 18.37.16 Join topik [0] (awesome@213.203.214.114) 18.37.30 # it's possible that a pin is 1 after reset or just changes to 1 after some time even if 1 would indicate usb, so I would try writing a 0 just before reading 18.37.44 # (that can even be different from unit to unit) 18.39.22 # JdGordon: does fs#11004 contain insufficient info? 18.39.23 # Unhelpful: gevaerts: to avoid heaps of unallocs/rallocs for the glyphcache I thought the fonts would stay the same as now and just do a big allocation for each, the size of that block would vary with the font size, but average aroun 25K or something 18.40.16 # oh, ok thats cool 18.40.49 Quit funman (Quit: free(random());) 18.41.21 # what is cool? 18.41.36 # kugel: dualboot.S doesn't do that though. 18.41.57 # I didnt see the task yet 18.41.59 # It only writes 0 to the direction register and then reads the port status. 18.42.10 # that could very well be because the c200v2s we had so far didn't need it 18.42.26 # And it works fine for the right button that way 18.42.52 # we have like 3 c200v2s, so it's possible we simply missed it 18.44.16 # kugel: So you mean switch to output, write 0, switch to input and read the port status? 18.44.22 # and, as I said already, the c200v2 is under unusable so we don't garuantee any correctness in the current code :) 18.44.41 # Could someone please take a look at http://pastie.org/822084 and commit it if it's good enough? It's a little blurb in the manual about fft.. 18.44.41 # we dont ever guarentee code correctness 18.45.06 # ranmachan: yes, you might need additional micro delays inbetween (like "volatile int i = 10; while (i--);") 18.45.18 # The touchscreen keymaps are not added but I am not sure how those work so I opted not to include them atm 18.45.21 # bye all 18.45.50 Part wojtek1991 18.47.36 # archivator: what's the difference between "IRIVER_H10_PAD" and "IRIVER H10 PAD"? 18.47.49 # this seems to have been used somewhat arbitrarily 18.48.00 # Hmm, let me double check that :) 18.48.47 # There isn't one with spaces on my end.. 18.49.21 # in the c200v2 OF I do see a function that does something with both GPIO A5 and A7 18.49.32 # Ahh! It's pastie's horrendous coloring that's doing it - there are actually underscores in there. 18.50.29 # can you call one lua script from another? 18.51.03 Join freddyb [0] (~fred@pool-68-238-8-141.chi.dsl-w.verizon.net) 18.51.10 # JdGordon: What size was your deceased clip+? 18.51.22 # 2G i tihnki 18.51.30 Join piotrekm [0] (~pm@unaffiliated/piotrekm) 18.52.54 Quit addikt1ve (Quit: WeeChat 0.3.1.1) 18.53.04 *** Saving seen data "./dancer.seen" 19.00.59 # I'm seeing another function in the c200v2 OF where it chooses between GPIO A1 and A5 depending on some configuration value 19.01.21 # It looks like there is more than 1 type of c200v2 around ... 19.01.28 # JdGordon: I'm wondering if the change to playback.c is sane 19.01.49 Join m3dlg [0] (~m3dlg@212.183.140.1) 19.05.37 # I wrote some code to enable mouse clicks on the background of the UI simulator. Would anyone else be interested in this? I mean should I post it on Flyspray? 19.05.43 # http://pastebin.com/m882f678 19.06.44 # bertrik: Might be that usb detect is supposed to be on A5 for me then. 19.07.36 Quit m3dlg (Ping timeout: 264 seconds) 19.08.10 Join m3dlg [0] (~m3dlg@212.183.140.1) 19.08.31 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 19.08.50 # kugel: I tried this: http://pastebin.com/m730fa94 but still don't see a change on GPIOA when I plug in usb... 19.11.04 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 19.11.32 # Only when I press menu or insert an microsd I see changes in GPIOA (even without the prior 0 write) 19.11.37 # "GPIOA_DATA = data & dir;" ?? 19.11.40 # If anyone's interested, this is the current incarnation of the python ifdef-to-latex conversion script. It should work in 90% of the cases. The input should contain only the #if ... #endif block with the keymaps. The script will ignore touchscreen keymaps (or rather anything after the #endif) 19.11.44 # http://pastebin.com/m4a339976 19.12.23 # kugel: Well, GPIOA_DATA = data would probably suffice. Just to put the backlight enable back :) 19.12.51 # well, how should this work if you write the old data back before reading? 19.13.01 Quit GeekShadow (Read error: Connection reset by peer) 19.13.19 # I've switched direction immediately before that, the bits in input mode should be unaffected by the write. 19.13.36 # And they are for the menu switch and SD bit 19.14.29 # so it shows GPIOA = 0x00 actually? 19.15.39 # No, it shows 0x86 or 0x8e (menu pressed) or 0x82 (microsd present) or 0x8a (microsd present and menu pressed) 19.16.38 # so A7 is set, bertrik mentioned the OF does something with A7? 19.17.52 # kugel: A7 switches on the backlight 19.18.06 # the OF seems to be very variable on what bits to set in GPIO A, depending on at least 5 variables that somehow define the player type 19.18.07 # (DIR is 0x80) 19.18.59 # the dbop doesn't change too when usb is inserted, right? 19.20.13 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 19.20.36 # If anyone else wants to have a look, the type detection code is at 0x8000 19.20.49 # kugel: DBOP is unaffected by USB plugin, yes 19.21.12 # Stays at 0xF07F 19.25.02 Join mt [0] (~mtee@rockbox/developer/mt) 19.26.27 # Torne: hm, from the manual point of view, I guess you're right. Technically, HID does not depend on USE_ROCKBOX_USB, since USE_ROCKBOX_USB should probably be USE_ROCKBOX_MSC. HID is really only noticeable on the USB screen, but it's always there 19.27.25 Quit m3dlg (Ping timeout: 256 seconds) 19.28.43 Quit kugel (Remote host closed the connection) 19.30.15 Quit pamaury (Ping timeout: 256 seconds) 19.32.19 # JdGordon: perfect 19.34.06 Quit freddyb (Remote host closed the connection) 19.38.20 # Anyone willing to commit http://pastie.org/822084? Or at least tell me what's wrong with it? Pretty pretty please? :) 19.38.46 # New commit by 03mt (r24622): Remove svn:executable property 19.39.02 Join checker [0] (~621342a9@giant.haxx.se) 19.39.17 # are there currently any shuffle options? 19.39.26 # Forgot to mention that this is in mdctexp branch ^ 19.39.49 Join freddyb [0] (~fred@pool-68-238-8-141.chi.dsl-w.verizon.net) 19.42.06 Part watto 19.42.15 Join lantius [0] (~lantius@76.73.16.26) 19.42.18 # hello 19.42.20 Quit evilnick (Read error: Connection reset by peer) 19.42.29 # hello 19.42.44 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 19.43.22 # i am trying to make a plugin for rhytmbox to support rockbox. I have found information about the database files, but I haven't found information about how the playlists are stored 19.43.29 Quit dmb_ (Ping timeout: 240 seconds) 19.43.39 # do you know where is the specification? 19.43.52 # playlists are just m3u files 19.43.55 # or m3u8 19.43.57 # lantius: the playlists are standard m3u 19.44.10 # ok, thank you 19.44.32 Join JdGordon_ [0] (~836b0053@giant.haxx.se) 19.45.44 Quit checker (Quit: CGI:IRC) 19.45.49 # kugel: which playback.c change? 19.49.13 Quit lantius (Quit: CGI:IRC 0.5.9 (2006/06/06)) 19.49.19 Join lantius [0] (~lantius@76.73.16.26) 19.58.09 # JdGordon_: I suspect he means FS#11004. I tried it on a couple songs and it seems to work... 19.58.11 # archivator: put it on the tracker - also I think this plugin is swcodec only (and I see no *_PAD of hwcodec targets) so the input is wrong and it looks to me that the *_PAD don't always match what we have in the manual (it differs sometimes from the c code), e.g. the for M5 and X5 the macro is only called IAUDIO_X5_PAD for the manual, currently. And sometimes also \Buttons are also called different, I believe. 19.58.57 # I'd also wish that the button table code follows the new scheme which makes it easier to add a column for targets with remotes (which I think is even needed already for the H100/H300 and Gigabeat (F and X, not sure about the S) 19.59.38 # yeah, S too 19.59.46 # pixelma: will do. What new scheme are you referring to? 19.59.49 # I really don't want to discourage you, already apreciate the work you put in there, if you stick it on the tracker someone else could finish it (maybe) 19.59.52 # If there is no remote key then it needs to be a blank column 20.01.08 # archivator: http://www.rockbox.org/wiki/LatexGuidelinesTalk at the end 20.01.18 # New commit by 03bluebrother (r24623): Rockbox Utility polish translation update. ... 20.01.28 # pixelma: You're not discouraging me, I realize that the manual is an enormous project in and of itself. I will post on the tracker, along with the script. I might actually create a proper application to do the parsing... 20.01.59 Join phanboy4 [0] (~benji@c-24-98-43-198.hsd1.ga.comcast.net) 20.02.42 # bluebrother: do you mean a Polish translation update, or to polish some translation update ;) 20.04.01 Quit gevaerts (Ping timeout: 248 seconds) 20.04.05 Quit anewuser (Ping timeout: 252 seconds) 20.04.56 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 20.05.09 # archivator: great. Thanks. Maybe c code and manual PADs could be synced sometime 20.10.21 Join anewuser [0] (anewuser@unaffiliated/anewuser) 20.10.29 Quit gevaerts (Disconnected by services) 20.10.33 # Whoops, it crashed: Data Abort @3068348C 20.10.38 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 20.12.38 Join Hacker258 [0] (~5c186d3b@giant.haxx.se) 20.12.57 # bertrik: Is there a size constraint on dualboot.S? I'm inclined to try using i2c to check usb status in dualboot.S tomorrow 20.14.08 # ranmachan, I don't know but I don't think so. I do think we should keep the dualboot part very simple and I don't want to add i2c reading there 20.14.38 Quit komputes (Read error: Operation timed out) 20.15.03 # it's an extremely critical part that means the difference between bricking or not, so it should also be extremely simple IMO 20.15.23 # Hi can anyone rewrite this code into a rockbox plugin please as i'm trying to lern . Its only 4 Lines , thankyou :) http://pastebin.com/d202e8db 20.15.48 Quit amiconn (Disconnected by services) 20.15.49 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 20.15.51 Quit pixelma (Disconnected by services) 20.15.51 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 20.16.09 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 20.16.11 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 20.16.58 # ranmachan, I noticed something weird in your battery benchmark, it started at nearly 5V and ended much lower than usual for a liion battery, so the battery readout is different too. 20.17.15 # Hacker258: Have you read http://www.rockbox.org/wiki/HowtoWritePlugins ? 20.17.51 # Hacker258: And then look at other plugins. 20.17.53 # yes i know how to do the printf 20.17.59 # its just the keyboard input 20.18.21 # kbd_input is all you get 20.18.29 # which is not very similar to ANSI C's input facilities 20.18.30 Join Tomis [0] (~Tomis@70.134.94.67) 20.18.39 # Hacker258: Your mp3 player has a keyboard? 20.18.58 # any parsing you would have to do yourself; it' far preferable to avoid that kind of input entirely 20.19.20 # no, can't I enter numbers using the onscreen keyboard?? 20.20.40 # Yes, but the keyboard is designed for text entry. To be consistent with the rest of the rockbox UI, you would use a "settings list" - i.e. a long list of numbers the user chooses from. 20.21.10 # how would I make a list from 1 to 31 20.21.39 # * AlexP knows people older than 31 20.22.17 # I know but I want the persons date of birth, the code was just an example 20.22.27 # * linuxstb doesn't do UI... 20.22.42 # Hacker258: Not including year presumably 20.23.03 # But you probably want to try and find the code for the date/time settings screen, and extract it from there. 20.25.39 # yah, for that kind of thing it's probably better to have it displayed onscreen and to scroll through each set of digits 20.25.51 # that's a *lot* more code than scanf() though :) 20.26.45 Quit krazykit (Ping timeout: 265 seconds) 20.31.59 Join komputes [0] (~komputes@ubuntu/member/komputes) 20.32.30 # can anyone post an example on how to do this? As time_menu.c is too complicated :S 20.33.59 # the point we were making is that this *is* a complicated thing to do. 20.34.08 # Adapting user input systems to the interface of an mp3 player is quite hard 20.34.24 # There is no simple example we can give you because it's not possible to do it in a nice way and still have ti be simple 20.37.04 Join krazykit [0] (~kkit@ppp-70-236-33-106.dsl.ipltin.ameritech.net) 20.37.32 # hacker258: you can use set_int from the plugin api to show a long list of numbers 20.37.36 # * bluebrother spots a problem with SystemInfo::platforms() 20.38.32 # well ok you can do that as well. but the UI from time_menu is nicer ;) 20.38.46 # Will the sim use asm, or will it always go for the pure C version? 20.39.22 # whats the best quick and dirty method available 20.39.24 # ? 20.39.39 # torne: you mean the split screen? or the ui to set the clock? 20.39.45 # the ui to set the clock 20.39.53 # thats terrible! 20.40.04 # ..maybe i am thinking of something else 20.40.06 # oh its painful to use except on a few select targets 20.40.47 # i mean being able to move between components of the date and scroll through values 20.40.57 # i haven't set the clock for ages so i may be misremembering ;) 20.41.05 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 20.41.44 Quit advcomp2019_ (Ping timeout: 265 seconds) 20.46.15 # what about the input in chessclock, how would i do that? 20.46.48 # read the source code for chessclock 20.47.12 # gevaerts: I think CONFIG_CPU is undefined on the sim, so no asm will be used. 20.47.42 # gevaerts: You want rockbox-as-an-app, not a sim, so get working... 20.48.16 # linuxstb: My first task is to find out why it's slow. I may have found it :) 20.49.02 # gevaerts: I'm guessing this is the sim on ARM? (your n900) ? 20.49.04 Quit JdGordon_ (Quit: CGI:IRC (EOF)) 20.49.05 # yes 20.49.44 # I guess you could just define CONFIG_CPU and see what breaks... 20.50.31 # or maybe just CPU_ARM and ARM_ARCH (6?) 20.51.18 # Yes, that's probably better. I guess the two things you want are the arm-optimised generic functions (memset etc) in firmware/ and then the codec optimisations. 20.51.24 Quit krazykit (Ping timeout: 264 seconds) 20.51.26 Join krazykit [0] (~kkit@ppp-70-236-33-106.dsl.ipltin.ameritech.net) 20.51.35 # * gevaerts tries 20.52.54 Quit Hacker258 (Quit: CGI:IRC) 20.53.06 *** Saving seen data "./dancer.seen" 20.53.11 # yay, good start. apps/plugin.c:339: error: '__div0' undeclared here (not in a function) 20.54.47 # make -k to the rescue 20.55.51 Join JdGordon_ [0] (~836b0067@giant.haxx.se) 21.02.45 Join dmb_ [0] (~Dmb@unaffiliated/dmb) 21.10.33 Quit komputes (Ping timeout: 256 seconds) 21.13.23 Join m3dlg [0] (~m3dlg@212.183.140.32) 21.14.36 Quit Tomis (Quit: Tomis) 21.17.01 Join Tomis [0] (~Tomis@70.134.94.67) 21.20.48 Quit BHSPitMonkey (Remote host closed the connection) 21.22.23 Quit utchybann (Ping timeout: 260 seconds) 21.22.28 Quit flydutch (Quit: /* empty */) 21.23.59 # hm, CPU_ARM doesn't really help much 21.24.16 Quit anewuser (Quit: http://xrl.us/WinterChipV =ooo Ï¢INTER ϾHIP 5iVE is OOON!!) 21.25.07 # New commit by 03mt (r24624): branches/mdctexp : Modify cook codec to use the new mdct library, ~11% speedup on Sansa E200. 21.26.09 # gevaerts: I tried saying before that if SIMULATOR is defined then alot of the arm code would probably be ignored anyway 21.27.37 # JdGordon_: in general, maybe, but not in the codecs I think. That means that this isn't a codec slowness as such 21.27.54 Quit ender` (Quit: It is difficult to produce a television documentary that is both incisive and probing when every twelve minutes one is interrupted by dancing rabbits singing about toilet paper.) 21.28.40 # It eats 17% CPU and causes pulseaudio to eat 17% CPU by just starting 21.28.58 Quit m3dlg (Ping timeout: 240 seconds) 21.30.03 # I'm going to post the UI simulator patch if no one objects. 21.32.36 # maybe it just doesnt like the amount of threads or something? 21.33.28 # how much ram does the n900 have? and how much have you told the sim to use? 21.34.02 # I assume thats what you're building for? 21.34.07 # it has 256MB, and I built a mostly-unmodified D2 sim 21.34.42 # but since it already eats lots of CPU by just sitting there, I think the big problems are either the sim audio driver or the sim lcd driver, or both 21.34.50 # maybe is swapping too much? (does it have swap space?) 21.35.15 Join Tomis2 [0] (~Tomis@70.134.74.176) 21.36.10 # It does have swap, yes. I doubt that that would be it though 21.36.12 # I edited the defines for the iPod Color before, but I forget where the file is. 21.36.27 # Since pulseaudio is also using a lot, I tend to think it's the sound driver 21.36.30 # I need to change it again. 21.37.29 Quit Tomis (Ping timeout: 240 seconds) 21.37.29 Nick Tomis2 is now known as Tomis (~Tomis@70.134.74.176) 21.37.48 Join AlexP_ [0] (~ap@rockbox/staff/AlexP) 21.37.49 # hm, maybe it's just a priority issue 21.38.19 # New commit by 03bluebrother (r24625): Fix problems with platform retrieval. ... 21.38.43 Quit AlexP (Ping timeout: 260 seconds) 21.40.07 # Never mind, found it. 21.44.14 # freddyb: nice patch! (havnt looked at the diff yet thuogh, only the description) 21.44.51 # do you rekon you can fix the problem where if you enable wps debugging in the sim and click in the lcd it should show the lcd pixel co-ordinates but really shows the window co-ords 21.50.15 # JdGordon_: I don't know much about it. Is it just an offset for each player? 21.50.47 # yes, there is a #define for each player where the lcd should be 21.51.13 # also, your patch doesnt work for touchscreen targets? 21.51.54 Join Sajber^ [0] (~Sajber@h-143-62.A213.priv.bahnhof.se) 21.52.12 # JdGordon_: I didn't get that far yet. I was looking for some interest before I did a bunch of work. I don't code as fast as you all. 21.53.03 # freddyb: I suspect that this is one of those patches that everyone has always wanted to do, only it's not extremely high on the priority list. Nice to see that someone finally does it :) 21.53.13 # amen 21.53.46 # As far as I am concerned, it's not wanted, it's needed! 21.53.46 # I bet im not the only one who clicks ont he sim buttons and wonders why nothing happens :p 21.54.04 # Ok, I try take some time and include all the players. 21.54.31 # * gevaerts has added a few comments 21.55.03 # also, remote buttons would be very useful 21.56.06 # New commit by 03bluebrother (r24626): Update Rockbox Utility version to 1.2.5 21.57.59 Nick AlexP_ is now known as AlexP (~ap@rockbox/staff/AlexP) 21.58.13 # New commit by 03bluebrother (r24627): Tag rbutil 1.2.5 release. 21.59.56 Join _zic [0] (~user@91-165-229-6.rev.libertysurf.net) 22.00.01 Quit _zic (Client Quit) 22.01.44 Join froggyman [0] (~sopgenort@pool-72-69-210-48.chi01.dsl-w.verizon.net) 22.03.35 Quit archivator (Remote host closed the connection) 22.05.09 Join moos [0] (moos@rockbox/staff/moos) 22.05.25 # What target has buttons on remote? 22.06.10 Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) 22.06.36 # * domonoky would think that all remotes (in rockbox) have buttons.. 22.11.14 # what remote would it be without buttons? ;) 22.12.15 # chances of that being useful are indeed remote 22.12.28 # It would be a great remote for my niece... 22.12.38 # gevaerts: Even for you.... :) 22.13.38 # this of course will eventually lead to swappable remote backdrops for the h300 (3 remote types) 22.13.40 # Irivers H100 and H300, the Iaudios, the M:robe500 (100 uses the same remote I think but I don't know if it is implemented). There are some non-lcd remotes which are not simulated thoug afaik 22.14.02 # Is the gigabeat remote implemented in the sim? 22.14.08 # I don't think so 22.15.21 # that's what I meant with "some non-lcd remotes", there are non-lcd remotes for the Archos Recorders too 22.16.19 # and H10 (that's another one which I'm not sure if it is supported by Rockbox though) 22.21.32 Join astigous [0] (~c8456ec6@giant.haxx.se) 22.23.37 Join castigous [0] (~c8456ec6@giant.haxx.se) 22.23.42 # Hi! 22.23.57 # is there anybody out there? 22.24.44 # lots of people are here 22.24.56 # if you have a specific question, please just ask it. 22.26.13 # Thanks! 22.26.31 Quit astigous (Quit: CGI:IRC (Ping timeout)) 22.26.49 # I just used the first time the new (?) *compressor* function of the 3.5 version and ... 22.27.20 # * JdGordon_ cant hold in his suspense 22.27.23 # all the battery was dead in a matter of minutes (and I don't have my charger with me SNIFF) ... 22.27.41 # New commit by 03mt (r24628): branches/mdctexp: Modify ATRAC3 codec to use the new MDCT library, ~1.2% speedup on Sansa E200. 22.28.09 # is there any settings to the compressor (threshold, gain, knee, etc) that could help reduce the excessive cpu utilisation? 22.28.48 # castigous: really? in a matter of minutes? or are you exaggerating a bit? :) 22.29.09 # ...because I really have a good use for this feature (L listened to classical and metal music, etc random mixed in a playlist) 22.30.21 # well it was at 47% when I turned it on, and +/-45 minutes later KABOOM, it depleted the whole battery and the player is brand new ... 22.31.11 # I would REALLY love to use this but not if Iḿ going to be deprived of the use of my player... 22.31.36 # Which player is this? 22.31.36 # castigous: what player is that and which version of rockbox are you running? (i.e., daily build, standard 3.5, etc) 22.32.43 # so, any suggestions about it - the player is a brand new Sansa Fuze v1 with v3.5 and it runs pretty extensively (although I haven't measured it yet) without the compressor and with replaygain ... 22.33.17 # which by the way kind of works but not as good as the compressor (it was working great for my situation but...) 22.33.26 Quit linuxguy3 (Ping timeout: 252 seconds) 22.33.29 # s/..././ 22.34.30 Join linuxguy3 [0] (~timj@adsl-76-203-23-66.dsl.emhril.sbcglobal.net) 22.38.16 Quit grndslm (Remote host closed the connection) 22.39.00 # Adnyxo: so, no suggestions? 22.39.07 # ot comments? 22.39.43 # well, you're the first to report anything like this afaik 22.40.26 # Personally, i've been using the compressor since day 1 and can easily squeeze 10+ hours out of my ipod 5.5 22.42.25 # castigous: replaygain working worse than the compressor? You do have replaygain tags in your files, do you? 22.42.35 # yeah, it was a *big* surprise to me when the voice told me I had 15% percent of battery and then a couple of minutes later (I dont remeber x%) and then shut itself off 22.43.03 # castigous: replaygain depends entirely on your files having tags. and it serves a different purpose than the compressor. 22.43.31 # yes, I have replagain (track) applied by foobar and it works but not so much in a noisy environment and with the kind playlist genre mix that I usually do 22.44.53 # well, yes, in a noisy environment you might want the quiet *parts* of songs made louder, which is something replaygain is not intended to do 22.45.16 # but the compressor worjed pretty great (although with the max threshold), I could hear the pianissimos (super soft passages) of classical music, and later don become deaf with a modern mixed and mastered song 22.47.51 # * TheSeven will quickly check compressor power consumption on nano2g 22.48.29 # 47% might not actually be 47% 22.48.44 # I know that several of my players don't report an accurate battery reading immediately upon boot. 22.49.05 # JdGordon: I think I got your coordinates figured out on the simulator for --debug-wps 22.49.09 # I'd suggest running a proper battery bench on the player with and without compressor just to see what the real difference in consumption is. 22.50.04 # I like mixing genres because have lots of (different genres of) music to learn from and when in street I like to be surprised by the next song... 22.50.18 # no noticable difference on nano2g 22.50.27 # freddyb: sweet :) 22.50.29 # maybe 1mA, but definitely not more 22.51.52 # with an without compressor: 18mA 22.52.24 # and* 22.53.07 *** Saving seen data "./dancer.seen" 22.53.31 Join komputes [0] (~komputes@ubuntu/member/komputes) 22.55.02 Join pamaury [0] (~pamaury@ALyon-551-1-70-117.w92-137.abo.wanadoo.fr) 22.57.44 Join perfectdrug [0] (~marko@p5B0EF1A7.dip.t-dialin.net) 22.57.45 # so, should I activate the debug mode? where I put the result, here or in the forums? 22.57.57 # What debug mode? 23.00.37 # how do you get last.fm to work with rockbox? 23.01.43 # Turn on last.fm logging 23.01.54 # Then scrobble the resulting log file 23.03.17 # Hi, thanks I will do it (at home when I can charge it :) 23.04.31 # Thank you fellas, I need to go for now but I will try to consult the debug and post the results later 23.04.38 # Thanks you all, Bye! 23.04.51 Quit castigous (Quit: CGI:IRC) 23.04.52 # AlexP: he probably means battery_bench 23.05.15 # yeah, maybe 23.06.29 # AlexP: where do i turn on last.fm logging? 23.06.46 # and I think he thougt the last.fm log was his answer, and he tries to scobbles the batteryissue 23.06.55 # togetic: It is in the menus somewhere, check the manual 23.07.10 # perfectdrug: Oh really :/ 23.10.02 # thanks AlexP 23.10.29 # no worries 23.10.36 Quit moos (Ping timeout: 265 seconds) 23.10.43 Quit komputes (Ping timeout: 272 seconds) 23.11.39 # New commit by 03mt (r24629): branches/mdctexp : Remove svn:executable property. 23.14.28 # Grrr. Why don't #ifdef's magically appear wherever they belong??? 23.15.29 # freddyb: there's a shortcut for that - C-x M-c M-ifdef 23.17.55 # archivator: Yeah, but you have to :wq emacs this_friggin_file.c first 23.18.43 # freddyb: Nice patch. :) 23.19.18 Join petur [0] (~peter@d54C6F9B2.access.telenet.be) 23.19.19 Quit petur (Changing host) 23.19.19 Join petur [0] (~peter@rockbox/developer/petur) 23.20.07 # just an FYI, I'm giong to commit multifont tomorow night or sunday unless someone objects 23.20.12 # Thanks 23.21.51 Quit krazykit (Read error: Connection reset by peer) 23.22.37 # JdGordon_: Did you still need whatever it was last night testing? 23.22.47 Quit bluebrother (Ping timeout: 260 seconds) 23.23.19 # I dont really remember what it was, so assume no 23.23.24 Join krazykit [0] (~kkit@ppp-70-236-33-106.dsl.ipltin.ameritech.net) 23.23.43 # I tihnk it was to see if the latest fm patch broke it, but its muh more likely that its hwcodec only 23.23.49 Join komputes [0] (~komputes@ubuntu/member/komputes) 23.24.28 # OK :) 23.24.29 Join bluebrother [0] (~dom@f053153090.adsl.alicedsl.de) 23.24.30 Quit bluebrother (Changing host) 23.24.30 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 23.33.01 Quit evilnick_B (Quit: Page closed) 23.34.53 Join moos [0] (moos@rockbox/staff/moos) 23.35.10 Quit komputes (Ping timeout: 256 seconds) 23.36.23 Join komputes [0] (~komputes@ubuntu/member/komputes) 23.38.30 Quit mt (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]) 23.39.20 Quit froggyman (Quit: lost my left side but I'm all right now...) 23.42.59 # * bertrik is struggling with the radio on the c200v2 again 23.44.53 # can a plugin load a codec and decode a compressed file? 23.45.48 Join p3tur [0] (~petur@rockbox/developer/petur) 23.48.25 # in theory it should be able to, probably need to add a bunch of functions t the plugin api to do it though 23.49.00 # have a look at test_codec 23.50.30 # I just had a crazy idea - if it's possible, it might be possible to turn fft into a viewer (as well as its current mode) - that way you could take all the time in the world to do a proper analysis. 23.58.39 # should be possible. and if not, just make it possible ;-)