Hacker News: mmfl

New comment by mmfl in "Dutch 'idealist' bank ASN blocks non-Google Android, including GrapheneOS"

mmfl — Fri, 06 Nov 2026 20:43:00 +0000

In the UK, you do require an FCA registration to access Open Banking APIs, but I built an open-source client (in production) that handles a lot of the API integration work: https://github.com/finlabsuk/open-banking-connector

New comment by mmfl in "Apple’s Latest Macs Have a Serious Audio Glitching Bug"

mmfl — Tue, 19 Feb 2019 22:42:36 +0000

Apple definitely have a major issue here - I upgraded from the 2016 MBP to 2018 MBP (max'ed out specs in both cases apart from SSD size) and audio dropouts etc when using Mainstage for live performance with virtual instruments (sound sources) have increased greatly. I'm a (piano) keyboard player and low buffer sizes and latency (<5 ms) are essential for turning my MBP into a responsive and expressive musical instrument. Unfortunately such settings reveal harshly the huge degradation in audio performance that has occurred and I am not any longer be prepared to use my MBP in a live performance situation. (Even if a larger buffer size reduces the dropouts I don't want to play an unresponsive instrument.) It's just ridiculous to see my powerful MBP running at very low percentage CPU utilisation and performing so badly.

Interestingly yes I experience issues with my USB2 interface (RME Babyface Pro) but also when using the MBP's headphone jack or the interface via USB ports on my LG Ultrafine 5K monitor (which has its own USB chip). I do wonder if the root issue may be along the lines of this poster's theory about poorly written Apple driver code (since Apple probably wrote new driver code to accommodate T2): https://www.gearslutz.com/board/showpost.php?p=13492144&post...

New comment by mmfl in "Swift: When Unused Code Is a Bug"

mmfl — Mon, 06 Aug 2018 18:33:58 +0000

If the concept is that protocol requirements represent the "customisation points" of a protocol, shouldn't this apply equally to conforming classes and subclasses with inherited conformance? So I would be in favour of fixing this. Conversely, perhaps protocol extension methods etc not declared as protocol requirements could e.g. elicit a compiler warning when "overridden" by conforming classes/subclasses with inherited conformance (since they are not intended as customisation points)? I think these changes would aid reasoning about protocols and reduce bugs.