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

Wellsie · 2024-12-07T07:23:10+00:00

There was an error rendering this rich post.

Please reconsider Reaktor as something you could re-launch as a fully featured DAW when used in Standalone mode whose full capabilities/potential would be unlocked if the following features were added:-

VST hosting: In rack/panel mode, VSTs appear as they do with their UI but they can be collapsed to a small rectangle with (say) 8 knobs assigned (collapsed is the default view in edit mode). Audio/modulation ports in and out either side to allow modulation from other Reaktor instruments or ensembles or VSTs. Mixing bus nodes and ensemble groups.
Colours for connection lines in edit mode.
Factory Wavetable OSCs (and synths) and filtering
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.
Multi-channel midi for hosting multi-channel midi generator VSTs (like Harmony Bloom) and multi-out ensembles within Reaktor (like ScapeShift). Multi-channel audio ins easily selected from connected audio interfaces. Multiple outs for use in a daw or to large mixing desk. Input nodes for bringing into realtime data from electronics prototypes and videogame hardware like gamepads, VR headsets and controllers/gloves.
To make this performant also provide multi-threading to all parts of Reaktor (probably requiring modifying all nodes to be multi-threaded.)
GPU mode - expand the multi-threaded aspect to take advantage of GPU processing.
EXPORTING of optimised Reaktor ensembles as compiled VSTs for loading back into Reaktor as an optimised uneditable VST increasing the amount of complexity possible. Patches containing hosted VST plugins will not export of course!
Create an online marketplace where people can upload for free or even sell the VSTs they make, with a rating and automatic refund system (which deletes it straight out of the program). If developers wish, they can even provide the original ensembles to foster learning or customisation. NI takes a cut from each sale. Wrapping Reaktor in a new commercial ecosystem would reinvigorate the creative part of the Reaktor community and bring a lot of new blood! Terms and conditions plus an approvals process should prevent people from trying to sell cheap clone plugins.
Uploaded VSTs can be tagged usable outside of Reaktor but can only be purchased from the NI store.
(Getting greedy now) Enable C++ development of custom low-level nodes by third-party developers. Also sellable on the Reaktor Store.

With these changes, Reaktor could become the most customisable DAW in the world for which people could design their own interfaces or forms of interaction. For full version release: include multiple new sequencers, traditional piano-rolls, audio loop playback and pre-made mixing, channel strips and mastering tools. Plus provide some new ensembles and the ability buy and download VSTs from third-party partners and use them straight away instead of having to download, extract and install. Rebrand it as (say) “Reaktor X” so you could even reboot it as a new product, but you MUST make it compatible with all existing Reaktor ensembles in the library. (These could also be instantly downloaded into your project rather than having to download, locate and reopen).

Find more posts tagged with

Reaktor 6

Feature Request

Comments

Sunborn

https://community.native-instruments.com/discussion/39637/reaktor-x-transform-reaktor-into-native-instruments-flagship-product-daw

"Fully featured DAW" and "VST hosting"??? 😳 😣

Most horrible idea about Reaktor i ever heard. PLEASE DON'T!

Evolve Reaktor? - Yes
Add Features? - Yes
Change its nature to something else? - NO, NO, NO.

gentleclockdivider

https://community.native-instruments.com/discussion/39637/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 .

Vocalpoint

And let's not forget the part where Reaktor has already been declared in permanent long term maintenance mode. (dating back to March 2023)

Updates and tweaks for major OS changes only now.

Big Gnome

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?

Wellsie

https://community.native-instruments.com/discussion/comment/197483#Comment_197483

Yeah, I saw this pop up on a feed within days of posting this. This is a shame but it won't be the first app I've loved that eventually got canned/abandoned.

Wellsie

Everyone who replied seems pretty adverse to the suggestions!

TBH I didn't think anyone would answer the post let alone take the time to write such thoughtful replies, so thank you.

I'm not going to elaborate further on the idea by writing counter-arguements, if that's ok.

And apologise in advance if NI take any of the suggestions seriously! 😅

Vocalpoint

@Wellsie

"Everyone who replied seems pretty adverse to the suggestions"

I am never adverse to anything that moves a product forward. But that really only matters when the product is actually relevant and moving forward.

NI has a different owner with a different mindset and vastly different long term plan - one that unfortunately does not involve any of the "old" NI guard.

Understandably - you don't need to like it but that ship has sailed - almost two years ago now.

colB

https://community.native-instruments.com/discussion/comment/202790#Comment_202790

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.

Quick links

Unanswered questions