Reaktor X - Transform Reaktor into Native Instruments flagship Product/DAW

Most of your suggestions are already possible inanother evironment , it's called : max msp

Why would they include another high level layer ?

They have been doing that for multiple times , be it in the form of macros and more recently blocks .

The core macro's have everything to get you started .

If there is one thing that reaktor could really do WITHOUT is another obfuscating layer .

Blocks , while sounding great wasn't such a succes after all , racks was even a worse idea

Vst host : verry bad idea

If you look at the competition like max-msp , the latest version includes high level modules of ableton stock dsp ( filters , synths ) , this may look nice for people to patch stuff directly but it also means that the more adventurous minds can't have a look at the dsp code since it's not done in gen~ but rather locked black box code .

This goes to show that lot's of developers are simplifying things to reach a bigger audience , and imho goes against the nature of the programs .
That being said , I wouldn't count to much onfuture development for reaktor , it's great as it is ( with all it's warts and whatnot ) , grab something like max or plug(pure) data to fill in the missing gaps .

VST hosting—this opens up an aisleful of cans of worms, both technical and practical without conferring, as far as I can tell, any benefit (at least without being a real crapshoot, i.e., behavior vis a vis feedback or audio rate modulation) over just loading up the respective plugins within any DAW worth its salt. I'd suggest if you want to boil down a bunch of Reaktor stuff alongside other plugins and maybe set up some simple macro controls for the whole contraption, I'd use something like Patchwork.

Colored wires—I'm of two minds on this one. I kind of like the idea, and I can see the utility, but for one thing I can see this potentially inviting some real retina-melting eyesores that could (deliberately or otherwise) do more to undermine the clarity of a patch than elucidate. (Ever seen one of those ensembles where all the macros are unlabled, positioned on top of one another in the patch pane, and interspersed with a bunch of dummy modules as an ad hoc attempt at copy protection? That's super obnoxious, and I would not like to see colored cables further contributing to this sort of obscurantism). Also, colored cables are already used, sparingly and mostly within core, to denote different distinct types of connections—white for floating point data, orange for implicitly resolved feedback loops, green for logical connections, blue for integer data and bundles, and tan & yellow for float/int memory respectively.

Wavetable oscillators—if you're talking about primary modules, that's what Sampler Loop, Sample Lookup, and Audio Table are for; if those are insufficient (and hey, granted, their interpolation is nothing to write home about), rolling your own in core is an approachable intermediate-level project, and the table framework opens these up to some of the more comfortable built-in sample loading interface. If you're talking about adding a wavetable oscillator to the factory library, I'm with you there, that'd be nice.
There are plenty of wavetable synths in the factory library, UL, and amongst the proprietary made-for-Reaktor landscape.
I'm not sure what you're referring to with regards to "filtering" in this context…?

A new high-level "layer" collection of nodes: a series of macros easily connected to help newcomers ease their way into creating their own instruments and FX.
Not sure how what you describe would differ from the factory macros…?

Reaktor already sends & receives multichannel MIDI & audio. What are you missing out on here?

Multithreading—this has been discussed to death in the past, and would open a major can of worms. This is by no means a magic-bullet make-it-faster-izer, and the devil is very much in the details. Probably the most logical approach would be passing off individual voices or instruments onto their own cores, but then what happens with multiple instruments patched in series? In a combination of parallel and series? That likely imposes a huge bottleneck where one or more threads are idle till they receive their input from another.
How much functionality is exposed to builders? Maybe there's a simple tickbox someplace that is only useful in a narrow subset of cases, e.g., allowing for very simple instruments that efficiently run hundreds of voices, but unpredictably significantly degrade performance in certain patching arrangements; maybe there's a comprehensive framework that practically no one uses owing to the complexity; maybe there's a happy medium, but I very have a hard time envisioning any kind of one-size-fits-all implementation that's usable and not bogged down by edge cases.

GPU processing—GPUs aren't suited to processing audio, which is why everyone and their mother isn't already doing it. GPUs do one thing extremely well, which is to receive data in big chunks from the CPU (a notoriously slow bottleneck), process it incredibly fast massively in parallel, and then back to the CPU. They are really bad at processing a continuous stream of data, let alone one running at hundreds of times the resolution of typical video frame rates. I vaguely recall Urs Heckmann was looking into this sort of thing a while back and ultimately rejected the idea for irreconcilable latency issues. I can't find the discussion I'm thinking of at the moment, but I did find this referencing some of the issues he ran into. (And if Urs can't make that happen with a bespoke framework, for damn sure it's gonna be a nonstarter for the average builder working on a generalized interpreter like Reaktor!)

VST export—I don't really object to this in principle personally—I mean, I like the idea of Monark or Form showing up in my DAW alongside my other plugins as much as the next guy—but I will note that people have clamored for this forever—like, since the R4 days, and it just ain't gonna happen. There's really nothing in this for NI, on the contrary it would seriously undermine the value of the UL and Reaktor as a platform.
Also, remember a few years back during the heyday of SynthEdit? There were a scant few SE cats doing excellent work, but a real glut of naive, low-effort junk VSTs that were a real mark of Cain on the software ("ugh, just another SynthEdit piece of ******"…) Or if you're a little older, maybe you remember the glut of crummy games built in HyperCard (similar to Reaktor insofar as being an early example of an approachable, interpreted platform, albeit for producing multimedia software instead of audio/midi) clogging up public upload sections of BBS's far and wide in the early days of the WWW that practically made HC a byword for "not worth your time". I expect VST export would invite the same sort of connotation to Reaktor.
As far as optimization, core already is a highly optimized compiled environment (primary is interpreted, and as such runs about as fast as it's likely ever gonna; which isn't saying much). Probably the best way this could be pulled off is via packaging each export with a resource-hogging per-instance Reaktor runtime, which would negatively affect the resource usage, if not necessarily the performance, of exported VSTs relative to non-Reaktor software; may as well just keep everything running natively within Reaktor.

Online marketplace—this one gets a full-chested 'hell no' from me. The last thing I want for Reaktor is to build it into a conduit for commerce. Reaktor Player licensing is already an option open to anyone wishing to develop commercially; and the UL for those interested in noncommercial sharing. Again, I think this'd probably just lead to a glut of amateur offerings, with curtailed editability, a price tag, and maybe an annoying new ad pane into the bargain (see: 'Instruments For You' in Kontakt. Ew.)

Reaktor-as-DAW—this just kind of baffles me to be honest. Reaktor doesn't even resemble a DAW, and there are already loads of excellent DAWs on the market. Why recreate Reaktor, which is a unique product that doesn't have a direct equivalent, into another niche, small fry DAW?

Don't worry, nobody with any actual influence at NI reads this forum any more.

In terms of the reception for you ideas, it's the usual thing, newbie with enthusiasm but absolutely no idea of the history, and current reality goes public with totally unrealistic flight of fantasy. Never ends well ;)

Just reframe your ideas in a context where long term community members have asked for relatively (to your ideas anyway) small features to be added, that the development team have agreed would be useful and beneficial, and would like to implement, but are unable to commit to, due to strategy goals of the wider organisation, and prioritisation of extremely limited resources. We are talking about some features that have been requested and promised for over a decade now.

Basic stuff like the table framework that was introduced with an incomplete feature set, and would be great if it was just finished, addition of stuff like writing to a framework table from within core, so allow file writing. just basic functionality.

Also stuff like:

• modifier keys on mouse area
• some form of GUI text input
• scalable graphics
• some form of code reuse mechanism
• core iteration

The actual list is long and most of the items would make a significant difference to folk who build in Reaktor, which would make a difference to everyone who uses Reaktor, because we could make better stuff.

Unfortunately, in the context of these long term relatively basic improvement requests, your ideas seem at best completely unrealistic. Some of them make it clear that you don't even understand what Reaktor is and haven't really learned to use it, not a great POV to be making requests from <shrug>

(===============================================

different selectable colours for wires in the edit pane would be a TERRIBLE idea, wires change colout to indicate error states, implicit feedback, value type… having an option for builders to arbitrarily choose different colours would destroy that

A new high-level "layer" collection of nodes: a series of macros easily connected to help newcomers ease their way into creating their own instruments and FX

There are already loads of high level macros for newcommers to patch together, and there are already too many 'layers'. More layers makes it more difficult for newcommers not easier. If YOU haven't found the collections of high level macros and instruments ('nodes' are not a thing in Reaktor), then it's time to RTFM!

Sorry to seem harsh, but you shouldn't be posting feature requests if you haven't even read the manuals, and you clearly haven't :-)

=================================================)

All that said, Reaktor is a great platform, with a huge feature set, and masses of content, it is a total bargain, and combined with a good DAW (e.g. Reaper), you can leverage multi core processing, and you could make whatever music you could imagine with just those two products. It doesn't need to be changed it's already a beast, just some basic features need adding and/or updating.