Status on m1/m2 update?
Comments
-
NI was FULLY aware of what AS transition meant- NI said…
Well, they understimated it for sure and roadmaps were too optimistic (not only for AS but M+)
BTW this topic will be closed too probably…
0 -
Yes, NI probably expected, Apple is not able to keep its promise x86 will run on Rosetta 2 flawlessly...
Apple should be blamed, not NI. NI has few more years to complete AS transition, but hopefully it will be in 2-3 months. For all or most NI products....
I am pretty sure, NI works on it as much as possible. Probably wanted to do also testing of M2... It would be even sound to wait till M2 Pro/Max, if possible... (M2 Pro/Max are on different node than M2, so generally different CPUs... It would be helpfull if SW may be tested even on them before release....)
And AS transition has to be completed (fully/almost fully) till release of Komplete 14, which might be expected this year... So, without testing on M2 Pro/Max.....
0 -
I hate Apple and their fans with a reasonable passion (?), but here people do the same with NI: tiptoeing around as if they were benefactors and we had to thank for the generous gift of their attention and wisdom. This is a user forum, not a lordship.
Yes, it's an optimizing compiler, it's complicated, yes. But it doesn't take a leap of logic to realize, after all these years, that there are serious issues with NI's codebase. It's quite evident that many parts of it have been written a very long time ago, some by people who have left the company, in architecturally inconvenient manners that make them very hard to maintain, let alone refactor, so there are all kinds of fixes, from small to large, that require extensive rewrites, and in the case of Reaktor that's hardly justified by its sales, and less justified each year, as the company struggles to make ends meet.
3 -
That is all true. My comments are to be taken within that context :).
The context is an old creaky codebase, with a development team barely big enough for basic maintenance and minor updates some of whom (we assume?) were not involved in the original development process.
In that context it is unreasonable to expect something like providing native M1 support to be a seamless timely process.
Reaktor is very old and comes from a different technological era. It's amazing that it is still amongst the best at what it does. In some ways unique. And that it is still viable to the extent that NI are willing to attempt to bring it to a new platform is amazing.
So yes, in that context I feel that folk should stop attacking NI and be patient. Kubrak is right that if it isn't working seamlessly with Rosetta 2, then that is an Apple problem. So go and pester Apple about that!
There are various things we could/should be legitimately angry and frustrated at NI about, but this is not one of them
1 -
Holding NI accountable for the slow development of AS native support is totally valid.
The biggest root cause of this slowness is the "creaky old codebase" is 100% the fault of decision makers within NI.
Had NI made better decisions about modernizing this codebase years ago, then so many other things may have happened in a more timely manner.
Apple is not to blame for NI poor decision making. NI owns that 100%.
1 -
Apple's move has nothing to do with innovation, it's just a chapter in their constant effort to lock their fandom in a parallel universe. If Microsoft support is a bunch of underpaid, overworked guys somewhere in the world desperately answering questions they know nothing about, Apple support is a proud team of guys in shirts politely indicating that there are no issues, because Apple doesn't make mistakes.
This doesn't change the fact that x86 is also an old creaky architecture, or more precisely an old creaky instruction set implemented with great effort by some amazing technology that it doesn't deserve. ARM is getting old already, and its mainstream implementations are incomplete and underperformant, but that's besides the point: x86 can't be extended forever, something will have to replace it and I'm pretty sure I'll live to see it. Apple is fast forwarding the situation to have the advantage of coming first, by semirandomly deprecating whatever they please. So we're all at an impasse, where things that were pretty standard ten years ago are now atomized into a number of incompatible alternatives. This means it's more important than ever to have your dependencies completely abstracted from your application. This was a basic tenet twenty years ago as much as now, the fact that it's become crucial is incidental.
NI's approach in the last years reminds me of these "modern" conservatives according to which all problems can be solved cutting corners, "streamlining" here and there, and putting a nice, comforting sans serif facade over the whole thing, while everything essential keeps rotting. Of course there are worse elephants out there, some of which are also struggling with AS. But take, for example, Cubase and DP: they come from the late Pleistocene, and they're AS native. Would you bet that Reaktor's codebase is larger than Cubase's?
3 -
so... Apple suck, NI suck, x86 sucks, and ARM mostly sucks, cubase and DP both suck, and Reaktor sucks... man stuff really does suck 😁😜
I totally get it - a lot of stuff could be so much better than it is.
I still love Reaktor though, in spite of all the shortcomings!
2 -
😂
Well, "sucks" is too broad a brush. More like NI is run by speculators, x86 is very old, ARM is not so old, Cubase and DP are old but good, and it's because I do like Reaktor that I hate to see it semi-abandoned.
Apple does suck though 😊
2 -
We will see, but I do not expect x86 to disapear any time soon. It has one, two, three decades left...
Reaktor has old codebase, because what would pay for total rewritting.... I also have 30 year old codebase in many of my programs. It works, customers are satisfied and do not want me to change it. Not speaking about that they would pay for it.... They simply do not want the change, because it works, and rewritting would mean, there could be problems. And they do not want any problems...
0 -
Disruption is happening but keep believing nokia lumia will rule the smartphone world…
You are so cute…
0 -
The same with Apple... Nobody is too big to fail. Today, Intel has problems, tomorrow it may be Apple....
0 -
Lol, this thread is getting way out of hand. So much despise and negativity being thrown around without really much substance. I can’t imagine a more ignorant comment than “apple sucks”. Way to argue for something. If apple did suck why is it being used by the best of the best? Year after year? And not only in music production? There must be a reason…. Hmmm I wonder what it could be.. ah well, I’d have to ponder a whole week…
2 -
It has nice logo and gives "status". And I would not say Apple is used by the best of the best. For example I would not touch Apple product even by a broomstick. So, there is at least one the best who does not use Apple.
1 -
Try to live in the present, mate…
Between new Ryzen promises and the downfall of Apple there are lots of professionals doing music nowadays with lot of native AS software avaliable TODAY.
Let’s hope NI can keep their promises of future releases and keep the brand healthy (because even if Apple is just branding, NI needs it)
2 -
I can't talk for anyone else, but I'm having a great week. No negativity. Just a simple recognition that Apple has a long history of horrible business practice. Even their technically good choices have more to do with that than "innovation" or anything. This is one of those cases: it's probably about time to move on from x86 (and OpenGL) to fresher lands, but they're doing it in a way that deliberately breaks the market, evading any kind of industry consensus before it can even start. I can see the advantages their products have for many people's workflow, but Apple's stuff is great while it works. When it doesn't, it's not even that you're on your own: most likely there's nothing you can do about it.
(I even linked a clear example of that: screen drawing has been broken since 2018, and everyone has had to roll their own rect invalidation layer because, according to Apple, "the new behavior should be considered the correct behavior, and getRectsBeingDrawn:count: can no longer be relied upon", so "developers who need drawing optimization" have to "roll their own system".)
0
Categories
- All Categories
- 18 Welcome
- 949 Hangout
- 56 NI News
- 471 Tech Talks
- 2.5K Native Access
- 11.1K Komplete
- 1.3K Komplete General
- 3K Komplete Kontrol
- 3.9K Kontakt
- 842 Reaktor
- 298 Battery 4
- 611 Guitar Rig & FX
- 325 Massive X & Synths
- 761 Other Software & Hardware
- 4.1K Maschine
- 4.8K Traktor
- 4.8K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators