As a builder, how would you feel about a total compatibility break for Reaktor 7?

AsylumSpeaker · 2022-08-15T15:17:00+00:00

There was an error rendering this rich post.

If you could have your own personal wish list for changes, updates, features and fixes for R7, would you accept a total compatibility break with older versions? Meaning no existing ensembles, macros, instruments, etc. would work at all in the new environment. I'm getting to feel that I would prefer that future for Reaktor.

My take on this is that if Reaktor were to transmogrify into a 3 layer structure of Panel & IO, Core, and Data all of which interconnected with controllably scoped tagged buses, and if a fairly substantial list of things-I-just-don't-like-about-Reaktor were changed, I think I'd be happy to have all my existing work left in the past and start with a clean slate. No Primary/Core split, completely modern scalable vector graphics panel sets with simplified control building and animation, and a universal data structure that could handle arbitrary data types in multidimensional arrays. Naturally a modernised compiler and various other under the hood changes, but I'm thinking more in terms of tools and workflow with this discussion.

How do you feel about the principle of a compatibility break? What would building in R7 have to implement for you to be happy with a break?

Find more posts tagged with

Reaktor Building

Comments

colB

It's not going to happen ;)

The problem is that the only sensible way forward would be to ditch Primary. But to do this, all the GUI and IO stuff would need to be scrapped, and also some long standing problems with core would need to be fixed - problems that the devs have failed to fix for the past 16 years, after supposedly numerous attempts.

It would make more sense to create a new product. Then have a period of time with both being supported, then deprecate Reaktor and switch to the new thing...

Doesn't matter though, it's not going to happen. The issues this would resolve for builders are pretty much invisible to the majority of users. The issues it would create for that majority of users would be significant. It would also cost a huge amount of money. It just seem completely implausible.

On top of that you have to factor in the 'powered by Reaktor' products, and the third party licenced products... these would also require re-writes in order to allow continued maintenance. Just seems like it would be a crazy thing to do.

---------------------------------------------------------------------

Instead we need some modernising of the GUI layer - particularly vector based graphics and scalability of some sort. And we need core updates, particularly to the table framework for read write memory/file access in core. Core iteration would be nice too, but that seems unlikely after all this time. I would also like a module that provides access to the keyboard for text entry, and/or real time keyboard polling... The sort of things that would make core more general purpose, that way we can build things that were not considered by NI.

colB

We also desperately need a mechanism for code reuse. I think that this could provide a large saving in cpu usage for large core structures, because it would allow inner unrolled loops to re-use the same loop code.

At present, if you have an inner loop with say 16 unrolled iterations, each of those identical chunks of cut and paste code need to be loaded into the cache individually as though they were unique... terrible performance can result once projects get to a decent scale.

There are so many things that could be done to dramatically improve Reaktor without breaking backwards compatibility.

Gui scaling, vector image support, pixel based 'canvas' with scaling...

table framework memory/file Read and write

code reuse mechanism

core iteration

keyboard access

fix for the compiler slowing down problem

multi-touch support for touchscreens

and many more!

Literally decades (in Reaktor years) worth of updates that could significantly improve Reaktor without sacrificing backwards compatibility.

AsylumSpeaker

https://community.native-instruments.com/discussion/comment/27662#Comment_27662

I filly agree that it's not going to happen. I'm just curious about whether the building community has become skewed over time towards those who are so wedded to Reaktor for good or for ill that they wouldn't like development if it meant breaking with their existing body of work. And I wonder too how long we go on for without things like code reuse and core iteration, things that are kind of basic development requirements. Or anything on your list really, plus list processing would be amazing, and truly globally scoped variables... you know.

At some point I think a major overhaul is necessary, and requires eventually becoming a new environment.

You're also right that building and development is a small part of Reaktor, but I always find that very hard to understand. As an instinctive builder, I wonder how anyone could use Reaktor without building their own stuff!

KoaN

https://community.native-instruments.com/discussion/comment/27684#Comment_27684

I guess for me as long as i could run Reaktor 6 along 7 and not be forced to stop using my older creations i would be fine with it.

I always remember Vadim "is he still part of the team?" saying maybe 4-5 years ago that there was still tons of room for improving Reaktor,but yah i honestly would believe it's a miracle if we see those things ColB mentioned implemented.

About the users not being builders,let's not forget they are the ones who will show interests on new,great sounding,creative ensembles.With so much choices today and rehashes of about everything...a big update like that would certainly open new doors soundwise.

Chet Singer

I can't see it happening. I'm sure that every obscure feature of Reaktor has at least one popular ensemble that uses it, guaranteeing grumpy unhappiness if it's ever removed. I've done software product rewrites, and every single user demands that their favorite feature still exist. And if it doesn't, they'll ****** until it is. What a headache.

If Reaktor is becoming too expensive to maintain then I suggest ring-fencing it and creating a new revenue stream by offering a genuine replacement.

Any successful replacement would have to deliver something new and wonderful that Reaktor never could. And I have a suggestion: a product that lets developers (that is, us) use Reaktor's wonderful (and unmatched, imo) core dataflow language to create embedded audio applications that are portable across Windows, Mac, iOS, and Android (standalone, VST, etc., the works). It's what the Superpowered SDK claims to do now, but using Reaktor's visual programming instead of C++. It would open up iOS and Android audio development to the masses. I've been searching for such a development system and I'll pay serious money it.

AsylumSpeaker

https://community.native-instruments.com/discussion/comment/27685#Comment_27685

See, if it's deeply unlikely we see the long overdue feature implementations (I agree) and if it's too tectonic a shift to move to a completely new, ground up platform regardless of its name, what then? Stagnation, with a desultory few features every few years? Not only is that no future, but it seems at odds with NI pushing NKS and encouraging licensed Reaktor plugins. Surely they want people to be able to build the instruments and effects that will make the NKS system a must have for every developer? Right now, in my opinion, Reaktor needs a big redesign to fulfil that brief.

KoaN

https://community.native-instruments.com/discussion/comment/27831#Comment_27831

I guess after all this time i resigned myself about seeing those updates.

I do remember though when the panel cables update got out ,there was a conversation with the Reaktor team "sorry for mentioning this again!" and the impression i got was "This update will please the users but we haven't forgotten about the builders" I had the feeling the next update would be focused on builders...but then the company completely changed and now the Apple debacle so...it's been pushed away for sure,hopefully it is still in the plan if that was the plan at all.

If i remember well Reaktor 6 was quite a surprise that nobody expected when it came out,so who knows.

AsylumSpeaker

https://community.native-instruments.com/discussion/comment/27843#Comment_27843

Strangely, it was panel cables that started me thinking about this whole issue. Every time I try to get into VCV Rack I make great progress, love the music I'm making.... then get frustrated with it's hardline 100% skeuomorphic approach. If it's not like using a real life Eurorack module, but with a mouse and half a MIDI implementation, it's not there.

The 2x mod matrix built into every Block, with optionally visible or hidden controls and destinations arbitrarily chosen by the Block developer, well, it's a 21st century, computer-native approach. I like it a lot. I'd prefer to build every single module myself in Reaktor, if it meant having things like snapshots and multiple panels, or contextual menus. I can integrate it deeply into a Maschine project for flexibility. I can do all kinds of things, but at the end of the day, it's hard. I want it to be easy, and I tell myself I'm good at this so just work at it and it'll come out well. But then I have to spend time nudging around invisible macros to make a panel element and all the while there's a Max 8 icon right there at the bottom of the screen, whispering to me about unified UI and processing objects and Presentation Mode...

KoaN

https://community.native-instruments.com/discussion/comment/27855#Comment_27855

I hear you.

Building a nice graphical interface is a lot of work in Reaktor! I think in all my time building stuff in Reaktor "it's been more than 15 years now" i spent almost as much time on the graphics as the ensembles themselves.

The graphical modules like "display" etc are still hard for me to master.

But on the other side,Reaktor or not building a graphical interface is a lot of work...but for sure some things could be improved on that side,nudging around invisible macros and layers can be frustrating.I remember when you only could move an object by 4 pixels at a time "prior to Reaktor 6" it was maddening!

Cal Scott

If R7 could transmorgify to be multicore... a compatability break would be irrelevent

AsylumSpeaker

https://community.native-instruments.com/discussion/comment/27903#Comment_27903

I have to admit, for a moment I thought "But... we already have Bundles...?"

colB

https://community.native-instruments.com/discussion/comment/27903#Comment_27903

How though? how would multi-core work within the context of building in Reaktor?

Cal Scott

https://community.native-instruments.com/discussion/comment/27968#Comment_27968

I was thinking it would be great to extend some of the chaos bands so they would have more sophistication out of the box. At the moment there will always be some compromise due to cpu limits, so the kik can't have compression, or the snare can't have reverb, or whatever.... all these things can be done in post, but it would be great to get closer to a finished production direct from an ensemble.

AsylumSpeaker

https://community.native-instruments.com/discussion/comment/27968#Comment_27968

Obviously in most cases audio jobs have to be done serially, and multi core operation doesn't help. But surely a redesigned, multicore focused compiler could detect when whole processing chains were completely separate, and distribute them effectively? For a single instrument that would likely have little to no effect, but the big use case I'd see would be Blocks, especially in large racks. Whether or not that is a good UX decision is an open question: Having your computer fall over when you patch a chain on one core to another, so they both get moved the the same core running at 150% is bad. Running way more blocks at a given vector size is good. But it's certainly a good use case, and NI does seem to want to push Blocks a lot.

colB

https://community.native-instruments.com/discussion/comment/27979#Comment_27979

But surely a redesigned, multicore focused compiler could detect when whole processing chains were completely separate, and distribute them effectively?

I'm no expert on concurrency. But surely there are some significant overheads, so deciding how and when to use concurrency is a non-trivial engineering job involving some serious benchmarking... and the results may not be generalisable enough to do it automagically. Far more useful at the compiler level would be access to SIMD processing. Again this would require more knowledge and learning investment from users to work well. Which kind of pushes against a fundamental philosophy of Reaktor - programming for non-programmers. There are so many users who already find core to be too difficult and confusing :)

The idea of using multicore at the instrument level is maybe more realistic. But I suspect that a lot of the folk over the years demanding multi-core are expecting all their stuff to just start running way faster, and that is unlikely to be the result. So years of complaints and criticism from users when it just doesn't work like it ought to... Would be cool though in some future Reaktor where Primary is deprecated, and the top level instrument layer allows us to visually place different instruments/blocks onto different threads - make it high level, and explicit, so it's something you have to do manually, it's simple, and there are less likely to be unrealistic expectations.... Only problem there is that it's already possible to do that with Reaktor in a good DAW, so why go to all the expense of re-inventing the wheel?

Another option might be polyphony based - this seems like the best fit technically, but then it's of little use for Blocks, and could cause issues in those many situations where polyphony is exploited for other unintended purposes.

Seems like there are other things that would be easier to implement that would also give a better performance boost... like a code reuse mechanism in core...

Quick links

Unanswered questions