Hacker News Reader

Comment by tgv | Hacker News Reader

Anything that uses a lot of CPU or pushes much data around.

I use Logic to make music. Many of te plugins run on one core, and can take up 100% of it. If performance via emulation is around 50%, that means a lot of drop-outs in the sound, and basically an unworkable situation. Been there, seen it, don't want to go throug it again.

The bigger plugin makers will probably port their products, but it's going to cost the user; the smaller ones may simply give up macOS completely.

View on HN

> The bigger plugin makers will probably port their products, but it's going to cost the user; the smaller ones may simply give up macOS completely.

The writing has been on the wall though - Catalina with all its dropped frameworks & notarization already pushed some developers to give up on the Mac (or tell their customers to just stay on Mojave). Loads of Waves users were unhappy having to upgrade to v11 for Catalina support, and won't be happy paying yet again for Mac ARM support.

Come join us on the dark side. Plenty of us music people already switched from Mac to Windows. Even Linux audio seems to have come a long way, with Bitwig, Reaper, Renoise all supporting Linux now, and even plugin devs like u-he.

The fact that Ableton doesn't work on Linux has been the only thing keeping me with Mac hardware. I've been so resistant to Windows. But my resolve weakens with the continual erosion of the Apple ecosystem.

You assume it is a lot of work to port the plugins. Most likely it only needs a compile for a new architecture. And they will probably have months to check that checkbox in Xcode. It is not like they have to switch to a new programming language.

I think almost no audio plugins (other than those ported to mac from iOS) use a blessed apple toolchain to the extend that they could just flip a switch in Xcode. And I wouldn't be surprised if some of them have very processor specific optimizations in their code.

Audio plugins are one of the few software domains where you'll still often find handcoded assembly in performance critical sections. I wouldn't be surprised if a lot of third party vendors don't make the transition.

On the other hand DAWs are more complete in the box now than ever so this is probably less of an obstacle to switching from the users' point of view than it would have been 5 years ago.

Video too. I paid attention to the commits to x265 for a while, and quite a lot of them were like this:

  asm: AVX2 version of saoCuStatsE3, (136881c -> 45126c)

Just counting lines, there's more assembly than C++:

  ~/x265> find source -name '*.cpp' | xargs cat | wc -l
     95358
  ~/x265> find source -name '*.asm' | xargs cat | wc -l
    168690

That said, x265 does compile for ARM, and has ARM assembly as well, though much less of it, as of when I last updated my copy (March 2017):

  ~/x265> find source/common/arm -name '*.S' | xargs cat | wc -l
     11014

Looks like, in today's codebase, the line counts for .cpp, .asm, .S are 111188, 203423, 12217 respectively—so proportionally much the same.

DSP etc. are the kind of things likely optimized for architectures, using intrinsics for vectorization and whatnot.

Yes, I do. And I remember the previous transitions: they were far from smooth.

I've been involved in more than one platform transition, and there are always problems. Plugins are complex.

Reply on news.ycombinator.com