Comments URL: https://news.ycombinator.com/item?id=47857964

Points: 53

# Comments: 7

I've wanted to automate this since 2019 (after first hearing about it in the popular podcast - Accidental Tech Podcast). I figured I'd write it in Kotlin (being my language of choice) first, but JVM audio processing wasn't there (or more fairly I just needed to put in way more work than I realized).

With AI ofc, I took another shot at it recently and finally built it in Rust.

"PodSync" takes a master track and individual participant tracks, finds the time offset for each using VAD (voice activity detection), MFCC fingerprinting, and cross-correlation, then outputs aligned WAV files. Drop them into your DAW at 0:00 and they line up!

There's an accompanying blog post with a visual on the mechanics: https://kau.sh/blog/podsync/

Would love to hear feedback!

Comments URL: https://news.ycombinator.com/item?id=47459076

Points: 2

# Comments: 0

The reason MCPs are so powerful are less a technological advantage over other tools and more how ridiculously easy they are to install and use.

Also given it's an official standard now (AAIF), it's easy for sharing across differently agent harnesses and tools.

Those are the two main reasons imho, they are still a mainstay.

If you'll allow some shameless plugs, my co-host and I talk about it in our podcast:

https://fragmentedpodcast.com/episodes/302/

Comments URL: https://news.ycombinator.com/item?id=46720959

Points: 1

# Comments: 0

I was trying to test the theory if it's even possible to release something production grade with vibe coding. Wrote about the experience here https://kau.sh/blog/container-traffic-control/

https://addons.mozilla.org/en-US/firefox/addon/ctc/

When you start to use Containers (feature the Author of the article talks about), you'll start to want a little more control in how the containers open especially for sites that you allow on more than one container

Source came be found here: https://github.com/kaushikgopal/ff-container-traffic-control

Comments URL: https://news.ycombinator.com/item?id=46430247

Points: 5

# Comments: 0

tldr: use spaces around em dashes

Comments URL: https://news.ycombinator.com/item?id=46394931

Points: 2

# Comments: 1

some fonts individually have beautiful glyps or characters but when you preview them with blocks and blocks of code, there's a quirkiness that throws of that symmetry.

I'll give a few examples:

- Mono Lisa font https://www.monolisa.dev/ (truly gorgeous font)

- Recursive https://www.recursive.design/ (particularly note the casual axis)

I bring this up because Google Sans Code, is super quirky; preview a few characters individually and they look good; put it all together in real code, and it's just not as smooth visually.

i don't have your skills of actually customizing or changing glyphs in fonts directly but i've customized and used scripts to fix glyph characters available as open type features. I've done this for fonts like:

- [Iosevka](https://kau.sh/blog/build-iosevka-font-mac-os/)

- [IBM Plex Mono](https://kau.sh/blog/freeze-alt-char-open-type-font/)

- [Jetbrains Mono](https://github.com/kaushikgopal/JetBrainsMono-KG) (yes, plenty of customization there)

- [Recursive](https://github.com/kaushikgopal/recursive-code-config)

it really is a sickness. a terrible sickness, if you care deeply about fonts. I know you don't care specifically about recommendations, but inevitably i've found myself gravitating to these fonts:

1. Berkeley Mono (paid)

2. SF Mono (walled)

3. Recursive (truly open and legible)

4. Commit Mono

I love the above fonts, but there's a few characters or quirks that drive me bananas on certain days, so inevitably find myself switching between them.

I wrote about this but I'm certain that eventually commands, MCPs etc will fade out when skills is understood and picked up by everyone

https://kau.sh/blog/claude-skills/

but sigh. Jetbrains really just has no focus.

Fleet came at a time when intellij felt extremely bloated. iirc they had painted themselves into a corner where it was easier to rip the band aid and start anew.

Fleet was supposed to be that promised editor which was snappy and had the power of intellisense + all things we liked about Intellij editors ... but without the terrible glacial bloat. but in a stroke of bad luck and typical lack of focus from Jetbrains, Fleet just didn't get good enough quickly.

I say lack of focus because (like their multiple attempts at AI) Jetbrains also had a lite mode in the start but that didn't work great. then came Fleet. But it was not getting better quickly enough and they changed course to make Fleet their main cross platform editor ... but even that didn't take.

I really am worried for Jetbrains and intellij. In a world where even VScode is having its lunch eaten by Cursor, Jetbrains is quickly getting pushed out of the list of contenders. they've squandered away a lead they once had in a certain niche for code editors.

I personally only pull up Intellij these days when there's some platform specific tool that's built in (like the emulator in Android Studio) or certain Android specific profiling tools, or the debugger.

Otherwise I rarely find myself using Intellij. My usage has dropped precipitously.

My reasoning for settling on Rust:

If I wanted something more general-purpose and ergonomic, I'd stick with something like Kotlin, which has wider ecosystem support. Go could fit here too, but I've heard from more experienced folks that Go's simplicity can get limiting as codebases grow (and requires 100s of developers to be disciplined). Not impossible, just not as conducive.

But since I specifically wanted a performant systems language, I figured I'd go to the other extreme. So my choice was Rust or Zig. I eventually chose Rust (as complicated as Rust can seem) the borrow checker is pretty elegant once it clicks and provides the necessary safety net for a language I intentionally am choosing for more control.

(here's my article on learning Rust if folks are interested: https://kau.sh/blog/learn-rust-ai-atrophy/) - different angle from the linked article.

1 - compromised hardware over better software is a trade-off you're willing to make and 2 - you believe that the Framework software experience is better than macOS

i can concede 2 (if true, I've not used a Framework laptop) but I don't understand point 1. packing a powerbank for example just feels ancient if you've used the arm chip macs. then again, I'm now pushing my trade-off

In fact there are some things about the syntax that are actually nice like range syntax, Unit type being (), match expressions, super explicit types, how mutability is represented etc.

I'd argue it's the most similar system level language to Kotlin I've encountered. I encourage you to power through that initial discomfort because in the process it does unlock a level of performance other languages dream of.

Comments URL: https://news.ycombinator.com/item?id=45980779

Points: 5

# Comments: 0