What's the general status of Reaktor?

Matt_NI

https://community.native-instruments.com/discussion/comment/8805#Comment_8805

I replied, just in case you two missed it 😅

Kubrak

It is pretty hard task to port Reaktor to AS. It may mean to write/rewrite substantial part of Reaktor. But it also depends what code Reaktor creates. It may be C/C++ that is compiled to target maschine code, or it may create x86 source code, that is translated to x86 maschine code by internal compiler. Or....

Because Reaktor used to support two different CPUs in past, I guess (hope) Reaktor generates high level language source code, that is further translated to target maschine code by general purpose compiler... If it is like that, NI needs to get compiler to AS and to optimize/recompile libraries for AS. And lots and lots of testing, optimizing and so on.

Even this simplest case is a lot of work. And it may work differently making porting to AS harder and harder....

Mutis

https://www.native-instruments.com/en/career-center

Maybe this could bring some perspective or opportunity ;)

EvilDragon

So, the SIMD parts of Reaktor (basically, Primary modules) are not really a big problem to port. There are libraries like xsimd or SIMDe that make it pretty easy to have SIMD intrinsics ported to whichever architecture.

As colB said, Core compiler is the main problem, and it depends on one person only. Yes, it needs a pretty substantial rewrite I'm pretty sure. No, LLVM is probably not the solution.

Trevor Meier

Reading the tea leaves, potentially the issue is that the core developer/founder who was the driving force behind Reaktor is no longer active on a daily basis at NI and has moved on to other projects. So until a replacement for his genius can be found… Reaktor may be left behind. Which is too bad really. It’s such a powerhouse

nanotable

https://community.native-instruments.com/discussion/comment/8923#Comment_8923

I guess the question is, is this person still at NI, and are they working on porting all that stuff?

It should be noted, however, that NI publicly committed to port their existing product portfolio, which obviously includes Reaktor. So while I’m hopeful that it will happen eventually, I’ll believe it when I see it. I guess the problem isn’t only the porting itself, which seems to be a herculean task in its own right, but making sure that it’s fully backwards compatible as well — a new Reaktor version without the UL wouldn’t make much sense and would be a death blow to the platform, imo. I sure wish NI would keep us updated on how it’s going on a regular basis.

olafmol

I believe most (all) original engineers have left the building. Some of them were freelancing for NI too. So I guess current engineering efforts are challenging as it's always very hard to inherit other people's code and improve this, assuming the code bases was started from small projects with limited documentation and test-frameworks.

nanotable

I'm going out on a limb and assume ED was talking about Vadim Zavalishin, who appears to be working for NI still https://de.linkedin.com/in/vadim-zavalishin-451bb812b But I'm not sure, and more information would be greatly appreciated.

Kubrak

It depends... If the code is well written, program has good structure, it may take some time to get in, but not that hard work....

Also, it is often possible to consult/ask previous programmer. Mainly if it was one/few man project. Programs are like babies... And programmers like parents.... One does not loose the attachement to his work even if working on different project in different company....

Murat Kayi

I would like to chime in with just a personal remark that I would appreciate a bit of a roadmap for Reaktor here in the forum. Nothing detailed - just a general heads up

Trevor Meier

Stephan Schmitt is the NI co-founder and original designer of Reaktor. He’s moved on to another project - although his new company did develop Kontour as a contractor to NI.

Kubrak

He left NI 10 years ago, or so.... Lots of time for NI to adapt. And as Reaktor is his child I do not believe he wouldn't want to help to some extent (if needed) to live it as long as possible.....

EvilDragon

Yeah I meant Vadim, and he's still with NI. There's a few other long-standing developers still with NI, like Georg Haupt for example.

Jon Watte

https://community.native-instruments.com/discussion/comment/8871#Comment_8871

This is a bit off-topic :-) But the internal mode of thinking for LLVM is "static single assignment," which is fundamentally a data flow concept. Thus, data flow actually translates very easily to LLVM-speak, and the reason there's so much talk about control flow, is that that's what needs a little more effort to translate! (See also: "phi operator".)

Agreed that the name "LLVM" is, ..., "mainly of historical significance."

Regarding "who is still at NI," I noted with some dismay that NI now has a main owner that's a private equity firm. What private equity firm generally are very good at, is mining out all the market value that exists in a given set of products, while investing very little in costly and/or risky R&D. What we could fear for the future if these owners follow the general trend would be lots of marketing, lots of re-skinning, and not much innovation.

Hence ... some concern about the future of Reaktor. Especially given that the list was updated on March 14, 2022, and still doesn't mention Reaktor at all. (I tried to post a link, but I get a "site security check" red box. It's the page you get when you google "native instruments Apple-Silicon-M1-Compatibility-News")

A message on the page saying "Reaktor will eventually be supported" would be a reasonable expectaction, but given that that message is not there, I think the only reasonable conclusion is that Native Instruments has not committed to supporting Reaktor on M1 silicon. It's been 18 months since first release, and longer for developers who have been on Apple insider seeding programs.

"it's not officially supported" and "not coming very soon" as posted by @Matt_NI are also not sending messages of particular reassurance, so the right choice here is likely to wean myself off of the Reaktor plugins. (And/or develop my own competitor tool and take over the market. Hah! :-D)

colB

https://community.native-instruments.com/discussion/comment/9794#Comment_9794

This is a bit off-topic :-) But the internal mode of thinking for LLVM is "static single assignment," which is fundamentally a data flow concept. Thus, data flow actually translates very easily to LLVM-speak, and the reason there's so much talk about control flow, is that that's what needs a little more effort to translate!

From the little I've read, I got that LLVM uses a Data Flow based implementation to analysing/model Control Flow code. It doesn't necessarily follow that this means it is automatically good at analysing Dataflow code though. An analysis engine that is designed/evolved to analyse control flow will be good at analysing control flow.

If the logic was sound that analysing some particular paradigm is easy using that paradigm, then LLVM would use control flow to analyse control flow - obviously not the case

I'll ask again for examples of LLVM being used as part of the compiler toolchain for Dataflow languages.

As far as the ownership of NI vs future of Reaktor, iirc concerns have been raised before, but generally the response is that development continues, and that it is against forum rules to stir up negative discussion about NI and about Reaktor. There have been warnings handed out for this in the past ;)

fwiw, normally, I would suggest if you're going to wean yourself off something it should be Apple ;). But in this particular case, I grudgingly think they've done us all a favour long term. Hopefully we'll see PC manufacturers moving over to high end ARM based platforms too. I just wish Apple could have found a better way to manage the transition.