Best Of

I know, but what else does it really need. Core has almost everything you need to design nearly everything.

Core has some massive holes in its feature set. Some of these features have been requested since it's introduction 20 years ago.

I was an electronics engineer and a musician for 50 years. I know circuitry like the back of my hand and know how to string things in core as it's very much like hardware circuits including DSP stuff. Reaktor has just about covered all of the basic building blocks we've used in electronics to make all kinds of things.

Any similarity to hardware circuits is entirely superficial. Reaktor is a programming environment with two languages. Any competent programmer would be able to give you a long list of stuff that is missing that would improve it

I honestly can't conceive what exotic alogythms there really are that would be useful.

Because you're not a programmer, and you havn't been working on Reaktor projects that push the platfom to the extent that you miss the lacking features.

What is it that you guys want that's so important to pester NI about. Plug in Latency reporting, fft stuff. Let's hear it…

Ok, I'll bite :). This is just my incomplete personal list. Features that I have needed for various projects that meant they were shelved, binned, non-started, or not as good as they would have been.

Core iteration

Massive hole in the core feature set. piping an iterator in from primary is a cpu hog, makes for ugly code, and doesn't work well for audio rate code. Iteration (or some equivalent, e.g. recursion) is a fundamental building block of all programming languages. Core is hobbled without it, particularly as projects grow. Large unrolled loops really become problematic as they can cause havoc with the caching processes on modern cpus. Very bad!

Table framework write access

For a modern audio environment, the flexible manipulation of digital audio is a basic requirement. Reading and recording of audio to and from memory.

Reaktors Table Framework was intended to provide Core with a more flexible set of tools for this purpose. But it was incomplete on release, only allowing the reading of files. So we can build amazing sample players, granular players, beat boxes etc. BUT, there is no way to record audio flexibly. We can use arrays, but they are limited to a few seconds only, and have no external file access.
If this initially promised feature had been added, you could make a freaking DAW in Reaktor (no vst hosting obviously, but still).
For me the big issue was the class of Eurorack modules like Morphagene. Real time granulation machines. There are a whole bunch of them with different feature sets. They are incredibly powerful and inspiring to use. It is not possible to build anything like this in Reaktor. Just no can do!

Text Processing

There is no option for user text input! Just crazy for any programming language.
e.g. you build a sequencer, with multiple tracks and a song mode with parts... Now you need to be able to give the users the option to name individual patterns like DrumsChorus, DrumsVerse, DrubsBreak1, DrumsBreak2, BassIntro... etc, etc... just not possible. A terrible omission for software intended for applications development.
I have used workarounds for this where you get an onscreen keyboard and click to type, but its clunky and nasty to maintain and even worse to use.

Loading of raw text files to tables would be huge too. iirc, I had to write a C app to convert my text to a comma separated list of ascii codes so I could then import it into a table, to then display it as ascii text. too clunky.

Flexible scalable multi-font displays for control numerics, so we don't have to use external software to build custom knob numerics. Thats just embarrassing in software where knobs are the most common interface component.

Modifier keys

When creating powerful mouse driven GUIs, two buttons is a major limitation. Having modifier key status would greatly improve things. Instead of just Left and right mouse buttons (can't use centre button as its not universally available), you would have each of those with CTRL, SHIFT and ALT... suddenly way more is achievable in a mouse driven GUI.

Code re-use mechanism(s)

In core, there is no code reuse at all. No functions (or dataflow equivalents, no iteration, no classes, it is lower level than even assembly language. From a development POV this is horrible. Create a 32 section unrolled loop, and then... oops, yo uneed to make a change... so delete all 32, make the change, reconstruct all 32 instances, test, repeat again and again... nightmare of wasted hours and RSI.
But that's not the worst of it. Cut'n'paste code is terrible for old bugs. You discover a bug in some often used macro... now you need to find every instance of that macro and update it. What if you miss one... then later use that instance to make more copies... oops...
And even worse, modern cpus really don't seem to like multiple copies of exactly the same code. It's bad for caching. Cache efficieny of core tructures seems poor. Working with Blocks, as you add more instances, particularly of complex blocks e.g. 'West Coast DWG Complex Oscillator', the cpu usage rises exponentially. One instance is 2% cpu on my system. eight instances is 45%. While this is a genral issue with all software, the effect could be significantly reduced if those instances all referenced single shared funtions, instead of blindly repeating exact copies of the same code over and over.

Scalable vector graphics canvas

OK, lots of folk asking for a scalable interface for the main application GUI, but what about a Primary panel module enabling the loading and basic manipulation of vector graphics images... SVG or something. That would allow builders to create scalable GUIS, or at least partially...

…

Any single one of these features would make a significant difference to what I could build with Reaktor.

There are plenty of other more niche features I would like to see, 64bit integers, more bitwise operators, some SIMD access in core, MIDI SysEx, MIDI 2.0, more and better built in dev tools, self patchable patch'n'play instruments etc. etc. etc., but that's enough to be going on with.

Like any toolkit or building environment, the specific needs of each craftsperson differ.

It's not unusual to see a very divergent list of needs, and also a very divergent list of requirements as a result.

Please don't fall into the trap of any one person assuming their needs are more or less significant than those of the other. All feedback can be considered valid, and it's up to us to prioritize it as best we can given what we know.

To shed a little bit of light as to the topic we hear most about: beyond specific feature requests for the builder capabilities in Reaktor we hear more about the player experience (e.g. the clunkiness of browsing, loading, and playing ensembles built by yourself or others).

And if we address anything in 2026, we are likely to start there. Making the experience of using Reaktor content a much smoother one.