--- Log for 21.09.116 Server: karatkievich.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 7 days and 3 hours ago 00.21.43 Quit edhelas (Ping timeout: 250 seconds) 00.29.20 Quit The_Prospector (Read error: Connection reset by peer) 00.32.05 Quit xorly (Ping timeout: 255 seconds) 00.35.08 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) 00.42.08 Quit ZincAlloy (Quit: Leaving.) 00.59.21 Quit girafe2 (Read error: Connection reset by peer) 01.16.58 Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-11d.dhcp6-bl.indiana.edu) 01.20.22 *** Saving seen data "./dancer.seen" 01.29.30 # Build Server message: 3New build round started. Revision 9dc4b00, 255 builds, 15 clients. 01.39.11 # Build Server message: 3Build round completed after 581 seconds. 01.39.12 # Build Server message: 3Revision 9dc4b00 result: All green 01.39.13 # Build Server message: 3New build round started. Revision 5e2600e, 255 builds, 15 clients. 01.39.31 # <[Saint]> We really need to figure out which method we want to commit in order to work around modern gcc in rockboxdev.sh 01.39.51 # <[Saint]> My method, pamaury's method, [7]'s method, etc. 01.40.25 # <[Saint]> I opt for mine, personally - but...I would. 01.40.43 # [Saint]: [7] method is better but I am holding back because I am lazy and I want to commit the mips toolchain fix at the same time. But that requires switch a toolchain which is a lot of work 01.40.51 # what is your method? 01.44.06 # [Saint]: ^ 01.44.30 # My method is a gcc patch. [7] is a MAKE flag and yours is? 01.48.08 # <[Saint]> Mine is changing CFLAGS to use -fgnu89-inline 01.48.30 # Build Server message: 3Build round completed after 558 seconds. 01.48.31 # Build Server message: 3Revision 5e2600e result: All green 01.48.32 # <[Saint]> I do this directly in rockboxdev.sh, this is likely the simplest approach, IMO. 01.49.18 # <[Saint]> just s/CFLAGS=-U_FORTIFY_SOURCE ../$toolname-$version/configure/CFLAGS="-U_FORTIFY_SOURCE -fgnu89-inline" ../$toolname-$version/configure/g 01.49.40 # <[Saint]> somewhere around line 21* in recoboxdev.sh 01.49.57 # <[Saint]> No makefile fuckery, no gcc patching. 01.50.22 # <[Saint]> pamaury: ^ 01.50.41 # <[Saint]> (sorry, I had to run off and deal with a cat puking on my rug :P) 01.50.50 # that's [7] method 01.50.57 # but it breaks the mips toolchain 01.51.10 # because it's so old it doesn't know about -fgnu89-inline 01.51.13 # :) 01.51.57 # <[Saint]> IIRC, [7] was doing this at the makefile level - his approach was functionally similar, but mine was a little more...direct. 01.53.10 # ah ok, anyway what you described is what I had in mind 01.53.22 # except for this problem with mips toolchain 01.53.54 # <[Saint]> I haven't played too much with the new mipsel toolchain, though I do recall it being a problem, in so far as fixing mipsel breaks armeabi and vice versa. 01.54.55 # <[Saint]> I ended up in a state where, basically, with a bleeding edge Arch or Debian system I could compile one or the other - but not both. 01.55.58 # <[Saint]> I think I should finish and commit for review my installation wrapper for prebuilt toolchains. 01.56.44 # <[Saint]> Realistically, I don't think end users, even if they intend on modifying Rockbox and compiling their own builds, have any business building and rebuilding toolchains that haven't (and won't) been changed in a decade. 01.57.35 # <[Saint]> The thing holding my back is that I couldn't really test for or test on esoteric architectures and operating systems. 01.58.41 # <[Saint]> The little wrapper I built was very simple and could only deal with x86/x86_64 and it assumed the distribution was a Debian derivative. 01.59.46 # <[Saint]> I understand that being able to compile the toolchains is a very important thing, but I don't see any reason why end users or those wanting to join the build farm should have to do so. 02.00.20 Quit alexweissman (Remote host closed the connection) 02.04.09 # I don't have any objection to giving prebuilt toolchain. I just want to make sure we can always build them from source if we need (which is not the case currently anyway) 02.04.16 # bedtime for me 02.04.37 # <[Saint]> I would like to get these problematic toolchains armeabi/mipsel/arm-ypr0 to compile against modern build tools, and then compile them for x86/x86_64/armel/armhf/aarch64/etc. and just provide a wrapper to install them. 02.05.15 # <[Saint]> I'm perfectly willing to host them. I doubt it will be high traffic. 02.05.51 # <[Saint]> Though I understand there's some other project I forget the name of that is using our armeabi toolchain. 02.06.27 # <[Saint]> For me, honestly, the biggest problem in the toolchains is the fucking arm-ypr0 toolchain. 02.06.33 # I was thinking about YP-R0. There is a simple fix for it which would be 1) don't build an dynamically linked executable (ie build a static one) so we don't depend on the system 2) change the toolchain version so that it compiles. 02.06.33 # We cannot do 2) without 1) because currently we need to match at least glibc, but I don't see why we really want to do that (except maybe to same RAM). 02.06.34 Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-11d.dhcp6-bl.indiana.edu) 02.07.28 # I least on the Sony NWZ linux port that I am planning to do, that's what I am doing. This solves all the problem and we don't have to build the crazy sony toolchain 02.07.46 # ok bedtime for real now, but you can think about it 02.07.50 # <[Saint]> o/ 02.07.52 # <[Saint]> night 02.08.56 Quit alexweissman (Remote host closed the connection) 02.17.38 Quit pamaury (Ping timeout: 260 seconds) 02.20.54 Quit __builtin (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 02.22.43 Join __builtin [0] (~xray@unaffiliated/franklin) 02.29.13 Quit __builtin (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 02.30.14 Join __builtin [0] (~xray@unaffiliated/franklin) 02.46.46 Quit duo8 (Ping timeout: 276 seconds) 02.47.03 Join duo8 [0] (~ZNC-SRV-H@116.107.158.100) 02.52.43 Quit robertd (Quit: Page closed) 03.09.56 Quit duo8 (Ping timeout: 244 seconds) 03.17.48 Join duo8 [0] (~ZNC-SRV-H@116.107.158.100) 03.19.15 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 03.20.23 *** Saving seen data "./dancer.seen" 03.37.13 Join saratoga [0] (497221ff@gateway/web/freenode/ip.73.114.33.255) 03.38.46 # pamaury: can you promote the imx targets to stable? i think the only thing missing is to tag a bootloader in git 03.48.22 Quit saratoga (Quit: Page closed) 03.49.42 Join shamus [0] (~shmaus@206.192.195.210) 04.03.40 Quit duo8 (Ping timeout: 265 seconds) 04.07.49 Join duo8 [0] (~ZNC-SRV-H@116.107.158.100) 04.15.02 Quit alexweissman (Remote host closed the connection) 04.19.57 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 04.27.13 Nick Strife89|Quassel is now known as Strife89 (~quassel@adsl-98-80-193-39.mcn.bellsouth.net) 04.48.32 Quit akaWolf (Ping timeout: 240 seconds) 05.00.08 Quit alexweissman (Remote host closed the connection) 05.01.32 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 05.13.51 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 05.20.24 *** Saving seen data "./dancer.seen" 06.10.59 Quit __builtin (Ping timeout: 260 seconds) 06.42.38 Quit TheSeven (Ping timeout: 250 seconds) 06.43.08 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.50.30 Quit idonob (Ping timeout: 265 seconds) 06.55.45 Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) 07.10.20 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:e58a:263c:68c3:cd4d) 07.20.27 *** Saving seen data "./dancer.seen" 07.28.54 Quit Bray90820 () 07.55.20 Quit ZincAlloy (Quit: Leaving.) 07.55.24 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 07.57.53 Quit bluebrother (Disconnected by services) 07.57.58 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 07.59.04 Join fs-bluebot [0] (~fs-bluebo@xd9bee3d2.dyn.telefonica.de) 08.01.10 Quit fs-bluebot_ (Ping timeout: 244 seconds) 08.02.16 Join ender` [0] (krneki@foo.eternallybored.org) 08.13.29 Quit pixelma (Quit: .) 08.13.29 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 08.16.04 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 08.16.05 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 08.19.15 Join edhelas [0] (~edhelas@145.133.43.230) 08.28.22 Quit edhelas (Ping timeout: 250 seconds) 08.43.23 Join xorly [0] (~xorly@ip-89-176-10-118.net.upcbroadband.cz) 08.44.53 Join edhelas [0] (~edhelas@145.133.43.230) 08.48.16 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.05.44 Quit edhelas (Ping timeout: 248 seconds) 09.17.20 Join petur [0] (~petur@rockbox/developer/petur) 09.20.28 *** Saving seen data "./dancer.seen" 09.21.28 Quit tchan (Ping timeout: 240 seconds) 09.24.08 Quit petur (Ping timeout: 265 seconds) 09.24.34 Join petur [0] (~petur@dD5E0153A.access.telenet.be) 09.24.34 Quit petur (Changing host) 09.24.34 Join petur [0] (~petur@rockbox/developer/petur) 09.27.46 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 09.37.22 Quit xorly (Ping timeout: 272 seconds) 09.43.32 Join elensil [0] (~edhelas@2001:1c02:1903:d800:1cee:8aad:dc3e:84ce) 10.12.52 Join MrZeus_ [0] (~MrZeus@81.144.218.162) 10.27.28 Quit hoshi (Ping timeout: 240 seconds) 10.30.15 Join goom [0] (~goom@cpe-66-25-153-174.satx.res.rr.com) 10.30.25 Join hoshi [0] (~hoshi@acck3.neoplus.adsl.tpnet.pl) 10.42.29 Quit goom (Quit: Leaving) 11.06.04 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 11.08.24 Quit JdGordon (Ping timeout: 248 seconds) 11.20.31 *** Saving seen data "./dancer.seen" 11.20.41 Quit olspookishmagus (Ping timeout: 265 seconds) 11.20.48 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 12.13.42 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 12.15.36 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 12.19.30 Join robertd [0] (c9d3b7fd@gateway/web/freenode/ip.201.211.183.253) 12.25.17 # saratoga (logs): yes I will do that tonight, and also try to have a manual for those too 12.33.38 Quit pamaury (Ping timeout: 260 seconds) 12.34.14 Join JdGordon [0] (~jonno@210.84.45.252) 12.34.14 Quit JdGordon (Changing host) 12.34.14 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 12.37.03 Quit JdGordon_ (Ping timeout: 244 seconds) 12.43.06 Join smoke_fumus [0] (~smoke_fum@188.35.176.90) 12.50.37 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 13.01.31 Quit shamus (Quit: chaos reigns within reflect repent and reboot order shall return) 13.03.26 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 13.06.02 Quit JdGordon (Ping timeout: 240 seconds) 13.20.35 *** Saving seen data "./dancer.seen" 13.33.20 Quit paulk-collins (Remote host closed the connection) 13.48.59 Join xorly [0] (~xorly@193.85.203.185) 13.56.28 Quit xorly (Ping timeout: 260 seconds) 13.58.04 Join xorly [0] (~xorly@193.85.203.185) 14.10.38 Quit Strife89 (Ping timeout: 255 seconds) 14.10.50 Join Strife89 [0] (~quassel@adsl-98-80-190-11.mcn.bellsouth.net) 14.16.18 Quit petur (Read error: Connection reset by peer) 14.16.44 Join petur [0] (~petur@dD5E0153A.access.telenet.be) 14.16.45 Quit petur (Changing host) 14.16.45 Join petur [0] (~petur@rockbox/developer/petur) 14.23.18 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:d536:6cd5:f64:2e9f) 14.35.25 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 14.40.17 Join p3tur [0] (~petur@rockbox/developer/petur) 14.42.42 Quit petur (Ping timeout: 265 seconds) 14.42.52 Nick p3tur is now known as petur (~petur@rockbox/developer/petur) 15.16.11 Quit duo8 (Ping timeout: 244 seconds) 15.19.02 Join duo8 [0] (~ZNC-SRV-H@116.107.158.100) 15.19.43 Nick MrZeus_ is now known as MrZeus (~MrZeus@81.144.218.162) 15.20.37 *** Saving seen data "./dancer.seen" 15.25.42 Join paulk-veyron-min [0] (~paulk@147.210.204.186) 15.35.38 Quit wodz (Ping timeout: 260 seconds) 15.44.17 Quit paulk-veyron-min (Quit: Leaving) 16.46.22 Quit petur (Read error: Connection reset by peer) 17.05.28 Quit nlogex (Ping timeout: 260 seconds) 17.08.25 Quit idonob (Read error: Connection reset by peer) 17.08.40 Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) 17.17.00 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) 17.17.15 # pamaury: sounds great, keep in mind we've never required a manual before to promote to unstable/stable 17.17.28 # so you don't need to wait for it to be done 17.17.59 # I know but most of them are easy targets and I'd like them to be done. At least the NZZ and also the ZEN X-Fi3 17.18.07 # *NWZ 17.19.18 # Also I have a question: I recnrly did some work on the STFM1000 tuner (found in NWZ and ZEN X-Fi3). It's working (at least basic playback, not recording or RDS). Do you think I should clean it up for the release or that can wait? 17.19.23 # *recently 17.19.48 # we haven't really decided on a release date 17.19.57 # for 3.14 17.20.16 # ok, I was thinking to clean up and commit. It cannot release hurt the release (since current state is not working and that would be maybe-work ;)) 17.20.38 # if you're worried about one specific device, at least promote to unstable 17.20.41 *** Saving seen data "./dancer.seen" 17.20.51 # right now we're probably discouraging a lot of users who would be fine with the current port 17.21.07 # yeah, I don't think the radio should be an item against stable 17.21.19 # the idea of stable/unstable was to let users know if a port could be used to play music reasonably well 17.21.29 # we probably have like 10 devices that fit that label but aren't listed 17.21.33 # I mean this radio tuner is incredibly hard to make it work, we'll never make it to stable if want full support 17.21.46 # ok 17.21.48 # also I updated the wiki with some bug/enhancements items 17.21.59 # we never intended stable to mean that everything worked perfectly, just that you could install rockbox on the device and reasonably play music 17.22.29 # unstable meant that and also you would have to be reasonably familiar with the command line or other tricks to install 17.22.30 # basically I did git log --author=me and translated that into human form 17.22.45 # yeah i saw, thanks 17.23.17 # We do have some ports where we support the FM tuner even if the OF doesn't (in some regions, anyway). This would merely balance things out :) 17.23.28 # haha 17.23.54 # hum by the way, who knows DSP and FM/RDS in particular? saratoga maybe? 17.24.05 # not very much 17.24.14 # I know bertrik has worked on rds 17.24.22 # I know but it's low-level RDS 17.24.32 # i looked at an RDS driver that was opens ource a while back just because i was curious about how they do the demoluation 17.24.33 # I have to do the demodulation in software 17.24.48 # can you use the linux one (or wherever it was from)? 17.24.53 # I have the OF code but it's incredibly complex 17.24.56 # writing those filters is probably painful 17.25.24 # I would prefer to understand how it works ^^ 17.27.43 # I never realised before that even stereo radio is a pain, you cannot simply use unfiltered audio, otherwise it sounds horrible 17.28.34 # ha yeah 17.28.35 # ftp://ftp.rds.org.uk/pub/acrobat/rbds1998.pdf 17.28.37 # Figure 2 17.30.33 # yeah I looked at that, I'm just not familar enough with DSP so that it really makes sense except at the theoretical level 17.31.54 # its a little different than the kinds of things i've done as well 17.32.21 # but the basic idea is that you have some carrier above the music, and from that you can recover a clock, then you look to see if there is a high-low transistion on clock edges or not 17.32.41 # that gives you the data stream, and then you have a whole mess of the data stream format above that 17.32.50 Join nlogex [0] (~filip@dhcp-108-168-15-90.cable.user.start.ca) 17.33.05 # Also I am not entirely sure which part of the diagram is implement by the tuner. It basically feeds me with the RDS signal at 38kS/s which is (i guess) the output of an ADC at (1) in the diagram of figure 2 17.34.42 # i guess it is probably 1, i don't think anything else would make sense 17.35.27 # i wonder if there is some local FM transmittor that supports RDS to compare to 17.35.31 # like for an ipod or whatever 17.36.15 # http://www.sears.com/sondpex-fm-transmitter-with-rds-technology/p-02806807000P?sid=IDx01192011x000001&gclid=CjwKEAjw34i_BRDH9fbylbDJw1gSJAAvIFqUN9RUh3EfjMj8L5NfxT6p5TXHBJlxv2Ehr8QwGD8b5hoChf3w_wcB&gclsrc=aw.ds 17.36.33 # this would have been a great class project in college 17.37.02 # but for example, when I looked at the sample (that was a while back), it was a little weird: the amplitude was going up and down (to 0) very slowly, suggesting a small drift between the tuner recovered subcarrier and actual subcarrier 17.39.18 # I read somewhere that the spec says that the 57Khz RDs subcarrier must be phase-locked on the pilot at 19Khz (makes sense form the diagram) but some (many?) emitters do not follow the spec 17.40.13 # thus if the tuner recover the pilot at 19Khz and uses that as the source of the 57Khz subcarrier, instead of recovering the 57Khz carrier directly, I expect that you run into some issues 17.58.17 Quit elensil (Quit: Leaving.) 18.17.19 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.24.09 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 18.26.15 Quit xorly (Ping timeout: 248 seconds) 18.37.27 Quit MrZeus (Ping timeout: 248 seconds) 19.11.07 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) 19.14.08 Join petur [0] (~petur@rockbox/developer/petur) 19.15.06 Quit pamaury (Remote host closed the connection) 19.20.45 *** Saving seen data "./dancer.seen" 19.34.00 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 19.51.39 Join krabador [0] (~krabador@unaffiliated/krabador) 20.03.12 Quit michaelni (Read error: Connection reset by peer) 20.03.42 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 20.18.18 Quit Moarc (Ping timeout: 272 seconds) 20.18.45 Join Moarc [0] (~chujko@a105.net128.okay.pl) 20.21.25 Join cereal_killer [0] (d5a244e9@gateway/web/freenode/ip.213.162.68.233) 20.26.55 # pamaury: rockboxdev.sh finished successfully and the Makefile was created 20.27.07 Join Bray90820 [0] (~bray90820@50-83-212-56.client.mchsi.com) 20.27.33 # But after typing "make" I get "error: lang.h: No such file or directory" 20.27.38 Quit Bray90820 (Read error: Connection reset by peer) 20.28.15 Join Bray90820 [0] (~bray90820@50-83-212-56.client.mchsi.com) 20.28.20 # rule for target ../apps/action.o failed 20.28.33 # cereal_killer: try "make clean" and then make 20.29.11 Quit Bray90820 (Read error: Connection reset by peer) 20.34.29 Quit krabador (Quit: Leaving) 20.59.16 Join Bray90820 [0] (~bray90820@50-83-212-56.client.mchsi.com) 21.00.18 # pamaury: thanks a lot. with your help, I successfully compiled my first Rockbox build 21.00.26 # now lets see, what it does on my D2 21.02.42 Join krnlyng_ [0] (~liar@77.117.30.113.wireless.dyn.drei.com) 21.05.02 Quit krnlyng (Ping timeout: 240 seconds) 21.11.43 # gevaerts: I compiled a build with the changes you mentioned 21.14.10 # playback works fine on the D2, also saving sound or theme settings, but trying to create a bookmark for the currently playing track results in "*PANIC* Updating size on empty dir entry 26" 21.16.55 Nick krnlyng_ is now known as krnlyng (~liar@77.117.30.113.wireless.dyn.drei.com) 21.20.46 *** Saving seen data "./dancer.seen" 21.21.53 Join girafe [0] (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr) 21.22.25 # should I try the builds before and after the filesystem rework? would this gather more information? 21.22.59 # saratoga: I will promote some targets to stable. I will update the main website, is that ok? (ie not waiting for the release) 21.23.23 # cereal_killer: I did not follow closely but I think the consensus was that before the filesystem rework, it worked by pure luck and after it didn't work 21.24.26 # oh, I see. 21.26.14 # but I might be wrong 21.26.36 # anyway, the reworked changed so many things that information before it will probably irrelevant 21.26.40 # unfortunately 21.29.06 Quit robertd (Quit: Page closed) 21.35.33 Quit Moarc (Ping timeout: 260 seconds) 21.37.52 Join Moarc [0] (~chujko@a105.net128.okay.pl) 21.39.07 # ok, thanks for your help. 21.40.11 # Build Server message: 3New build round started. Revision c534be0, 255 builds, 16 clients. 21.45.11 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 21.45.40 Quit cereal_killer (Ping timeout: 240 seconds) 21.48.10 Quit saratoga (Ping timeout: 240 seconds) 21.51.47 # Build Server message: 3Build round completed after 696 seconds. 21.51.48 # Build Server message: 3Revision c534be0 result: All green 22.07.40 Join edhelas [0] (~edhelas@145.133.43.230) 22.13.57 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) 22.17.52 # pamaury: can you also add a note under "Project news" saying you promoted some devices? 22.18.01 # sure 22.25.49 # saratoga: should it be a feature ? 22.30.13 Quit petur (Remote host closed the connection) 22.32.24 # pamaury: I mean on the front page 22.32.29 # above "3.13 released" 22.33.35 # isn't user manual required to get stable? 22.33.39 # ah, how does that work? it is hardcoded in the index.t? 22.34.01 Quit Kruppt (Quit: Leaving) 22.36.19 # lebellium: no, we never required it before, just a wiki page with instructions 22.37.05 # lebellium: http://www.rockbox.org/wiki/TargetStatus#Current_status_of_stable_targets 22.39.39 # I need to update this page too 22.44.26 # saratoga: oh ok 22.44.42 Quit denniskombucha (Remote host closed the connection) 22.57.21 # is it really possible to use A-B repeat on most players? 22.57.31 Quit girafe (Read error: Connection reset by peer) 22.57.36 # as far as I can see, it requires dedicated keys which I guess most players cannot spare 22.58.34 # or is there another way to set A and B points? 23.03.35 Quit atsampson (Quit: new irssi time) 23.03.56 Join atsampson [0] (~ats@cartman.offog.org) 23.10.48 # pamaury: it may be a key combination 23.11.01 # like power + left and power + right on Clip Zip 23.11.17 # so the lack of keys shouldn't be a huge issue 23.14.28 # not all targets can do combos 23.14.39 # and some combos are just crazy impossible (physically) 23.15.39 # why can't all targets do combos? 23.16.03 # damn, why does ACTION_STD_MENU means "go to main menu" in all screens except possibly where it means "context menu", which already has an ACTION_STD_CONTEXT... 23.16.16 # because some target cannot have two button pressed at the same time 23.19.06 # are you referring to some Creative and Sony targets? 23.19.18 Quit ArneB (Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number) 23.19.18 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 23.19.44 # lebellium: yes, but I am sure many other targets have this problem 23.20.06 # or only some combos, that are definable but I defy anyone to actually use them, are define 23.20.18 # I thought most targets used a combo to boot the OF for example 23.20.32 Join ps-auxw [0] (~arneb@p578F7060.dip0.t-ipconnect.de) 23.20.50 *** Saving seen data "./dancer.seen" 23.21.04 Quit Guinness (Read error: Connection reset by peer) 23.22.19 # usually the power button can be combo'ed with everything (but again there are counter example). But the power button make a terrible combo button on most targets because of its location 23.22.20 Quit advcomp2019__ (Ping timeout: 255 seconds) 23.33.41 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 49.0/20160916101415]) 23.41.47 Join shamus [0] (~shmaus@ip-206-192-195-210.marylandheights.ip.cablemo.net) 23.56.13 Quit paulk-collins (Quit: Leaving) 23.56.14 Quit alexweissman (Read error: Connection reset by peer) 23.56.45 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net)