5 ms·

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

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.

kall 6y ago
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.
cageface 6y ago
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.
- waterhouse 6y 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.
jfkebwjsbx 6y ago
DSP etc. are the kind of things likely optimized for architectures, using intrinsics for vectorization and whatnot.
tgv 6y ago
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.

kall 6y ago

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.

cageface 6y ago

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.

waterhouse 6y 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.

jfkebwjsbx 6y ago

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

tgv 6y ago

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.