Live data from Hacker News

An appeal to Apple from Anukari

anukari.com

171–180 of 197 posts

Re: An appeal to Apple from Anukari

#171

Earlier quoted context omitted.

Exactly what are they suppose to do if not create their own frameworks to bear leverage their own hardware? Do you want them to use cross platform frameworks that are not optimized for their system?

My problems start long before the special APIs come into play. When we supported Mac, I just wrapped the APIs like you do for any other system. The problem is I don't use Mac, so building software for Macs is inherently troublesome. I can build and test for Windows just fine from Linux and OpenBSD. I can't for Mac. Now you might say this is problematic, Apple doesn't want third-party developers locking their platform…

The way I see it, they mainly just aren’t interested in devs treating macOS as just another lowest-common-denominator target, which makes some amount of sense. Such software is likely to not be as nice to use as something purpose-built for the OS, particularly when considering that the dev probably never even tested the software in question under macOS, greatly hampering their ability to find and eliminate bugs.

Re: An appeal to Apple from Anukari

#172

Earlier quoted context omitted.

My problems start long before the special APIs come into play. When we supported Mac, I just wrapped the APIs like you do for any other system. The problem is I don't use Mac, so building software for Macs is inherently troublesome. I can build and test for Windows just fine from Linux and OpenBSD. I can't for Mac. Now you might say this is problematic, Apple doesn't want third-party developers locking their platform…

Why would I want to use software that you never tested on the target machine?

Because it's not 1982 anymore?

Re: An appeal to Apple from Anukari

#173
post #59

Earlier quoted context omitted.

It's surely not perfect, and so much is quite horrible, but at least try to keep the facts in check. AppKit and auto layout are still working fine, they aren't going anywhere any time soon, there is no need to rewrite all the UI code. Core Data threading? Well, it has got its pitfalls, but those are known, and anyway, nothing is forcing you to use it. Xcode is so slim these days, it a ~3 GB download, it doesn't take…

Let's also keep in mind that the Linux desktop commits most of these offenses, but worse. Core Data threading? Does Linux even attempt something like Core Data? How well is that going? Swift? I remember when Linux diehards invented Vala. The Swift of Linux, but with none of the adoption. As for UI code, Linux is finally starting to get a little more stable there. GTK 2 to 3 was a disaster; Qt wasn't fun between major…

And the UI situation still has issues. If you want flexibility in language choice, GTK is the only modern-ish framework option there is. The rest are tied to 1-2 languages, bad at accessibility, look archaic, etc.

Re: An appeal to Apple from Anukari

#174

Earlier quoted context omitted.

Why would I want to use software that you never tested on the target machine?

Because it's not 1982 anymore?

I didn’t buy a Mac to use your lowest common denominator untested, unoptimized application that doesn’t take advantage of my hardware to its fullest.

Re: An appeal to Apple from Anukari

#175
post #137

Earlier quoted context omitted.

But they had to be pushed in that direction. IT actually affected their work. In this case, the users of these tools seem perfectly ok with them and aren't going to just explore something as disruptive as an entirely different OS just for kicks.

Not sure why you started off with "but" when we are in agreement and/or you're not disputing my point - that Windows is viable but the Mac-using audio professional aren't (yet) sufficiently motivated to seriously evaluate Windows as a migration target. > In this case, the users of these tools seem perfectly ok with them That wasn't my takeaway from the article. The plugin is outright broken on the latest hardware, ev…

That comment was left in haste, sorry. To clarify, I meant that in the case of FCP and movie editing software, they were almost forced to switch.

The FCP upgrade didn’t just break the main app, but the plugin ecosystem was wiped out too. (From what I read, I’m not a movie pro). And that was disruption forced upon the users.

So in that scenario, they didn’t have much of a choice.

But in this scenario, the audio apps work well and it’s just the developers complaining.

And even though I’m a developer, I would say as long as the users are happy then I can see why there is less concern about dev happiness

Re: An appeal to Apple from Anukari

#176
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.

I find it hard to believe that users would notice latency under 1ms. Probably not even under 5ms.

Have you tried buffering for 5ms? Was result bad? 1 ms?

Re: An appeal to Apple from Anukari

#177

Earlier quoted context omitted.

Because it's not 1982 anymore?

I didn’t buy a Mac to use your lowest common denominator untested, unoptimized application that doesn’t take advantage of my hardware to its fullest.

You're using HN right now. The web is one of many types of write-once-run-anywhere software you are critically reliant on in your day-to-day life.

Re: An appeal to Apple from Anukari

#178
post #168

Earlier quoted context omitted.

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.

afaik it's not possible to configure buffer size and sample rate from within a user application without exclusive mode, which actually does matter for the non-exclusive use case. iirc it was even worse where applications' streams would be resampled transparently and buffered, which is absolutely not what you want. I don't use windows for audio anymore so I can't comment on this in win11, but it used to be that WASAPI…

I see. Thank you!

Re: An appeal to Apple from Anukari

#179
post #154

Earlier quoted context omitted.

“Linux” isn’t a person or a company. Different people contribute to it with different goals. > 90%+ of work on Linux comes from corporate sponsorship And approximately 0% of these corporate contributors care about the “Linux desktop” experience. Unlike Apple their goal is not to build a consumer-targeted OS. Linux on the desktop is very, very niche, and even among the people who do use it, a lot of them will spend al…

If you haven't used linux desktop for a while, even a year ago, try again. Use a bleeding edge distro like the latest Ubuntu or Fedora ideally running Wayland and you will be surprised how smooth and feature-full it has become, with gobs of high quality apps available with no finicky compile instructions or crazy installation steps needed to follow. Whatever rough edges you may encounter will keep being sanded down a…

I’m pretty sure I read your exact comment way back in 2006. ;P

Re: An appeal to Apple from Anukari

#180
post #40

Earlier quoted context omitted.

On the old Mac OS, and early OS X day, the documentation was great, I dunno what happened to the documentation team. Swift on the server is for Apple ecosystem developers, to share code, just like all those reasons to apparently use JavaScript on the server instead of something saner.

I remember it being pretty good circa 2012 or so. The API docs generally told me what I needed to know and there were some helpful in-depth technical notes. Did they lose something in the redesign or Swift migration?

It was starting to go downhill even then. They let go a significant number of documentation people for whatever reason.
Post reply on HN