--- Log for 30.09.112 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 1 month and 1 day ago 00.05.36 Quit Rower85 (Read error: Connection reset by peer) 00.06.07 Join Gallomimia [0] (~Gallo@d173-180-138-130.bchsia.telus.net) 00.09.26 # Seems to be a themesite issue. The daily checkwps run doesn't work well... 00.13.18 # hum ok 00.19.09 # gevaerts: database locket? 00.19.14 # locked* 00.19.23 # yes 00.26.45 # i just saw that when browsing the sitre 00.28.02 # We're doing something wrong with database accesses, but I'm not sure yet what exactly 00.37.48 # * gevaerts tells the database to use WAL instead of the older locking mechanism 00.38.00 Quit Gallomimia (Quit: Gallomimia) 00.39.22 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 00.43.06 Join perrikwp_ [0] (~quassel@cpe-075-177-082-185.triad.res.rr.com) 00.45.36 Quit perrikwp (Ping timeout: 252 seconds) 00.47.32 Quit perrikwp_ (Ping timeout: 240 seconds) 00.48.01 Join perrikwp [0] (~quassel@cpe-075-177-082-185.triad.res.rr.com) 00.51.44 # gevaerts: "DFKT Minimum X5 v3 INV Theme" says it "works with current build" on the theme overview (for x5) but "doesnt work with current build" on the theme details page 00.52.15 # Yes, that only *looks* like an inconsistency though :) 00.52.54 # The issue there is that on the overview the target is known, and on the detail page the first found target is used IIRC 00.53.10 Join Gallomimia [0] (~Gallo@209.87.18.21) 00.53.23 # wait what? that makes no sense :) 00.53.36 # the url has the target string 00.55.19 # I might be wrong, but as far as I remember that's not actually used to pick the right one 00.56.19 # Right. The code seems to agree with that 01.03.09 # I guess I already reported that here some months ago but I think mixing b&w and color themes for targets with the same screen resolution is a very bad idea. The color themes you can download in the H1x0 category (originally made for H10 20GB or X5) are just unusable on the H120 when auto-converted to grey-levels color 01.07.31 # OK, the checkwps run is done, with a lot of handholding... 01.07.53 # H10 and X5 now have the same themes 01.10.05 Join saratoga [0] (123e0cca@gateway/web/freenode/ip.18.62.12.202) 01.12.05 # lebellium: I think I agree, but I'm not sure how to even tell the difference from code... 01.12.34 # Base it on the upload target?> 01.13.50 # gevaerts: did you get a chance to look into approving new accounts on the forums? 01.15.03 # saratoga: I haven't done anything since last time, really 01.15.33 # I should be able to get to it soon though. The cold that made me a bit inactive seems to be going away 01.18.09 # ah ok 01.18.10 # thanks 01.18.47 # gevaerts: Isn't it possible to add a b&w/color field to each target? I assume there is already a touch/non touch field to make the difference between the themes for Cowon D2 and those for iPod video for instance? 01.21.59 # lebellium: there isn't, actually 01.22.26 # The theme site knows about resolution and checkwps results 01.24.44 # hum then why are there 105 themes for the iPod video but only 71 for the D2? I thought it was because only "touch-ready" themes display for the D2 01.24.57 # this theme website is a bit difficult to understand sometimes :S 01.26.01 Quit ender` (Quit: Our chances of being caught by the RIAA or IFPI are somewhat less than being hit by lightning - or choking on a wasabi-flavoured peanut. -- TheRegister) 01.26.25 # I checked one of those. It had touch areas that checkwps for the D2 doesn't like 01.26.41 # (and which are entirely skipped by checkwps for non-touch) 01.27.48 Quit Poodlemastah (Quit: ZNC - http://znc.in) 01.29.04 # ok, makes sense now. But that's far from being optimal in my opinion. 01.29.38 Join Poodlemastah [0] (~Poodlemas@h-253-206.a218.priv.bahnhof.se) 01.31.15 # I don't think adding a flag every time someone spots a feature difference is a good solution. Maybe we need a bit more information, but not without proper thinking 01.32.56 # You risk ending up with either unclear heuristics to deduce the flags based on the theme, or asking the uploader to supply lots of extra information that might be wrong 01.35.41 # well... actually among all current (and future?) targets, I only see 2 relevant infos needed: b&w or color display , and touch or non-touch device. If that info is linked to the target when it is added to the theme website, the guy who uploads a new theme has nothing to do but to select the appropriate target, no? 01.39.47 # Well, first of all, there are monochrome, greyscale and colour targets. It's not as simple as monochrome or colour :) How are these handled? Do colour targets get all themes, or only colour themes? 01.40.51 # Same for touchscreen, do touchscreen targets get all themes (remember, there's grid mode which some people even like!)? Do non-touchscreen targets get all themes? 01.41.01 # the question is: how many people install a monochrome/greyscale theme on a color target? I'm maybe wrong but I assume almost nobody? :) 01.41.12 # Why not? I don't know 01.41.57 # could we just have people check a "color" box when uploading themes? 01.43.03 # We could, or we could assume the theme matches the primary target they're uploading for 01.44.13 # that would work 01.49.36 # I think touchscreen is a lot harder to do automatically. Simple touchscreen themes will work fine on a non-touchscreen target, but some of those fancy themes won't work well at all. On the other hand, a simple non-touchscreen theme can be made usable on touchscreen with just a few touch areas, while the author primarily focuses on non-touchscreen and will upload for those 01.52.15 *** Saving seen data "./dancer.seen" 01.56.20 # the thing is that you don't design a theme for a touchscreen and non-touchscreen device the same way. For a touchscreen device you need bigger icons (play/pause/prev/next etc) to touch. I personnally would not want such a theme on a non-touchscreen device. But probably some people don't care about that 02.04.08 Quit n1s (Quit: Ex-Chat) 02.14.24 Join Armitaage [0] (~6c32a62a@www.haxx.se) 02.16.09 Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 16.0/20120925201946]) 02.18.10 # hi there. i have a bit of a problem that i'm not sure if it is answered elsewhere. My Sansa Fuze is behaving really strangely, it refuses to charge and claims that the playlist control file is invalid. i have tried updating the bootloader and rockbox, but the problem persists 02.19.02 Quit perrikwp (Read error: Connection reset by peer) 02.19.06 # i'd check the file system for errors, and see if there is a playlist control file you can delete 02.19.37 # where should i look to do that? 02.20.00 # rockbox folder i guess 02.21.01 # oh, and one other problem that i noticed. i can't connect mp3 player to comp in rockbox mode, it crashes every time 02.23.19 # says "data abort at 30051578 FSR 0x8 adress 0xAC5E5DD4 pc:30051578 sp:300A2ED4 bt end" 02.24.55 # FS#12184 ? 02.24.57 # http://www.rockbox.org/tracker/task/12184 3Fuze V1 locking when transferring files Rockbox 3.9 (bugs, unconfirmed) 02.25.01 # depending which fuze you have 02.29.24 Quit Gallomimia (Quit: Gallomimia) 02.32.24 Join Keripo [0] (~Keripo@c-76-22-63-234.hsd1.wa.comcast.net) 02.32.34 # yeah, looks like that is my issue, but i don't see the bug having been resolved. and what i see in the comments is mostly more reports of the bug, but no solutions. 02.35.36 # yeah been hoping someone who has that problem would tell me which commit broke it for over a year now 02.39.37 # i'm trying by reinstalling rockbox from the ground up, starting with the latest stable release 02.39.57 # i wouldn't bother 02.40.09 # its probably just some file system corruption 02.40.18 # that playlist thing anyway 02.40.59 # my player is completely unusable, and i need to be able to use it, lol. it has all my music on the go 02.41.35 # did you check the file system for errors? 02.42.25 # how would i do that? sorry, not a dev, a user here 02.43.21 # assuming your'e on windows, my computer > properties of the disk drive, check for errors 02.43.29 # if you're on some other OS, check the documentation 02.48.18 # hmmm...simply deleting the playlist control file seems to have fixed at least the resume playback function....but connecting to the pc is still icky 02.48.39 # yeah, probably just a corrupted file 02.49.05 # computer seems to not recognize the device 02.49.28 Quit Horscht (Quit: Verlassend) 02.50.36 Quit saratoga (Quit: Page closed) 02.53.05 Quit Keripo (Read error: Connection reset by peer) 02.55.12 Join Keripo [0] (~Keripo@c-76-22-63-234.hsd1.wa.comcast.net) 02.58.43 Join saratoga [0] (123e0cca@gateway/web/freenode/ip.18.62.12.202) 03.02.32 Quit mgottschlag (Ping timeout: 240 seconds) 03.05.51 # well, it's not really a fix, but i have a way to get to my music, charge, and connect to the comp. but it requires me to mess with things that i shouldn't have to 03.07.05 # everytime i want to change playlists i have to delete my playlist control file and restart the device, and it might take me several tries before i can access the player via my computer >.< 03.07.58 # that's pretty sucky, but it's all i've been able to do. thanks for the advice, though ^-^ 03.09.29 Quit Totalled (Quit: PETTAN PETTAN, TSURUPETTAN!) 03.09.46 Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) 03.14.55 Nick StopMakingSense is now known as PerfectlyNormalB (~fearofmus@unaffiliated/fearofmusic) 03.15.05 Nick PerfectlyNormalB is now known as LittleCreature (~fearofmus@unaffiliated/fearofmusic) 03.19.37 Join amayer [0] (~alex@h62.26.25.72.ip.windstream.net) 03.20.50 # i would just use the sandisk USB mode if you have the problem in the FS task 03.22.27 Join factor [0] (~factor@74.195.160.132) 03.33.55 Quit Staphylo (Read error: Connection reset by peer) 03.34.10 Join Staphylo [0] (~Staphylo@mareo.fr) 03.37.42 Quit froggyman (*.net *.split) 03.52.09 Quit eckoit (Quit: eckoit) 03.52.18 *** Saving seen data "./dancer.seen" 03.53.21 Quit Provel_ (Read error: Connection reset by peer) 03.58.02 Join Provel_ [0] (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 04.04.22 Quit Provel_ (Read error: Connection reset by peer) 04.04.44 Join Provel_ [0] (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 04.14.46 Join Guinness` [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 04.14.46 Quit Guinness (Read error: Connection reset by peer) 04.14.49 Nick Guinness` is now known as Guinness (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 04.15.24 Quit amiconn (Disconnected by services) 04.15.24 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.15.24 Quit pixelma (Disconnected by services) 04.15.25 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.15.27 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.15.30 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.16.11 Part amayer 04.22.31 Join froggyman [0] (~froggyman@unaffiliated/froggyman) 04.24.43 Quit factor (Read error: Connection reset by peer) 04.33.39 Join factor [0] (~factor@74.195.160.132) 04.36.51 Join perrikwp [0] (~quassel@cpe-071-076-186-173.triad.res.rr.com) 04.38.12 Join TheSphinX^ [0] (~briehl@p5B323AFB.dip.t-dialin.net) 04.42.08 Quit TheSphinX_ (Ping timeout: 276 seconds) 04.50.27 Join Guinness` [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 04.53.28 Quit Guinness (Ping timeout: 246 seconds) 04.53.28 Nick Guinness` is now known as Guinness (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 04.58.10 Quit perrikwp (Read error: Connection reset by peer) 04.59.23 Join perrikwp [0] (~quassel@cpe-071-076-186-173.triad.res.rr.com) 05.01.44 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 05.21.42 Quit Epicanis (Quit: bedtime) 05.22.25 Quit TheSeven (Disconnected by services) 05.22.35 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.41.23 # [7]: does the Classic support 48k? 05.41.45 # i see it defines it in the config file 05.41.57 Quit sciopath (Read error: Connection reset by peer) 05.42.17 Join sciopath [0] (~sciopath@yer91-2-82-237-54-159.fbx.proxad.net) 05.52.21 *** Saving seen data "./dancer.seen" 05.52.48 Quit zchs (Quit: Leaving) 05.56.13 # i'm confused by the sample rate code for the ipods 05.57.01 Quit Rower85 (Ping timeout: 246 seconds) 05.57.19 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 05.57.46 # whats the difference between audiohw_set_frequency and pcm_set_frequency ? 05.59.20 # in wm8975.c audiohw_set_frequency is a null op, but in cs42l55.c it actually changes the rate 06.03.54 Quit gxk (Ping timeout: 260 seconds) 06.10.52 Join gxk [0] (~gxk@bzq-79-179-225-137.red.bezeqint.net) 06.12.15 # actually, does anyone have an ipod classic who can test a patch? 06.21.34 # http://mit.edu/mgg6//www/rockbox_classic_sampr.zip 06.21.46 # if someone would install that build and then run the test_sampr plugin 06.21.50 # and see if 48k works 06.22.34 Quit Prodicus (Ping timeout: 246 seconds) 06.26.59 # by works i guess plays a tone that sounds right 06.31.47 Join JdGord [0] (~AndChat80@49.176.33.56) 06.39.56 Quit JdGord (Read error: Connection reset by peer) 06.45.18 Join JdGord [0] (~AndChat80@49.176.33.56) 06.47.49 Quit JdGord (Read error: Connection reset by peer) 06.59.23 Join JdGord [0] (~AndChat80@49.176.33.56) 07.00.41 Quit Armitaage (Quit: CGI:IRC (Ping timeout)) 07.04.14 Quit JdGord (Read error: Connection reset by peer) 07.19.06 Join eckoit [0] (~ryan@50.65.10.24) 07.21.47 Quit prof_wolfff (Ping timeout: 245 seconds) 07.44.54 Quit Keripo (Read error: Connection reset by peer) 07.52.24 *** Saving seen data "./dancer.seen" 08.19.52 Join pretty_function [0] (~sigBART@123.252.215.227) 08.56.09 Quit pretty_function (Remote host closed the connection) 09.31.02 Join pretty_function [0] (~sigBART@123.252.215.227) 09.33.39 Quit amiconn (Read error: Connection reset by peer) 09.33.39 Quit pixelma (Remote host closed the connection) 09.34.55 Join pixelma [0] (pixelma@rockbox/staff/pixelma) 09.34.55 Join amiconn [0] (amiconn@rockbox/developer/amiconn) 09.40.41 Join pamaury [0] (~quassel@5.157.114.2) 09.40.41 Quit pamaury (Changing host) 09.40.41 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.52.28 *** Saving seen data "./dancer.seen" 09.55.57 Join stoffel [0] (~quassel@pD9E430D4.dip.t-dialin.net) 10.00.15 Quit pamaury (Ping timeout: 246 seconds) 10.27.55 # JdGordon: ping 10.28.23 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.31.57 # <[Saint]> the thing is that you don't design a theme for a touchscreen and non-touchscreen device the same way. 10.32.03 # <[Saint]> I'm gonna disagree here. 10.32.15 # <[Saint]> Because, that's simply not true. 10.32.46 # <[Saint]> If we're talking about an "ideal world" then, maybe. 10.33.00 # <[Saint]> If we're talking about cabbiev2, then, certainly not. 10.33.06 # having done themes for both I agree with him 10.33.51 # <[Saint]> There's no reason to do so, though, but I think we've established before that your german fingers are siimply too fat :) 10.34.15 # i think he just meant that you approach differently depending on whether a theme is going to be touch-enabled or not 10.34.36 # <[Saint]> But, I don't...though. It can, and should, cater for both cases. 10.34.42 # I'm not saying you cannot do themes that work equally well on both 10.34.58 # <[Saint]> there's no need to have two themes for a target that shares almost everything, except entry type. 10.35.10 # <[Saint]> ZYou can detect, and switch conditionally. 10.35.21 # <[Saint]> this is why we have a "is touchscreen?" check. 10.36.07 # by switching conditionally you take a (perhaps only slighly) different design route 10.36.14 # <[Saint]> I used to make a habit of coding in touch regions for non-touch targets just in case the user might *one day* find a touch target to use it on. 10.36.42 # he said that the design differs, but both design can be in the same theme with a bit of work 10.38.34 # the point is: if you make one theme that's specifically for button-targets and one that's specifically for touchscreens, they will be different 10.38.59 # <[Saint]> I think I've proved otherwise there, and I stand by that. 10.39.00 # however with compromises and/or hard work you can build both into the same theme 10.39.52 # <[Saint]> My 240x320 theme is *exactly* the same for touch/non-touch. Only the larger sizes differ, because they can, and have room to. They don't *have* to, though. 10.40.47 # <[Saint]> Anyway, the reason why I brought it up is that I don't think "touchscreen" is a valid flag to determine what target is allowed which theme. 10.41.11 # yea 10.41.43 # even non-touch-enabled themes work fine in grid mode so it's not unreasonable to show them 10.42.57 # <[Saint]> and things like bars automagically make their own touch areas now, so a "simple" theme that includes absolutely no touch regions will at least be partly usable without any user intervention in absolute point mode. 10.43.12 # <[Saint]> its a very blurred line. 10.44.00 # the automatic touch region for bars dont make it touch-enabled 10.44.08 Quit factor (Read error: Connection reset by peer) 10.44.24 # it will change to back grid mode automatically 10.45.10 # even then, partuly usable would still be unusable if you cannot leave the wps 10.46.06 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 10.48.07 Quit XavierGr () 11.01.05 Join factor [0] (~factor@r74-195-217-135.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 11.02.33 Quit pretty_function (Ping timeout: 260 seconds) 11.12.26 Join pretty_function [0] (~sigBART@123.252.215.227) 11.33.24 Join ender` [0] (krneki@foo.eternallybored.org) 11.45.00 Quit bluebrother (Disconnected by services) 11.45.05 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 11.47.37 Quit fs-bluebot (Ping timeout: 245 seconds) 11.48.52 Join fs-bluebot [0] (~fs-bluebo@g226071098.adsl.alicedsl.de) 11.52.31 *** Saving seen data "./dancer.seen" 11.53.04 Join lebellium [0] (~chatzilla@f052147163.adsl.alicedsl.de) 11.53.52 Join bertrik [0] (~quassel@ip545056ba.adsl-surfen.hetnet.nl) 11.53.53 Quit bertrik (Changing host) 11.53.53 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 11.58.11 # [Saint]: I had the example of my theme in head. For example the 240*320 theme: http://themes.rockbox.org/index.php?themeid=1563 If we get a 240*320 touchscreen target one day, I don't see how my theme coud be compatible unless you want to touch the small play/pause icon in the top corner. I obviously designed it for a non-touchscreen target 11.58.28 # <[Saint]> "one day"? 11.58.41 # <[Saint]> There's millions of them. literally. 11.59.25 # I mean if we ever get a 240*320 touchscreen target* 11.59.30 # sorry for my english mistakes 11.59.45 # <[Saint]> And, I still meant "one day?" 12.00.02 # <[Saint]> Its one the the single most popular smartphone resolutions. 12.00.07 # <[Saint]> you're not thinking about RaaA. 12.01.10 # Indeed (for me 800*480 sounds more popular but there are many low-end android smartphones with bad 240*320 screen) 12.01.13 # <[Saint]> There shouldn't be any need for a "touchscreen theme" or a "non-touch theme", in my honest opinion, the reason there is such a thing is because theme authors are lazy. 12.01.50 # <[Saint]> It is entirely possible for the same theme to handle both cases, and *every* theme should. 12.02.52 # I don't see how that? Most themes have a single play/pause/next/prev/stop/recording icon because you don't need to display them all at the same time for a non-touchscreen device. And that saves space on the screen 12.03.29 # <[Saint]> so, display and position the items conditionally. 12.03.46 # <[Saint]> this is why we have a "is touchscreen?" condition. 12.05.27 # <[Saint]> "play/pause/next/prev/stop/recording" this also isn't a particularly good example. play/pause/stop can share a single space, and recording has its own screen, so the same control space can be used to stop/start recording. 12.06.41 # <[Saint]> "play/pause/stop" can easily be the same control space, with three different icons. The touchscreen cabbies all do this. 12.06.58 # Indeed. But you still need to display at least 3 icons: prev, next and play/pause. It's technically possible to doing it conditionally as you said but I don't know where I would get the space on my theme for that 2 more icons without redesigning it completely 12.07.50 # <[Saint]> if your theme has no visual representation of those cases for the "non-touch" case, then, (IMO) it is lacking to begin with. 12.10.13 # <[Saint]> (notice the "IMO", I think a theme should *always* display the current play state via some form on "universal icon" >>/<>/<<|/>/||/[]) 12.10.48 # kill the design to support the touchscreen 240*320 targets with the same theme? I won't and I assume other designers won't either. That's why I proposed to make a touchscreen/ non-touchscreen flag. 12.11.29 # <[Saint]> or, just....don't design for that resolution? 12.11.44 # <[Saint]> the touchscreen/non-touch thing *IS A REALLY BAD IDEA* 12.12.01 # <[Saint]> it is totally needless, and sets up more failure cases than it could fix. 12.13.48 # <[Saint]> If you can't fit basic user controls onscreen at all times without compromise, though, it seems to me that the theme needs to be re-thought anyway. 12.13.53 # <[Saint]> ...but, that's just me. 12.14.47 # <[Saint]> and, sorry, but I do see play state as a "basic user control" that *needs* a visual representation on a media player. Remember, these devices don't all have a nice hardware button for everything. 12.14.55 # Yeah that's a personal opinion. I think the contrary and will never redesign my theme that way. If I ever get a 240*320 touchscreen target I will just make a new theme optimized for it 12.15.55 # <[Saint]> well, I look at this from the perspective of the default theme. In Rockbox, we have touchscreen and non-touchscreen targets for 240x320, and I have *one* theme that covers both. 12.16.09 # <[Saint]> It wasn'tr easy to do, but, I did it and it works. 12.16.57 # what is your theme again? 12.17.17 # I don't know the real names by heart 12.18.04 # <[Saint]> I started to rework cabbiev2 for application builds (probably over a year ago now actually, ...heh), It's all in my github. 12.18.40 # so the cabbiev2 in my R0 is the same on a touchscreen target? 12.19.30 # <[Saint]> No, kugel took a slightly different approach. My work (with some debate and tinkering) should replace that or merge with it at a later stage. 12.19.58 # ah ok because from what I see currently on the R0 there is also a unique play/pause/stop/prev/next icon and I just find that OK 12.20.30 # <[Saint]> yeah, that's just...weird. 12.20.43 # <[Saint]> play/pause/stop *should* be the same icon, IMO. 12.20.55 # <[Saint]> well, not the same *icon*, but the same control space. 12.21.15 # <[Saint]> tap to play/pause, long tap to stop. 12.21.17 # <[Saint]> simple :) 12.21.22 # indeed 12.21.34 # the issue for me is only prev and next that would kill the design 12.22.41 # <[Saint]> if your "non-touch" variant included ffwd/rew icons, there'd be no issue. 12.22.46 # <[Saint]> you could reuse them. 12.23.48 # <[Saint]> tap to skip, long hold to seek. etc. 12.25.24 # indeed. But there is absolutely no more free space on my theme for 2 more icons. And on the 240*320 theme on the R0 I don't see free space either, I would be curious to see how you added the prev/next icons :) 12.25.37 # cabbiev2* 12.25.54 # kugel: Sorry, didin't get to look last night 12.26.11 # And I agree that touchscreen and non-touchscreen themes are different 12.26.40 # but anyway 12.27.49 # <[Saint]> AlexP_: I agree they're different too...I seem to be being misinterpreted. 12.28.09 # If you are using the have touchscreen tag then you are essentially designing two themes in one file 12.28.12 # <[Saint]> I agree they can be totally differnet, I do *not* agree, however, that there needs to be seperate themes for each case. 12.28.48 # I won't be adding the non touchscreen case to mine, show me a non touchscreen 720x1280 target first :) 12.29.27 # <[Saint]> you don't need to, see the beauty? your touch theme "just works" as long as there are HW keys. 12.29.39 # Why would I bother? 12.29.43 # There aren't any 12.29.55 # And it needs lots of conditional casing making it much more complicated 12.30.25 # It is a different design paradigm in many ways, I don't see how trying to force the two together makes sense 12.30.29 Quit pretty_function (Ping timeout: 244 seconds) 12.30.31 # <[Saint]> the conditional casing is less complication that two themes for the same target. 12.30.35 # Sometimes it does, and then great 12.30.39 # I disagree with that 12.30.55 # <[Saint]> your case is individual, though, as there's no non-touch case for your resolution. 12.31.10 # <[Saint]> for shared targets, then, yeah...I think one theme should be handling both. 12.31.17 # One of the worst things you can do re touchscreen design is to try to force touch onto a standard theme, they just demand different things 12.31.30 # And I don't see the advantage of shoving two themes into one file 12.32.13 # <[Saint]> it would solve some of the nightmare that is the default theme. 12.32.29 # Not really 12.32.46 # That could be solved equally well, if not better, by having a touchscreen optimised default theme 12.33.16 # <[Saint]> ...that's what I'm trying to do.. 12.33.36 # I meant as a seperate entity 12.33.45 # <[Saint]> I just don't think it means I have to stop caring about non-touch cases to do so. 12.33.45 # If you can force both into one file, then great 12.34.07 # No, you ave different ones for each, each optimised for their use case 12.34.22 # Instead of one that (potentially) isn't ideal for either 12.34.30 # No if you can manage that in one, then great 12.34.39 # s/No/Now/ 12.34.42 # But anyway, there isn't a right answer and the great thing about freedom of choice is freedom to do what you want :) 12.35.37 # <[Saint]> "No, you ave different ones for each, each optimised for their use case" if it was that way, I'd have left it alone :) 12.35.46 # ? 12.36.05 # <[Saint]> I took the opportunity to work on optimizing some of the ~4 year old theme code too, and saw that I could kill multiple birds, etc. 12.36.40 # <[Saint]> I wouldn't call the non-touch cabbie "optimal", is my point. But, I'm trying to get there. 12.36.40 # Whether they are in one file or two, they are different - perhaps to a small extent, perhaps to a large extent 12.36.51 # That is very subjective 12.36.59 # As is pretty much everything about themeing 12.37.10 # <[Saint]> obviously so :) 12.37.28 # Right, so you can't say, this is right, that is wrong (a generic you) 12.38.11 # <[Saint]> There's brand name me's? 12.38.22 # heh :) 12.38.37 # I meant one, not you personally :) 12.38.43 # <[Saint]> I also think you missed the points where I've stated "this is my opinion". Its not a right/wrong thing...I don't care what he does. 12.38.58 # <[Saint]> Ohhhhh, wow...I took that wrong, then :) 12.39.25 # You also said things like "that's simply not true." 12.39.33 # Which isn't the case 12.39.37 # But anyway 12.40.13 # <[Saint]> Its non-false as well...hmmm. 12.40.20 # It is your opinion 12.40.25 # Truth doesn't come into it 12.40.26 # <[Saint]> Heh, yeah. Subjective stuff. 12.41.01 # yep 12.42.53 Quit stoffel (Ping timeout: 240 seconds) 12.54.02 # one design thing that will always differ between touch and non-touch: non-touch shows the playing state (i.e. normally a play icon) while touchscreen shows a play state button (i.e. normally a pause button sicne pressing it pauses playback) 12.55.18 # * [Saint] should point out that he's not saying that themes should be *identical*, but rather that the design needn't vary simply because one target is touch and one isn't. 12.56.13 # <[Saint]> the above is a great example of this actually. 12.56.25 # it's a design variation 12.56.37 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 12.56.59 # <[Saint]> yes, it is...? 12.57.04 # for non-touch you design icons as indicators, for touch you design them as buttons 12.57.06 # <[Saint]> (not sure where that was going) 12.58.08 # <[Saint]> It doesn't necessarily mean you design them differently, though, does it...or, it needn't have to. 12.58.19 # <[Saint]> I mean, you just used existing icons too...right? 12.58.44 # yes sure. but the theme design (not the looks of the icons) is different 13.00.30 # <[Saint]> so, when you say "but you design them as "...what does that mean exactly? 13.00.41 # <[Saint]> If you're not actually changing them at all, then...? 13.01.00 # it does not just mean the look of the icons 13.01.28 # <[Saint]> sorry, when speaking about icons, I thought it was limited to icons. 13.02.13 # icons are a subset of a theme design 13.03.09 # with "design them as ..." i meant what purpose they are for, and therefore at which times they show up 13.03.26 # <[Saint]> sorry...I missed where you were going. You started with "one thing that must differ" (being the icons), and then stated that they in fact remain the same...and now, you're talking about other things...and, I'm lost. 13.04.05 # I didn't mean that the icon graphics differ, but their purpose 13.04.05 # <[Saint]> Oooooh, right. You last post makes the original one a LOT easier to understand. 13.05.03 # <[Saint]> Yes, and my theme(s) are doing that too...because it's needed. But, that's the only part that differs (visually) between touch and no-touch. 13.05.22 # so, even if you use the same graphics; in a non-touch theme icons act as indicator, while on a touch one they usually act as button label 13.07.14 # this is what I meant by "approach differently depending on whether a theme is going to be touch-enabled or not" 13.08.13 # <[Saint]> and, that's where we part ways I think. As, I don't think a theme should be "touch only" unless it will only ever run on a touch enabled device. 13.08.57 # <[Saint]> though, perhaps you mean the touch case, or non-touch case, and not necessarily that it should be seperate themes. 13.09.18 # i never said they need to be separate themes 13.09.38 # i said it's doable to build both designs into the same theme 13.10.13 # but it requires work and perhaps compromises so not everyone can be bothered 13.13.13 # <[Saint]> The entire point of me bringing it up, and the subsequent confusion...and then getting stuck on other topics, was due to me taking issue at the idea of the themesite checking for touch/non-touch, and just in case there's any more room for confusion: "I think it's a really bad idea" :) 13.13.54 # <[Saint]> This isn't me saying "all themes should handle all cases", however. 13.15.08 # if it's a bad idea but all themes should not necessarily handle all cases, then people with a touchscreen device will see a lot of unusable themes in their target category 13.15.40 # <[Saint]> lebellium: no, they will see exactly no unusable themes. 13.15.47 # <[Saint]> Every theme is usable to them. 13.16.15 # <[Saint]> You're forgetting about grid mode, which some people actually like. Which some people even use by coice. 13.17.08 # <[Saint]> If thetre's no touch tags present in a theme loaded on a touchscreen target the default used to be to switch to grid mode so that the currently loaded theme would still be usable. 13.17.13 # <[Saint]> I believe this is still the case. 13.17.56 # Indeed I forgot about that grid mode... 13.18.24 # * [Saint] just noticed that the *-800x480x16 and *-480x800x16 bitmaps are mostly (all?) identical. 13.18.28 # <[Saint]> lol, how did that happen? 13.19.55 # <[Saint]> ah, "mostly identical". 13.20.28 # <[Saint]> There's a few have been duplicated for seemingly no reason, probably to avoid naming collisions prior to commit(?). 13.20.30 # when talking about separate themes for touchscreen and non-touchscreen targets on the theme website I just had the touch tags in mind, I totally forgot about that grid mode, sorry 13.20.47 # there could be a checkbox that hides grid-mode themes 13.22.07 # <[Saint]> or, do some magic and print something in the blurb like we do fr "works with " 13.22.15 # <[Saint]> s/fr/for/ 13.23.00 # <[Saint]> Ohhhhh....actually, this is a problem. 13.23.11 # <[Saint]> The new theme behaviour breaks this assumption. 13.23.44 # <[Saint]> There will now not *ever* be a case of a theme not having a touch tag present if it includes any bar-type tags. 13.24.08 # did you read what I wrote above? 13.24.42 # (above/earlier) 13.24.49 # <[Saint]> I did, yes. But I'm wondering how the new bar tag behaviour affects this. 13.25.08 # <[Saint]> Since they now draw all their touch areas automatically. 13.25.21 # the automatic touch region for bars dont make it touch-enabled, it will change to back grid mode automatically 13.25.26 # <[Saint]> (and it needs to be specifically disabled by the author if this is unwanted) 13.25.35 # you are wrong :) 13.26.21 # the bar-tag regions are excluded from the logic which determines touch-enabledness 13.26.34 # <[Saint]> "the automatic touch region for bars dont make it touch-enabled" Oh, right. Well, that's a good thing. Slightly broken, but, broken in a way that works. 13.27.23 # well, it's this way because JdGordon pushed it to be default 13.27.41 Join Horscht [0] (~Horscht@p549477BA.dip.t-dialin.net) 13.27.41 Quit Horscht (Changing host) 13.27.41 Join Horscht [0] (~Horscht@xbmc/user/horscht) 13.28.35 # <[Saint]> the "slightly broken" bit I was referring to was the fact that the theme would have touch tags but still not technically be "touch enabled". 13.28.59 # <[Saint]> But, for the record, I don't like the default behaviour of the bar tag touch areas either...and, said so at the time. 13.29.36 # i know 13.30.08 # we're in the same boot in this case 13.38.18 # [Saint] I don't know if you did read that but from my tests the %s tag is necessary for the RDS text to properly scroll and that worked correctly in the older builds. Should I open a bug ticket on the website or the right people are already aware of all RDS issues? 13.39.00 # saratoga: i could test on my classic, but it has to charge a bit first 13.39.05 # <[Saint]> I think "the right people" are aware already, but you should open a bug anyway. 13.43.57 # lebellium: it would be nice if you could find the commit that introduced the problem (heard of git bisect?) 13.45.37 # btw, could we tag the branch point? this would allow to bisect issues like "doesnt work in current build but last release" more easily 13.47.50 # kugel: that will be difficult as I don't compile builds myself, I just download builds on the RB website :S For the Clip Zip I used an old April build on my computer to compare with the latest builds but for the R0 lorenzo gave me a recent RDS build. That would be interesting to compile the RDS patch with an old build to see if that still makes my theme crash 13.51.34 # <[Saint]> setting up a development environment will take 30~60 mins. 13.51.45 # <[Saint]> bisection another ~60mins. 13.52.33 *** Saving seen data "./dancer.seen" 13.52.49 # I'm using Windows 7, not Linux, I'm not in this development world (yet?) ;) 13.55.13 # lebellium: set up a VM then! 13.56.27 # I already have a VM for Windows XP (necessary to run the Samsung recovery tools) but I don't have a single GB or MB left on my HDD for a new OS, the situation is critical lol 14.03.21 Quit bertrik (Remote host closed the connection) 14.09.20 # <[Saint]> couldn't you just run the recovery tools in compatibility mode? 14.09.34 # <[Saint]> I thought & was supposed to be entirely backward compatible still. 14.09.40 # <[Saint]> s/&/7/ 14.10.45 # The issue is just the drivers, The Samsung R&D in Korea lives in the past with 32-bit only drivers which can't be installed on any 64-bit OS. Yet, most computers run Win 7 64-bit.... 14.11.12 # <[Saint]> Hahahahah...in what world are you talking about? 14.11.20 # <[Saint]> "Most computers" run XP. 14.11.52 # I meant most computers sold today run Win 7 64-bit, not Win 7 32-bit except some netbooks 14.16.17 # I would object to having grid mode themes presented as touch themes 14.16.20 # They just aren't 14.16.38 # We would annoy a huge amount of people if we did that, they just aren't proper touch themes 14.29.12 # i think it depends, there are targets where grid mode is default 14.29.21 # e.g. cowond2 (iirc) 14.30.55 # [Saint]: according to some sources win7 has surpassed win xp 14.34.26 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 14.34.52 Join prof_wolfff [0] (~prof_wolf@213.37.219.103.dyn.user.ono.com) 14.36.03 # Ha, that was easy. Now I can load fully resolved elfs as plugins. I can't figure out how to strip elfs. plugins.make just don't like me. 14.36.16 # Time to approach relocations... 14.43.04 # [Saint]: replacing your 20-DroidSans-Bold.fnt font I use for RDS text by another font like the Rocbox one, the R0 doesn't crash anymore but the RDS text still behaves crazy when scrolling. 14.59.37 # Oh! I found something interesting. When displaying RDS name and RDS text in separate viewports, the RDS text is not crazy anymore! 15.05.04 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 15.10.01 # oh gosh that also fix the crash issue! Oo But why is putting %ty and %tz in the same viewport that bad?! that did not cause any issue with the older builds as far as I know! 15.18.31 Quit wodz (Quit: Leaving) 15.19.57 Join Prodicus_ [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 15.20.22 # Buschel: looking closer at celt_decode_with_ec the freq and X buffers are only used at the same time in denormalize_bands, freq is never used before and X is never used after so i hacked up a patch to share the same buffer for them which saves some iram when allocing them on iram 15.20.23 # http://pastebin.com/XtJ5KVj9 15.21.07 Join pretty_function [0] (~sigBART@123.252.215.227) 15.21.16 # it works but is fairly ugly 15.21.21 Quit Prodicus (Ping timeout: 246 seconds) 15.23.53 # X is a int16_t and freq is int32_t 15.24.42 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 15.25.34 Quit Prodicus_ (Ping timeout: 256 seconds) 15.33.21 Quit guymann (Quit: brb) 15.33.49 Join guymann [0] (~c@unaffiliated/guymann) 15.35.18 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 15.35.21 Quit guymann (Client Quit) 15.35.42 Join guymann [0] (~c@unaffiliated/guymann) 15.36.55 Quit sciopath (Quit: Quitte) 15.39.18 Quit Provel_ (Ping timeout: 260 seconds) 15.42.13 Join Provel_ [0] (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 15.48.22 Join Provel [0] (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 15.50.00 Quit Provel_ (Ping timeout: 245 seconds) 15.52.35 *** Saving seen data "./dancer.seen" 15.55.34 Quit bzed (Ping timeout: 260 seconds) 15.56.59 Quit Provel (Read error: Connection reset by peer) 15.57.17 Join bzed [0] (~bzed@devel.recluse.de) 15.57.24 Join Provel [0] (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 16.22.36 Quit Provel (Ping timeout: 246 seconds) 16.22.46 Join stoffel [0] (~quassel@pD9E430D4.dip.t-dialin.net) 16.23.08 Join Provel [0] (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 16.30.25 Quit n1s (Read error: Connection timed out) 16.40.41 Quit stoffel (Remote host closed the connection) 17.11.49 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.19.12 Quit pretty_function (Remote host closed the connection) 17.29.07 Quit mgottschlag (Ping timeout: 255 seconds) 17.30.52 Quit Provel (Read error: Connection reset by peer) 17.31.19 Join Provel [0] (~Provel@75-132-15-43.dhcp.stls.mo.charter.com) 17.37.13 Join perrikwp_ [0] (~quassel@cpe-071-076-186-173.triad.res.rr.com) 17.39.53 Quit perrikwp (Ping timeout: 257 seconds) 17.41.09 Join stoffel [0] (~quassel@pD9E430D4.dip.t-dialin.net) 17.52.37 *** Saving seen data "./dancer.seen" 18.04.10 Join Keripo [0] (~Keripo@c-76-22-63-234.hsd1.wa.comcast.net) 18.04.14 Join pretty_function [0] (~sigBART@123.252.215.71) 18.10.02 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 18.18.08 Quit Totalled (Quit: PETTAN PETTAN, TSURUPETTAN!) 18.18.11 Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) 18.18.26 Join Totalled [0] (~Totalled@c-98-245-9-211.hsd1.co.comcast.net) 18.21.54 # n1s: about your freq/X patch. why do you set X to freq[C*N/2]? and not simply to freq[0]? 18.22.08 Nick AlexP_ is now known as AlexP (~alex@rockbox/staff/AlexP) 18.23.15 Quit wodz (Read error: Operation timed out) 18.23.39 Quit Keripo (Read error: Connection reset by peer) 18.24.39 # n1s: i do not think this approach is too hacky. i would define a static char-array of 1920*MAX(sizeof(celt_sig), sizeof(celt_norm)) in IRAM and would simply cast it then, e.g. "freq = (celc_sig*) s_buf; X = (celt_norm*) s_buf;" 18.26.30 # n1s: could you measure the other parts of the patch (comb_filter, memcpy in celt.c, the index-changes to mdct.c/kiss_fft.c)? 18.32.30 Quit pretty_function (Read error: Operation timed out) 18.32.55 # n1s: btw, where does this 1920 come from? 18.33.11 Join Keripo [0] (~Keripo@c-76-22-63-234.hsd1.wa.comcast.net) 18.44.08 # n1s: ok, just found out about the index shift when setting X 18.47.05 Quit mgottschlag (Read error: Operation timed out) 18.47.27 # n1s: nevertheless we should have the static allocation of two seperate buffers submitted first. and move the "joined" buffer solution in a second submit. this is benefit *if* we should have overssen something and need to bisect some day 18.49.41 Quit guymann (Quit: oops) 18.54.43 Join pretty_function [0] (~sigBART@123.252.215.71) 18.56.30 Join guymann [0] (~c@unaffiliated/guymann) 18.59.15 Quit Buschel (Ping timeout: 246 seconds) 19.00.23 # [7]: http://www.head-fi.org/t/532426/ipod-classic-rockbox-its-happening/1515#post_8738388 19.01.51 Quit pretty_function (Ping timeout: 246 seconds) 19.06.04 Join pretty_function [0] (~sigBART@123.252.213.240) 19.10.01 # <[7]> saratoga: sorry, no idea 19.10.08 # <[7]> it's been ages since I implemented this 19.10.26 # no idea what your comment was referring to? 19.11.04 # <[7]> well that sampling rate stuff which apparently isn't working 19.11.04 # Note: Disable output before calling this function 19.11.24 Quit stoffel (Remote host closed the connection) 19.13.18 # that code is called above in audiohw_preinit, so i guess one of the other registers might need to be set before changing that clock 19.13.56 # or perhaps cscodec_reset 19.15.14 # <[7]> well those comments on the forums seem to be nonsense - there shouldn't be any need to mess with the pcm driver 19.15.57 # <[7]> cscodec_reset is a very bad idea 19.16.23 # <[7]> it is crucial for audiohw_preinit to be called before audiohw_set_frequency 19.16.47 # <[7]> audiohw_preinit will set the sampling rate to 44100Hz 19.17.01 # does sample rate changing even work on the Classic right now? 19.17.13 # <[7]> I think it should, but I'm not sure if it has been tested at all 19.17.17 # as far as I can tell it shouldn't (but i'm not too familiar with this code) 19.17.26 # <[7]> why shouldn't it? 19.17.30 Quit perrikwp_ (Read error: Connection reset by peer) 19.17.43 # <[7]> that /* Note: Disable output before calling this function */ is probably copied from another driver 19.17.55 # <[7]> not sure if it's strictly necessary for this codec, probably not 19.18.06 # <[7]> but it's generally a good idea 19.18.13 # i think pcm_set_frequency will do nothing since pcm_dma_apply_setting is a NOP 19.18.29 # <[7]> that's fine because pcm doesn't even need to know the frequency 19.18.44 # <[7]> the cs42l55 is operating as the i2s master and thus controlling the sampling rate 19.18.53 # isn't that access point for the plugin API though? 19.18.55 # <[7]> i.e. the i2c write in audiohw_set_frequency is the only thing you should need to do 19.19.00 # if that is a NOP how would something cahnge the rate? 19.21.46 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.21.50 # have you tried the test_sampr plugin on the 6G? 19.28.59 Quit Horscht (Quit: Verlassend) 19.29.44 Join Epicanis [0] (~Epicanis@static-72-95-113-7.port.east.myfairpoint.net) 19.29.57 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 19.30.49 Join Buschel [0] (~chatzilla@p57905E53.dip.t-dialin.net) 19.41.59 Join lorenzo92 [0] (~chatzilla@host67-111-dynamic.21-79-r.retail.telecomitalia.it) 19.44.33 Quit Keripo (Quit: Leaving.) 19.51.01 Quit Rower85 (Quit: Hmmm...) 19.52.39 *** Saving seen data "./dancer.seen" 19.55.24 Quit ender` (Read error: Connection reset by peer) 19.56.50 Join ender` [0] (krneki@foo.eternallybored.org) 19.57.52 Quit linuxstb (Quit: This computer has gone to sleep) 19.59.54 Join linuxstb [0] (~linuxstb@host86-136-64-97.range86-136.btcentralplus.com) 20.03.23 # saratoga: i have an ipod classic (120 GB), if you want anything to be tested on that target let me know 20.04.07 Quit the-kyle (Quit: Leaving.) 20.05.18 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.06.13 # kugel: finally tested your patch, A+, works perfectly ;) 20.07.29 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 20.08.28 Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) 20.08.32 # kugel: little help with git, if I remove the gpio patch, then need to do again simply git commit? I fetched git freshly, then applied your patchset using the patch url... 20.09.07 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 20.10.47 Quit Rower85 (Read error: Connection reset by peer) 20.11.02 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 20.19.08 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 20.20.05 # pff did a bullshit...sorry you all...is it possible to remove an entry in gerrit? -.-" 20.20.54 # well it is correct, but not really hehe 20.26.36 # <[Saint]> anyone else find it interesting the "bricked" Clip+ was detected as an M200Plus by some lowlevel magic b0hoon managed to trigger? 20.27.08 # <[Saint]> from: http://forums.rockbox.org/index.php/topic,35776.msg205797.html#msg205797 20.27.21 # okay, let's ask somehting different... does anyone knows why software keypad lock works in WPS only? Is there a particular reason? 20.29.17 Quit pamaury (Ping timeout: 245 seconds) 20.32.18 # <[Saint]> lorenzo92: I believe it's only intention was to prevent interruption to playback. 20.32.38 # <[Saint]> It isn't to prevent all arbitrary accidental keypresses. 20.33.03 # [Saint]: yes, logical, but then why don't enable it also in the FM radio screen? 20.33.32 # moreover targets with physical lock can be lock in any screen... 20.33.39 # *locked 20.34.19 # <[Saint]> they also have a physical lock to do so with, and don't need to rely on hardware keys that may already be mapped to other functions. 20.35.04 # <[Saint]> my suspicion is either: a - no one thought of it, or, b - crowded keymaps and blocking keys made this a nightmare. 20.35.49 # <[Saint]> I'm leaning towards the latter, as I know what a nightmare keymaps are. 20.39.28 Join pystar89 [0] (~pystar89@ip-5-146-40-148.unitymediagroup.de) 20.43.50 # indeed :) but it *may* be a good idea to add the keylock also in FM screen, at least...as suggested by some users 20.48.34 # updated YP-R0 wiki ;) 20.50.44 # kugel: why is "Battery charging" in the TargetStatus page labelled as partial for YP-R0? We need definitely work out the USB to make this port stable, I have ideas but rockbox code crashes :p 20.58.18 Quit XavierGr (Read error: Connection reset by peer) 21.03.15 Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) 21.10.11 Quit pretty_function (Ping timeout: 248 seconds) 21.25.04 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 21.38.39 Quit y4n (Quit: We're fucking 3LN!) 21.42.33 # Buschel: the 1920 comes from the static mode, and stereo and yeah sure, doing either change separately is probably nicer 21.43.17 # I'll try to test the other parts of your patch during the week 21.46.10 # perfect, i'll let you know if i should find any other optimization 21.52.40 *** Saving seen data "./dancer.seen" 21.53.48 Join freqmod [0] (~quassel@cm-84.215.142.108.getinternet.no) 21.54.12 # http://gerrit.rockbox.org/r/#/c/319/ - anything more i can do to get this in to trunk? 22.01.26 Quit lorenzo92 (Quit: ChatZilla 0.9.89 [Firefox 15.0.1/20120907231657]) 22.01.40 Join amayer [0] (~alex@h62.26.25.72.ip.windstream.net) 22.09.36 # freqmod: tell someone to push it :) I have no idea what it's supposed to fix though 22.10.39 # accordik to bertik http://gerrit.rockbox.org/r/#/c/300/ "* Seeking ported from speex, but fails on some cases (e.g. seek to granule 0)" 22.10.45 # alternatively if you're going to be working on opus more, we could probably just give you git write access 22.11.13 # well, i don't plan to work more than bugs i encounter 22.11.18 # *than on bugs 22.12.09 # basically it disables my code to guess where to jump to for long seeks (to speed it up for targets with disks), which are a bit flakey 22.12.18 # and handles granule 0 as a special case 22.15.06 Quit factor (Quit: Leaving) 22.16.52 # but if you want to give me access, it could be useful to have 22.17.02 # * freqmod is planning to do a codec2 codec interface 22.17.14 # it is finished, but no fixed point of codec2 exists yet 22.18.15 # and the bitstream doesn't look to get frozen in the near future 22.19.42 Quit guymann (Quit: exit(EXIT_FAILURE);) 22.20.29 Join guymann [0] (~c@unaffiliated/guymann) 22.22.02 # still some work to be done on codec2. personally from my experience it seems like his sample files do a lot better than anything I encode myself, which makes me wonder if he's overtrained things. 22.23.29 # hehe 22.23.33 # i have the same experience 22.23.47 # but i have only transcoded mp3's 22.24.39 # however it does create listenable sounds in about 1 kpbs 22.24.50 # so i was thinking about encoding the whole librivox library 22.25.09 # I've worked from lossless originals- recordings of myself and recordings from a conference 22.25.21 # hmm 22.25.42 # he should probably get some more test samples to tune for 22.26.54 # as you say, for huge audiobook libraries the possibility of getting something at 2kbps is tantalizing and the quality it already hits at 1.4k makes one think it could be good enough to work well at ~2 22.28.16 # he supposedly made a better codec at 3,6kbps a week ago 22.28.44 # however i think i would still go for 1,2 kbps as the difference between 3,6 and 10kbps opus is much more 22.29.04 Quit benedikt93 (Quit: Bye ;)) 22.29.31 # yeah, for a lot of applications the quality improvement from moving to mediumband rather than narrowband is pretty obvious. 22.30.31 Quit guymann (Quit: brb) 22.31.14 Join guymann [0] (~c@108-237-202-52.lightspeed.wlfrct.sbcglobal.net) 22.31.31 Quit guymann (Changing host) 22.31.31 Join guymann [0] (~c@unaffiliated/guymann) 22.36.39 Join scorche` [0] (~scorche@75-174-198-34.phnx.qwest.net) 22.36.39 Quit scorche (Disconnected by services) 22.36.39 Quit scorche` (Changing host) 22.36.39 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 22.39.45 Quit Buschel (Quit: ChatZilla 0.9.88.2 [Firefox 15.0.1/20120905151427]) 22.46.08 Quit wodz (Quit: Leaving) 22.55.17 Join lebellium_ [0] (~chatzilla@e179142095.adsl.alicedsl.de) 22.57.12 Quit lebellium (Ping timeout: 245 seconds) 22.57.26 Nick lebellium_ is now known as lebellium (~chatzilla@e179142095.adsl.alicedsl.de) 22.58.46 Join Strife89 [0] (~Strife89@207.144.201.128) 23.03.20 Join factor [0] (~factor@r74-195-217-135.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 23.12.02 Quit factor (Read error: Connection reset by peer) 23.17.23 Join scorche [0] (~scorche@rockbox/administrator/scorche) 23.17.55 Quit scorche` (Read error: Connection reset by peer) 23.20.29 Join factor [0] (~factor@74.195.160.95) 23.32.57 Quit n1s (Quit: Ex-Chat) 23.34.33 Quit Strife89 (Quit: Connection reset by deer.) 23.48.10 Quit freqmod (Remote host closed the connection) 23.52.43 *** Saving seen data "./dancer.seen" 23.53.06 Quit the-kyle (Quit: Leaving.) 23.55.24 Quit Prodicus (Read error: Connection reset by peer) 23.56.04 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net)