Blocks: your verdict?

Greetings Reaktor community.

So we've been living with Reaktor 6 blocks for several months, have had plenty of time to get a feel for them.

What is your verdict about them? Pros and cons about their usefulness for making music. Their flexibility. Their power. Their sound quality. Their ease of use. Their programmability. Their customizability. Their look. Their CPU load. Their abilities and their limits. The whole big picture.

Do you see them as a replacement for the old approach of making a single-instrument/panel ensemble with macros? Or an alternative?

 

My take:

Pros

High-quality sound.
Ease of connecting blocks into an ensemble and then saving ensemble-wide snapshots.
Love that pretty much everything runs at audio rate, reduces clicks and makes new sounds possible.
Built-in and easy-to-use modulation is great.
Ability to save block-specific snapshots in an ensemble.

Cons

CPU load is often quite high.
Multiple-instrument/panel appearance is ungainly.
Being forced to program in core is unfortunate; having a choice would be better.
Lack of built-in stereo and polyphony, and the difficulty of adding these to blocks.
The modular paradigm of having controls go from 0 (or -1) to 1 makes changing control ranges tedious.
From a builder's standpoint, some of the objects you need to get at frequently are buried so deep in sub-macros that they are hard to reach.

In general, I prefer the single-instrument, single-panel approach to building Reaktor ensembles, both as a builder and player.

 

wrong! It's a must. Every modular system (Hardware or Software) needs this. How should a LFO „know” whether its signal is used for amplitude modulation or pitch modulation?

 

the other day i opened an R5 enesemble and dragged all the faders, buttons and gui elements together in a oner. i really miss that!

R6 brought some advantages like you say with a wicked sound qualtiy and ease of patching. You can prototype a decent machine in a few hours but design will bog you down for days. the stacked macos and hidden elements. yes its doable, but its like the most awkward and difificult system for gui elements now. it was kind of the other way round in R5. I like single panels, but maybe other users are going to prefer the Blocks cause they can swap in and out stuff to custom their own versions...all in all for the price and the new sound possibilities its a win.

 

I understand that having a specific consistently applied range of control output values is a necessary part of the modular paradigm.

But there are times that I would like to limit the range of a control. Staying with your LFO example, I might want to limit the value of an LFO frequency control knob to .01 to 1 Hz. It is possible to do this in the LFO block, but tedious and awkward. It is much easier to do it outside blocks.

 

As I see it, Reaktor is not a very builder-friendly platform. Yes, you can do pretty much anything if you're willing to put in the time and energy, but NI made MANY UI decisions that are engineering/results-driven, rather than user/process-driven. That's my main gripe with Reaktor 6: Instead of taking the opportunity to optimize the UI for builders, they chose to create a new Reaktor paradigm (blocks).

 

blocks is great!

it gives you easy access to core and shows many corecells in action that otherwise would be much harder to understand residing simply in a library. Also it lets us builders pick some parts out of it and combine them for our own creations.

CPU is a problem though

But buying a new Eurorack module is also "expensive"

so lets all take our favourite Parts out of blocks, put it into a single processing corecell and write every modules output into an array for a convenient modmatrix without the limitations of the Blocks A & B modbus

Thats what Im doing right now.

with Blocks NI eased many design decisions that otherwise would have left me baffeled like a band of unblown balloons.

like modrange -1...+1 or 0...1

 

One way to fix the problem I have with block ensembles consisting of multiple instrument panels is to move block structures from instruments to primary macros, then save these macros in one high-level instrument. That way I'd get the benefit of block modularity and power without losing what I like about the appearance and usability of single-panel ensembles.

What I'd lose is the ability to save block-specific snapshots, which is another big pro to the block ensemble-creation paradigm. But that's something I haven't seen many builders use, except perhaps for certain effects blocks like Reverb, Delay, etc.

 

I agree with some of the points you make, and the pros you mentioned are spot on, but I can't agree with some of your complaints.

First of all, some of the format's operating principles, e.g., all audio-rate modulation, clock routing (sans GREs at least), etc., are not possible in primary. Secondly, it's more CPU-efficient to keep as much of a given structure as possible in one layer or the other, and also, while I am hardly an authority on core's event handling vis-a-vis primary's, I know there are some fundamental differences which I could see presenting some tough-to-squish bugs.
Also, not to be a jerk about it or anything, but I think that incorporating primary-level processing in the blocks format would be inviting a glut of structures from inexperienced users that look something like this:

(Anyone here remember the wasteland of half-baked HyperCard games that was AOL's user upload section in the early 90's? I want to avoid that kind of situation.)
That being said, I do occasionally miss primary's more robust voice handling when I'm working in core.

I have no idea what you mean about lacking stereo. There there are plenty of stereo blocks, and stereo I/O doesn't involve anything more arcane than making a pair of terminals instead of just one--and the templates are set up that way from the get-go. (Of course what you build in order to actually produce a stereo image is entirely up to you, but that's no different than in primary.)
The polyphony thing is a fair point, and if you need that, then blocks are by their nature going to be a questionable choice, pretty much like with hardware modulars. For what it's worth, the lack of support for polyphony frees up voices for use in complex parallel structures, which I've found useful on a few occasions (although like I said, sometimes working with individual voices within core is awkward).

This really is the only sensible way to maintain uniformity and interoperability across different structures, and furthermore is kind of a baked-in part of the modulation scheme (I wrote about how this works at length in this thread).
x * 0.99 + 0.01 is not exactly a ball buster. Usually I just use an xa + b or xa + y, as scaling from 0-1 is usually basic arithmetic I can do in my head (for something like your example, even a Clip Min would work in a pinch). For when I'm too lazy, I modified the factory [x,y]->[u,v] macro to expect a 0-1 input signal, so all you need to do is specify the min and max values, and the input is scaled for you.
I do kind of miss being able to specify a particular number of steps for controls, like you could in earlier versions of R5--putting, say, 1/127 into step size is a hassle.

I don't agree with that at all. Of course you're right that blocks is R6's major selling point, but there are lots of builder-oriented improvements as well--if anything, I think users less inclined toward building got the short end of the stick here. I mean, the primary and core macro libraries have both undergone significant and much-needed overhauls which include debugging structures like event watchers and scopes, and transfer function libraries for making, e.g., custom filter or envelope displays; toolkits are provided for making one's own envelopes and filters; there are a number of macros for modifying and routing different clocks; core cells have been consolidated to seamlessly handle both audio and event I/O; bundles and especially scoped busses make routing large numbers of signals and/or routing signals to deeply nested structures way, way more painless; and color coding integer signals/different connection types/feedback loops makes core a lot easier to navigate.

 

For example the A B buttons, was there no otherway to implement this feature without using a stacked macros?... they jump!!, you can't line them up. it takes 3 or 4 goes. sometimes when my eye is good i nail it on second time, but thats rare.

then consider a Block ensemble can easy have 15 blocks x 2 A/B mods = 30 ...then x 3 attempts + all the clicking on/off the box and locating each one in the structure and you can arrive at 500 manouvers to just move your A/B mods... and thats just one component were taking about! compared to on a single panel GUI in Primary you can shift those 30 buttons just by selecting them and then move them all in one manouver... so thats 30 clicks compared to 500. Really! it would be hard to dream up a more inefficient a sytem... in this sense R6 is not an upgrade...it gone very far backwards to what you would expect in an earlier version like Reaktor 2 or 3... or even beta.

Anyway it still rocks, it just seems there been a ton of cons added in with the pros.

 

Gnome, to respond to a few of your points:

In my experience, core tends to be more tedious and time-consuming to program than primary. It's a bit like assembler vs. a high-level language, though less so now that there are so many useful core macros floating around. Forcing block builders to program in core creates a "Reaktor builders divide" in which you end up with an elite class of core-fluent programmers who can make cool and innovative blocks and a much larger group of primary programmers who can't (due, mainly, to time constraints). I find this unfortunate.

Yes, it's usually quite easy to modify the block code to get controls to output a specific range of values. But not always, especially if the block control has a value display (like the LFO Frequency control) that needs to reflect the new value range. As someone who relies so heavily on randomization, I am almost always very concerned with control min/max ranges, which determine to a large extent the "success" of a randomization. Not being able to set these easily and conveniently (without modding the blocks) is a nontrivial con for me.

As far as the Reaktor UI goes, UI design is my field, and I can assure you that -- from an interactive design best-practices perspective -- the Reaktor 6 UI is problematic, especially for builders. I could compile a list of dozens of issues, ranging from subtle workflow inhibitors to dramatic user-unfriendly choices. And I'm not alone in this: The forum is filled with UI suggestions/complaints, pretty much all of which NI ignored!

 

@rachMiel

unfortunately Core has a much better sound quality, especially synthesis - probably because builders can really get deep inside dsp structures. sound quality matters more and more to me these days, and i have been very impressed with the sound of the Blocks Synths.

sowari

 

What sorts of things do you find to be more difficult to do in Core?

 

Everything is way more difficult in core. I mean i like difficult, but Core seems slighlty illogical and overly difficult , its always harder to pinpoint exactly whats going and where its connected.

Many of the connections are virtual and wirelessly connected, so you can't get as easy an overview of whats flowing where. thats critical for me on big projects, in Primary i can open up any project, and no matter its complexity i just understand it all at a glance .and i may have even forgot i made it. but still, in a flash i can recall everthing thing that going on in 2 seconds flat. thats one of primarys greatest strengths.

Also i find Core is just not as nice an environent to spend hours in, its dark and small, the texts are horrible, nothings named in a human language, i can't explain it, it simply doesnt inspire.

In a word Core is an Ugly tank, and Primary is very beautiful Red Ferrari.

 

Also i am not so convinced of this extra sound is only acheivable a result of Pure Core being used at all times.

How is it some amazing sounding ensembles of past like SpaceVerb + Skrewll

Could it not be if Reaktor 6 had been coded multicore and some top DEVS spent as much time developing some cool Block style fx and instruments coded in Primary with a sensible template for A/B we could not have the equivalent sound and a neat MOD system, but coded in mainly in Primary, perhaps just with a few very specific DSP procesing macros done in Core when it was impossible to do another way in Primary, and all at a lower CPU cause of the multicore ability. i bet that was a possibilty!

 

Perhaps you should finally start with this : now the same in core!
... and downoad: REAKTOR RIDDLES

 

do you mean Space Master? the current version is Core.

Skrewell, is great but i am talking about more conventional 'Analog Synthesis' and comparing Reaktor's sound with commercially released synths such as Ace/Diva (U-He), and the Arturia V Collection. for me the Blocks synths sound much better than the Arturia synths, which was not the case before recent developments in Core building from the Reaktor Gurus.

what i need is for the Reaktor devs to create and release more Core Macros so it would be easy for 'lego builders' such as myself to build stuff. Here's link above now the same in core! is a good example of what i am talking about.

with Reaktor 5 i definitely agree with the visual aspect of Core and that also put me off from exploring, but i feel Core in Reaktor 6 looks better on my Macbook Pro.

sowari

 

Core structures DO sound better than primary. With primary you're limited to how the modules were hard-coded. That sawtooth will always alias as **** because it's a naive sawtooth algorithm. Core sawtooth osc is a different story. And please, let's not mention the primary filters. They're just not good enough, period.

Yes, it's more tedious to work with (but the results are MUCH more rewarding sound-wise than primary only, IMHO), but Core is not intended for casual tweaking or patching anyways. Core is intended for DSP wizards. Thankfully, in R6 there's a lot more Core macros, so medium to advanced primary builders can also dip their toes in..

 

maybe all of the Primary Oscillators/Filters should be recoded?

sowari

 

Nope, backwards compatibility is priority (well, I guess they could have Legacy mode in module properties, but...). That's why NI did better versions in Core. I think the focus of NI is to expand Core, rather than expand primary.