Live data from Hacker News

An appeal to Apple from Anukari

anukari.com

141–150 of 197 posts

Re: An appeal to Apple from Anukari

#141

This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is. Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but stil…

> Networking APIs that require the use of a 3rd party library because the native APIs don’t even handle the basics easily

This is nonsense. I've been a professional Mac and iOS developer for well over a decade, and even in the days of NSURLConnection, I've never needed a 3rd party networking library. Uploading, downloading, streaming, proxying, caching, cookies, auth challenges, certificate validation, mTLS, HTTP/3, etc. – it's all available out of the box.

Re: An appeal to Apple from Anukari

#142
post #29

Some folks may have seen my Show HN post for Anukari here: https://news.ycombinator.com/item?id=43873074 In that thread, the topic of macOS performance came up there. Basically Anukari works great for most people on Apple silicon, including base-model M1 hardware. I've done all my testing on a base M1 and it works wonderfully. The hardware is incredible. But to make it work, I had to implement an unholy abomination o…

Did you try this entitlement? https://developer.apple.com/documentation/bundleresources/en... wonder if com.apple.developer.sustained-execution also goes the other way around...

Thanks for the thought, unfortunately when running as a plugin Anukari is subject to whatever plist.txt the host application uses. I think that I did try that with the standalone binary at one point, but unfortunately I did not appear to take notes! That probably means I did not have success.

Re: An appeal to Apple from Anukari

#143
post #60

Earlier quoted context omitted.

This is "don't anthropomorphize the lawnmower" territory imo. I don't think Apple is actively hostile to 3P developers or tries to lock them in. I think they simply don't care - or lack the institutional capacity to care even if individual developers in the organization want to care. The Apple developer experience is an abject horror because they believe everyone who is capable of developing high value applications f…

I'd argue you can see the hostility if you compare shipping to Windows vs shipping to Apple. Microsoft doesn't care if you copy over your MSVC suite into a Wine environment to build your software for their platform. Even SignTool just works. It's not necessarily trivial to do, but that's simply because the MSVC suite is a horrible mess like everything else Microsoft. Apple explicitly disallows cross compilation in th…

Apple is mainly a hardware company it is saying you must buy our hardware if you want to make money out of our users.

That is not being developer hostile. Apple does many other things that don't help developers but forcing their hardware is just an entry cost.

Re: An appeal to Apple from Anukari

#145

1024 objects updating at 48khz seems possible on the CPU - depending how the code is written. 48M updates per second? It seems like a possible use for OpenMP to run a few loops in parallel across cores.

1. Anukari runs up to 16 entire copies of the physics model for polyphony, so 16 * 1024 * 48K (I should update the blog post)

2. Users can arbitrarily connect objects to one another, so each object has to read connections and do processing for N other entities

3. Using the full CPU requires synchronization across cores at each physics step, which is slow

4. Processing per object is relatively large, lots of transcendentals (approx OK) but also just a lot of features, every parameter can be modulated, needs to be NaN-proof, so on

5. Users want to run multiple copies of Anukari in parallel for multiple tracks, effects, etc

Another way to look at it is: 4 GHz / (16 voice * 1024 obj * 4 connections * 48,000 sample) = 1.3 cycles per thing

The GPU eats this workload alive, it's absolutely perfect for it. All 16 voice * 1024 obj can be done fully in parallel, with trivial synchronization at each step and user-managed L1 cache.

Re: An appeal to Apple from Anukari

#146

Earlier quoted context omitted.

The post opens with the following TL;DR:, snipped for brevity: > It would be great if someone can connect me with the right person inside Apple, or direct them to my feedback request FB17475838 as well as this devlog entry.

Feedbacks often go into a black hole unless either: 1. A bunch of people file effectively the same bug report (unlikely here) 2. An individual Apple employee champions the issue internally 3. Someone makes a fuss on Twitter/X and it starts to go viral Sounds like the OP is trying to get #2 to happen, which is probably his best bet.

Another trick is to schedule some Apple engineer time during WWDC, and plead your case.

Re: An appeal to Apple from Anukari

#147
post #95

I'm having trouble understanding what the problem is -- as in, what are the actual symptoms that users are seeing? How much latency can the app tolerate and how much are you seeing in practice? It would be helpful (to me at least) in thinking about potential solutions if that information were available up front. Perhaps there's something in this video that might help you? They made a lot of changes to scheduling and…

It's a real-time audio app, so if it falls behind real time, no audio. You get cracks, pops, and the whole thing becomes unusable. If the user is doing audio at 48 kHz, the required latency is 1/48,000 seconds per sample, or realistically somewhat less than that to account for variance and overhead.

Re: An appeal to Apple from Anukari

#148
post #37

This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is. Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but stil…

I don't disagree with you, but there simply isn't an alternative for pro audio developers. You go where the users are and the majority of the market (by revenue) are Mac users. Now a lot of people may reply to this that Windows isn't that bad with ASIO (third party driver framework) or modern APIs like WASAPI (which is still lacking), or how pipewire is changing things on Linux so you don't need jack anymore (but god…

> You go where the users are and the majority of the market (by revenue) are Mac users.

You go to a different market.

Re: An appeal to Apple from Anukari

#149
post #122

Earlier quoted context omitted.

How is WASAPI lacking? I thought the abundance of FL Studio beat producers proved that for audio work, today, Windows is completely fine.

Basically every software (except Logic) is available on Windows but users still buy Macs. Even among those users, people usually fallback to ASIO instead of directsound or wasapi backends. WASAPI requires exclusive mode to be useable for pro applications, or else your latency will suffer and they may be doing some resampling behind the scenes.

Exclusive mode is a feature, not a bug. If the user needs the bits coming out of the user's DAW to reach the speakers as pristine as possible, then the user probably doesn't want these bits mixed with any other application. If the user needs to switch between the DAW and a Youtube tutorial, then there's probably no need for exclusive mode.

Latency is a valid concern, but is it really bad? PCs are fast now.

Re: An appeal to Apple from Anukari

#150
post #16

Earlier quoted context omitted.

[flagged]

It’s technical to over half of programmers who don’t need to know these types of details about hw/sw interactions.

It's about 'very technical'. If you can explain the problem in one basic sentence it's not very
Post reply on HN