| 00:03:37 | | Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) |
| 00:24:06 | | Quit munkis (Ping timeout: 260 seconds) |
| 00:37:10 | | Quit m01 (Quit: Konversation terminated.) |
| 00:39:00 | othello7 | wait why is mpegplayer being removed? |
| 00:39:09 | | Join m01 [0] (~quassel@vps-b172b88b.vps.ovh.net) |
| 00:44:01 | __builtin | buZz: heh, that was me asking about the 6G piezo_start() function |
| 00:44:21 | __builtin | I think I can walk you through what the code means: |
| 00:44:56 | __builtin | my understanding is that timer A on the SoC is used in GPIO mode to output a digital signal to the piezo |
| 00:45:49 | __builtin | so the trick is configuring the timer to output the right square wave that you want |
| 00:46:04 | __builtin | CH23: ^ |
| 00:46:59 | __builtin | the code you see in piezo_start() is configuring timer A through a series of memory-mapped registers ("TA<XXX>") |
| 00:49:59 | __builtin | the timer itself is driven from an external 12 MHz crystal (ECLK), which is then divided down to a 100 kHz clock by the configured prescaler values |
| 00:51:02 | __builtin | the "cycles" argument to piezo_start() is the number of (1/100 kHz) cycles you want the square wave period to be |
| 00:51:38 | __builtin | so if you want a 1 kHz tone, you set cycles=100 |
| 00:51:57 | __builtin | (100,000/1,000 = 100) |
| 00:52:22 | __builtin | and the "periods" argument is the number of full cycles to play for |
| 00:53:20 | __builtin | the "periods" argument takes effect through the interrupt handler, INT_TIMERA, which I think gets called on each full cycle of the timer |
| 00:54:33 | __builtin | the "force" parameter to piezo_button_beep isn't relevant at all here - that forces the method to spinlock until any previous tone has completed playing |
| 00:54:51 | *** | Saving seen data "./dancer.seen" |
| 00:57:55 | | Join munkis [0] (~mendel_mu@70-59-89-230.mpls.qwest.net) |
| 01:00 |
| 01:01:10 | __builtin | speachy: re: mpegplayer, I think some wider discussion is warranted before deciding to remove it |
| 01:06:23 | _bilgus | i'm still not sure the use case there it seems a novelty at best |
| 01:06:31 | __builtin | the only real maintenance burden it presented was the need to define keymaps for it during new ports, and it was still fully functional prior to being removed |
| 01:07:18 | _bilgus | like 1-3 " video can compete with phones not to mention the yuv routines |
| 01:07:51 | __builtin | sure - the YUV code is probably a couple KB of core code, but only on targets with plenty of RAM to spare to begin with |
| 01:07:59 | _bilgus | and asm |
| 01:08:23 | __builtin | my stance on this kind of thing is "if ain't broke, don't fix it" |
| 01:09:04 | __builtin | I think there are still viable use-cases where audio+video playback on a media player is a good thing to have |
| 01:09:52 | __builtin | and there's probably a non-zero number of users still with little music videos encoded for playback on their devices |
| 01:10:03 | _bilgus | i think if thats the case it should probably carry its own routines and remove the burden from core at least |
| 01:10:20 | _bilgus | if possible |
| 01:13:41 | __builtin | I don't think that's technically desirable... it looks like the YUV code depends on lots of target-specific optimized blitting code |
| 01:13:51 | __builtin | which, sure, we could throw into apps/plugins |
| 01:14:11 | __builtin | but it wouldn't make technical/logical sense to do so |
| 01:15:04 | _bilgus | i'm thinking more like ditch the hand assembly in favor of a slightly slower c routine |
| 01:15:18 | _bilgus | thats the big drawback imo |
| 01:15:32 | _bilgus | and maintenance/porting burden |
| 01:15:34 | __builtin | why do that? the hand assembly is already written and presumably still works |
| 01:15:55 | __builtin | so for existing targets, the maintenance burden ought to be zero, unless you run out of code space |
| 01:16:17 | __builtin | or majorly change the assumptions of the LCD code, but if you're doing that, you're in for a lot of work anyway |
| 01:16:40 | __builtin | and new targets can (and have, apparently) easily define a stub blit function to no-op it |
| 01:17:21 | | Quit munkis (Ping timeout: 252 seconds) |
| 01:17:41 | __builtin | (and it looks like there was already a slow C fallback, as you describe) |
| 01:17:54 | __builtin | so new ports had the option of just falling back to that |
| 01:18:31 | | Join munkis [0] (~mendel_mu@70-59-89-230.mpls.qwest.net) |
| 01:18:43 | | Join dfkt [0] (~dfkt@62-178-144-183.cable.dynamic.surfer.at) |
| 01:19:31 | _bilgus | I still think that would be a decent compromise but will wait for speachy to state the onus |
| 01:22:34 | __builtin | I do think that the discussion about removing fully functional features ought to be had in a more visible venue (either mailing lists or forums) |
| 01:31:03 | | Quit dfkt (Quit: SIC GORGIAMVS ALLOS SVBJECTATOS NVNC.) |
| 02:00 |
| 02:49:01 | | Quit CH23 (Ping timeout: 246 seconds) |
| 02:54:52 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:01:09 | | Join lebellium [0] (~lebellium@2a01cb040109a600492d39b33bbdb7f2.ipv6.abo.wanadoo.fr) |
| 03:28:37 | | Quit S|h|a|w|n (Read error: Connection reset by peer) |
| 03:40:57 | | Quit rogeliodh (Quit: Ping timeout (120 seconds)) |
| 04:00 |
| 04:06:51 | | Join rogeliodh [0] (~rogeliodh@144.91.64.242) |
| 04:40:48 | | Quit rogeliodh (Quit: Ping timeout (120 seconds)) |
| 04:42:52 | | Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) |
| 04:54:55 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:17:12 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 06:17:14 | | Quit pixelma (Quit: .) |
| 06:19:38 | | Join amiconn [0] (jens@p200300ea87273400305e95fffec66ff3.dip0.t-ipconnect.de) |
| 06:19:38 | | Join pixelma [0] (marianne@p200300ea87273400305e95fffec66ff3.dip0.t-ipconnect.de) |
| 06:54:58 | *** | Saving seen data "./dancer.seen" |
| 06:57:03 | | Join CH23 [0] (~CH23@revspace/participant/ch23) |
| 07:00 |
| 07:14:53 | CH23 | hactar|ant, the iPhone 7 plus' taptic engine has some testpads, which when accessed, you only need the first and last one to connect to the ribbon pads where the piezo normally sits. here's a tutorial: https://www.youtube.com/watch?v=crWU0Khyanw and some pics of mine: https://imgur.com/a/qdALXxb |
| 07:16:00 | CH23 | it feels really nice to use, and somehow still makes the same sound as it did with the piezo |
| 08:00 |
| 08:26:01 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 08:35:53 | | Quit amachronic (Ping timeout: 252 seconds) |
| 08:55:01 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:45:27 | | Quit michaelni (Ping timeout: 268 seconds) |
| 09:58:22 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 10:00 |
| 10:18:32 | rb-bluebot | Build Server message: New build round started. Revision d73aaf3d9e, 303 builds, 7 clients. |
| 10:46:27 | rb-bluebot | Build Server message: Build round completed after 1675 seconds. |
| 10:46:29 | rb-bluebot | Build Server message: Revision d73aaf3d9e result: 120 errors 0 warnings |
| 10:55:02 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:02:18 | rb-bluebot | Build Server message: New build round started. Revision 70d5b2cd45, 303 builds, 7 clients. |
| 11:09:27 | | Join S|h|a|w|n [0] (~shawn156@user/shawn/x-4432647) |
| 11:21:39 | speachy | mpegplayer was really not anything more than a tech demo, and its limitations are so severe (by modern standards) that it's useless as a selling point/feature. |
| 11:26:00 | speachy | it requires re-encoding videos for the specific device, which in turn has a (very) crappy and tiny screen. |
| 11:26:58 | speachy | I posted the original patchset over a year ago, and I recall a bunch of discussion at the time, though it largely withered into general apathy. |
| 11:28:07 | speachy | and yes, we've been fighting display code space on a lot of targets, and the plugin API has some prtty nasty things in it just to accomodate the mpegplayer plugin. |
| 11:29:18 | speachy | that was one of the reasons I dragged everthing forward to the (Then-)newer toolchains, and went through the pain and bugs uncovered by using -Os by default. |
| 11:31:19 | rb-bluebot | Build Server message: Build round completed after 1742 seconds. |
| 11:31:20 | rb-bluebot | Build Server message: Revision 70d5b2cd45 result: All green |
| 11:31:35 | _bilgus | woot |
| 11:31:59 | speachy | yeah, my combined UL speed of "19" :D |
| 11:32:32 | speachy | I have another ...36 cores that I could light up for builders but what's the point, given that performance... |
| 11:33:14 | _bilgus | I'm just happy not to have to wait a whole day to compile the whole shebang |
| 11:34:00 | speachy | ...If Ian had hit here we'd have lost 60% of our builders for a little while |
| 11:34:31 | speachy | plus the only ones that can handle the android and ibasso builds |
| 11:35:22 | _bilgus | re mpegplayer is it possible to self contain it, it'd hit performance but disconnect it from core −− I saw that there were c routines.. not saying you should do it but if someone is really passionate about it |
| 11:36:48 | _bilgus | I'm still of the thought that 3k for a single novelty plugin is too much even before looking at the asm burden |
| 11:36:54 | speachy | I'm of the strong opinion that we need to focus our limited efforts on making our core features kickass, as audio playback is the _only_ reason we'd attract new users. |
| 11:37:35 | _bilgus | udio and blind users |
| 11:37:39 | _bilgus | audio |
| 11:37:54 | speachy | a bottom-of-the-barrel smartphone (which is cheaper than any working rockbox-capable player you'd find these days) will do a far, far better job of video playback. |
| 11:38:02 | speachy | audio and accessibility, exactly. |
| 11:38:40 | speachy | if we're going to go for a moonshot project it would be a bluetooth stack with AVRCP support. |
| 11:38:48 | buZz | i mostly want to build rockbox as application on a gcc from this millenium |
| 11:38:49 | buZz | :P |
| 11:38:59 | speachy | on a gcc? |
| 11:39:05 | buZz | yes |
| 11:39:11 | _bilgus | I'm still not impressed with bt audio TBH |
| 11:39:17 | buZz | eg. not gcc 4.x |
| 11:39:30 | buZz | but gcc 8.x or higher |
| 11:39:30 | speachy | ah, ok, I thought you meant something else |
| 11:39:54 | buZz | :) i'm one of the devs on Maemo Leste, and its still missing a 'nice' mediaplayer |
| 11:40:11 | buZz | thought rockbox might fit, but i dont really desire to build a ancient gcc just for a single application |
| 11:40:28 | speachy | the good news is thanks to the sim builds the core is quite fine with modern gcc, but there's always the bare-metal shenanigans. |
| 11:40:49 | buZz | nice :) well, 'as application' doesnt have bare metal? |
| 11:41:05 | buZz | should just be libsdl for everything i guess? |
| 11:41:07 | speachy | all of my buidlers are running Gcc 12.1 right now. |
| 11:41:13 | buZz | oh wait, is it libsdl1 ? |
| 11:41:25 | speachy | yes, we support a generic SDL target. |
| 11:41:36 | speachy | libSDL1, but yes. |
| 11:41:48 | buZz | meh, libsdl1 is pretty ancient too |
| 11:42:56 | speachy | most of our hosted targets run on top of low-level linux APIs (eg fbdev, alsa, /dev/input) but sdl hides all of that |
| 11:43:22 | speachy | you can use sdlcompat12 (?) which is a wrapper for SDL1 on top of SDL2 libs. |
| 11:44:22 | buZz | oh fancy |
| 11:44:23 | speachy | there's a good argument for not swithcing to SDL2 natively though, as IIRC the latter pretty much requires OpenGL. |
| 11:44:40 | buZz | yeah OpenGLES2 is the only output that works on my target device ;) |
| 11:44:41 | speachy | ie there's no dumb fbdev display backend. |
| 11:45:19 | buZz | quite sure SDL2 still supports fbdev though? |
| 11:45:24 | speachy | nope |
| 11:46:01 | speachy | at least not at the time I was experimenting with it. SDL2's display API is built around the notion of display lists instead of raw pixel buffers. |
| 11:46:12 | buZz | ah, there's directfb , not fbdev |
| 11:48:17 | speachy | huh, it directly supports kms/drm. Too bad we don't have even that on our hosted targets. :/ |
| 11:53:17 | braewoods | speachy: what do we use for display on hosted? X? FB? |
| 11:53:45 | speachy | I think they all use fbdev. |
| 11:54:01 | speachy | (don't recall what the ibasso targets use) |
| 11:54:46 | braewoods | I see. I was thinking SDL2 could be useful for RB general development on the desktop. |
| 11:54:55 | braewoods | For testing stuff without having to get out a hardware unit. |
| 11:55:07 | speachy | it wouldn't gain us anything over SDL1 beyond a more modern baseline. |
| 11:55:23 | speachy | the simulator builds already run on SDL. |
| 11:55:50 | braewoods | And would be a massive undertaking to port to. |
| 11:55:56 | speachy | (and there's a generic SDL target allowing for an arbitrary (at compile-time) screen size meant for hosted use. |
| 11:56:59 | speachy | no, I don't think so. the only real work would be to change the existing SDL1 display code to run on SDL2, and since we only sling pixmaps around there wouldn't be much actual change wrt interfacing with SDL itself. |
| 11:57:39 | speachy | (I think input, audio, and threading APIs are unchanged or effectively so) |
| 11:57:50 | braewoods | I see. |
| 11:58:23 | speachy | what _would_ be more useful is a native pthead-based threading/semaphore backend. |
| 11:58:44 | speachy | that would make hosted targets a lot more responsive. |
| 11:59:00 | braewoods | Wouldn't that require mutexes and more? |
| 11:59:48 | braewoods | It reminds me of issues with GTK+ where it can get weird because of the single threaded event loop it uses. |
| 12:00 |
| 12:00:04 | speachy | sure, but we already have them so... |
| 12:00:24 | braewoods | Applications are expected to use threads on their own if they need them for application processing. |
| 12:00:44 | braewoods | Background threads so to speak. |
| 12:00:59 | speachy | we already are heavily threaded internally. |
| 12:55:03 | *** | No seen item changed, no save performed. |
| 12:55:10 | hactar|ant | ch23 so it's that little module that goes where the battery traditionally sits? that's very cool. is that a common mod? i haven't heard of it |
| 13:00 |
| 13:53:50 | CH23 | hactar|ant i'm not sure how common it is, i think it's slowly becoming a trend right now. |
| 13:56:53 | hactar|ant | it fits so neatly in there |
| 14:00 |
| 14:04:16 | CH23 | i have tried soldering to a case but it wouldn't take solder, to maximise the tranfer of vibration to the case. but it's already good this way |
| 14:08:25 | hactar|ant | wouldn't that make it difficult to replace the hold switch if that was necessary? |
| 14:09:52 | CH23 | there's just about enough space to do so |
| 14:55:05 | *** | No seen item changed, no save performed. |
| 15:00 |
| 15:23:41 | speachy | buZz: I'm attempting to build a series of gcc8.5-based toolchains with binutils/etc from the same era. Arm's the complicated one as we diabled exceptions in the standard library. |
| 15:24:00 | speachy | ...I'm thinking I should also enable g++ too |
| 15:24:02 | buZz | oh yeah, totally, all my targets are armv7 :) |
| 15:24:28 | buZz | (atm Nokia N900, Motorola Droid 4 and Pinephone) |
| 15:26:24 | speachy | getting everything onto gcc 4.9 was quite an adventure |
| 15:46:41 | buZz | yeah there's a lot of stuff around that doesnt really seem willing to be ported easily to >4 |
| 16:00 |
| 16:55:07 | *** | No seen item changed, no save performed. |
| 17:00 |
| 17:02:21 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 17:09:45 | rb-bluebot | Build Server message: New build round started. Revision 4b8fe8acd1, 303 builds, 7 clients. |
| 17:11:25 | | Quit advcomp2019 (Ping timeout: 250 seconds) |
| 17:17:13 | amachronic | speachy: just curious, why pick gcc 8 if updating gcc? why not jump to 11 or 12? |
| 17:18:31 | speachy | splitting the difference with upstream, ie 4 major releases. |
| 17:19:01 | speachy | the most recent stuff (11 and 12 I think) require a C++11 environment. |
| 17:19:17 | amachronic | only on the host. |
| 17:19:24 | speachy | yeah |
| 17:20:17 | amachronic | which according to gcc's C++11 status is complete since gcc 4.8 |
| 17:20:23 | speachy | had to start somewhere. |
| 17:21:38 | amachronic | i just figure that updating compilers will expose the same few issues over and over |
| 17:21:51 | amachronic | re. aliasing, bad assumptions about volatile, w/e |
| 17:21:54 | speachy | things are in a lot better shape than when I dragged everything to 4.9 but we'll see. right off the gate with 8.5 X3 doesn't build cleanly. that's where I left it to get some outside work done |
| 17:24:30 | speachy | I _think_ our hosted targets should be okay with newer toolchains but we're stuck with older infrastructure (eg glibc, other system libs) and I don't want to have to patch those any more than necessary. |
| 17:25:03 | speachy | and ultimately the question is if we'll end up with slightly better optimized code or slightly more optimized bugs |
| 17:25:44 | | Quit lebellium (Quit: Leaving) |
| 17:27:43 | amachronic | compatibility between new gcc and old glibc and that could be a problem; i don't know much about it |
| 17:28:09 | q3k | it's pretty bad |
| 17:28:28 | speachy | I'm hopping that if anything shows up it'll be solved by forcing using -std=gnu99 or whatever instead of the newer stuff's gnu11 |
| 17:28:48 | q3k | not as bad as the other way around (new glibc old gcc), but still bad |
| 17:29:06 | speachy | it's not as critical for hosted targets as they're pure userspace |
| 17:29:16 | amachronic | we wouldn't have to compile glibc though, only link against it. |
| 17:29:46 | speachy | actually we have to build glibc −− that's the only way we get proper headers to link against. |
| 17:29:54 | speachy | build against, I mean |
| 17:30:05 | speachy | alsa, zlib, and a couple others too |
| 17:30:07 | amachronic | well, I know that :P |
| 17:30:33 | amachronic | but _surely_ glibc and gcc can't screw up a simple C ABI too badly? |
| 17:30:41 | q3k | :) |
| 17:30:57 | speachy | s/glibc and gcc/random soc vendors and integrators/ :) |
| 17:30:58 | q3k | hic sunt leones |
| 17:31:04 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 17:32:56 | rb-bluebot | Build Server message: Build round completed after 1391 seconds. |
| 17:32:57 | rb-bluebot | Build Server message: Revision 4b8fe8acd1 result: All green |
| 17:33:41 | speachy | the cross-compiler has special needs for glibc sources so it can bootstrap itself. :/ |
| 17:34:41 | amachronic | that tedious dance of building gcc+glibc+linux headers twice :( |
| 17:35:23 | speachy | and/or we could always see how well modern llvm handles things. :D |
| 17:35:36 | q3k | yeah i was gonna say, it might be worth investigating clang/llvm |
| 17:35:47 | q3k | although things aren't that great there either - but at least you get cross compilation for 'free' |
| 17:36:43 | rb-bluebot | Build Server message: New build round started. Revision 4f9e4ddb99, 303 builds, 7 clients. |
| 17:37:16 | speachy | that said I should see how much of a PITA it owuld be to enable C++ (& libstdc++) on this iteration. |
| 17:37:30 | q3k | bootstrapping llvm itself is trivial, it gets messy around clang, it gets even worse around clang cross-compilation/sysroots (mostly because clang has a lot of 'smart' gcc/linux runtime compatibility), it becomes a cognitohazard around compiler-rt/libcxx, and libc is its own mess |
| 17:37:53 | amachronic | last time I researched it, freestanding c++ is basically useless with gcc/libstdc++ |
| 17:38:28 | speachy | oh? I find that interesting given how much of the vendor microcontroller world is built around C++ these days |
| 17:39:20 | amachronic | if you're able to work out how to do it then there's no reason it _shouldn't_ work |
| 17:39:52 | amachronic | but allegedly freestanding libstdc++ lacks even basic facilities like <type_traits> |
| 17:39:52 | q3k | if you don't use the STL you just need a few shims for global constructors and new |
| 17:40:08 | speachy | I'm just thinking of (eg) some hypothetical future codec/library or random game (hola, __builtin) we want to integrate that utilizes C++. |
| 17:40:31 | q3k | that would need a full blown c++ stdlib |
| 17:40:58 | q3k | (ie. either listdc++ or libcxx) |
| 17:41:02 | speachy | hah! I'm picturing a scummvm port to rockbox now. |
| 17:41:22 | speachy | that would be _really_ cool.. |
| 17:42:24 | speachy | though even with sufficient-resolution screens it's going to be nigh-impossible to actually read any text or pixel-hunt objects.. |
| 17:43:55 | speachy | after I get the native mips 8.5 building cleanly (and hopefully generating a working jz4760/X3 binary) I'll see if I can get C++ turned on for the m68k toolchain. worst case I curl up in a ball in the corner while rocking and sucking my thumb. |
| 17:44:46 | | Quit advcomp2019 (Ping timeout: 260 seconds) |
| 17:45:01 | speachy | anyway, time to go afk for a while again. |
| 17:50:00 | CH23 | __builtin I missed your explanation, thank you! I'll give it a try. |
| 17:50:54 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 17:50:56 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 17:59:57 | rb-bluebot | Build Server message: Build round completed after 1394 seconds. |
| 17:59:59 | rb-bluebot | Build Server message: Revision 4f9e4ddb99 result: All green |
| 18:00 |
| 18:00:05 | | Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) |
| 18:01:18 | rb-bluebot | Build Server message: New build round started. Revision eaccdeeae2, 303 builds, 7 clients. |
| 18:02:52 | | Quit advcomp2019 (Ping timeout: 265 seconds) |
| 18:03:21 | | Quit advcomp2019_ (Ping timeout: 265 seconds) |
| 18:03:45 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 18:05:36 | | Quit advcomp2019__ (Ping timeout: 268 seconds) |
| 18:14:57 | | Quit advcomp2019 (Ping timeout: 265 seconds) |
| 18:24:37 | rb-bluebot | Build Server message: Build round completed after 1399 seconds. |
| 18:24:38 | rb-bluebot | Build Server message: Revision eaccdeeae2 result: All green |
| 18:27:25 | rb-bluebot | Build Server message: New build round started. Revision f8e968991d, 303 builds, 7 clients. |
| 18:33:36 | CH23 | so i just replaced "if (beep)" with "if (!beep)" on line 92 of piezo-6g.c, and removed lines 94 and 95. it seems the piezo still clicks as it should. what purpose do those extra lines serve? see: https://i.imgur.com/Ghd11dz.png |
| 18:36:45 | CH23 | it seems that's for the 'back' and 'forward' buttons or so. |
| 18:38:12 | amachronic | apparently nothing is using the beep=true case |
| 18:39:04 | amachronic | or force=true for that matter |
| 18:49:51 | rb-bluebot | Build Server message: Build round completed after 1347 seconds. |
| 18:49:53 | rb-bluebot | Build Server message: Revision f8e968991d result: All green |
| 18:55:08 | *** | Saving seen data "./dancer.seen" |
| 18:55:11 | | Join massiveH [0] (~massiveH@2600:4040:a993:4900:49a7:a7ac:d768:4f9d) |
| 18:59:31 | | Quit amachronic (Quit: amachronic) |
| 19:00 |
| 19:47:59 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 19:48:06 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 20:00 |
| 20:24:42 | CH23 | for anyone who's also modding their iPod to have a taptic engine, with the iPhone 7 plus taptic engine, I get a fairly silent but heavy vibration by setting the following: https://i.imgur.com/4ucPGzg.png in case the imgur link expires: "if (!beeping) { if (!beep) piezo_start(1000,1); } }" |
| 20:31:44 | CH23 | __builtin the one thing I don't get, you said the 'cycles' parameter is in 1/100th kHz, so 1000 should be 10kHz, yet it appears to be much much lower than say 50 |
| 20:45:59 | CH23 | oh i see. i had headphone keyclick off. |
| 20:46:09 | CH23 | on headphones it sounds about right |
| 20:55:12 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:02:51 | | Quit tomato (Quit: The Lounge - https://thelounge.chat) |
| 21:24:06 | | Quit CH23 (Ping timeout: 260 seconds) |
| 21:37:15 | | Join tomato [0] (~tomato@user/tomato) |
| 21:58:31 | | Quit hactar|ant (Quit: and it's always been the same / it's just a complicated game) |
| 22:00 |
| 22:09:02 | | Join hactar|ant [0] (~zem@c-24-21-103-100.hsd1.or.comcast.net) |
| 22:44:24 | | Quit massiveH (Read error: Connection reset by peer) |
| 22:46:49 | | Join massiveH [0] (~massiveH@2600:4040:a993:4900:49a7:a7ac:d768:4f9d) |
| 22:55:14 | *** | Saving seen data "./dancer.seen" |
| 22:55:37 | | Quit massiveH (Quit: Leaving) |
icon identifies that the person is a core developer (has commit access).