Reaktor 6.3: Where's the documentation ?

I wanted to look after some information I forgot, by accessing directly to the correct PDF file via the help menu, as usual.
But in 6.3, all the links to the documents have been removed . Even the PDF files have been wiped out of my drive.
So I have to download the whole stuff manually ? And to find another way to access them not as efficiently as before ? Sorry NI but I'm not pleased with this
I'd exchange the new rack feature with the bundled documentation without hesitation.

 

Some are here
https://www.native-instruments.com/de/products/komplete/synths/reaktor-6/downloads/
in the middle of the site

 

Yeah that's what I said… I have to download the whole stuff manually.

 

There is some discussion of this in the other threads about the 6.3 release .

 

It's better than an online manual IMO

 

Sure, but we are still one leap backward.

 

We have been moving away from including PDFs in installers for a while now. Instead, we offer PDFs on the Downloads page, which is linked from the Help menu. I understand this is an inconvenience for some, but it was a necessary step to resolve dependencies in the deployment process and deliver up-to-date documentation upon release. It also increases the chances that continuously improved documents actually find their way to the user.

 

So let the users deal with it then… sad…
If the documents are continuously updated, I'm ever more disappointed by the need to browse the same page and download the same file every time I have to take a look into it, if I follow your argument's logic. Better to go for full online mode then, too bad for users who don't have a permanent connection on their gear.
Please at least add a synchronized list of the documentation in the help menu, with offline mode and auto-update of the files once they are modified online.

 

I agree that downloading PDFs is not ideal. We are looking into better ways of delivering documentation to the user, however for the time being the Downloads page is the place to get it.

 

Hi Jan,
Thanks for explaining this, it's helpful. I'm not sure I would have put off updating if I had known I would have to retrieve the prior docs, but it would have been nice to know it was going to happen. (Preparing users for necessary inconvenience is one way to diminish the inconvenience.)

Also, perhaps you can say something helpful about the fact that rack-connections aren't saved with snapshots?
This was conspicuously avoided in the documentation provided about racks and saving rack files as presets. I'm not sure how much I would avail myself of the same rack setup from one ensemble to another. What would really be a great addition to blocks would be having the option to use the same blocks with different wiring setups. Clearly it's possible to implement this, though perhaps snapshot design would need an update itself.
Is there a plan to implement this in the future? Otherwise, what seemed like a really big improvement (we can change the wiring without needing a new ensemble) will go up in smoke.
Best regards and thanks for any more information you can offer,
Catman

 

I am not sure I fully understand your question. Racks don't have Snapshots, instead they store all settings including connections in a single file, or the host project. This is possible because a Rack only references the Blocks, but does not include them like an Ensemble does.

 

I'd just like to say: Jan, props for answering here on Sunday evening!

Regarding Catman's question, people would like to know if Racks will get some sort of preset saving functionality, so that you could have different wirings/parameter settings stored within ONE .nksr file as presets/snapshots, instead of requiring to save a new .nksr for every different wiring/parameter setup you make, even if you use exactly the same blocks. Surely there's a lot of validity in having such a feature available.

 

Well said, Evil Dragon!
And yes many thanks to Jan for being with us on a Sunday.
I'll add this: When looking at a Panel view, and seeing ports on blocks, it isn't surprising that we users might see the ports and the wires that connect them as Panel Elements; i.e. similar to Knobs, Buttons, etc.
So another way to pose the question would be, can we have any given rack-file we save associated with (and therefore in a sense 'in') a given snapshot, such that a different snapshot in the same ensemble could use the same blocks, wired differently, thus amounting to a different rack-file (also saved separately), such that each snapshot could recall the rack-file that 'belonged' with it? That would be HUGE!
If it already does this and I'm missing that enormous point, my apologies to everyone.
Catman

 

You and me both, Arachnaut!
I was thinking about the complexities of connection and how I would encode that into something that would, from the computer memory standpoint, resemble the value pointed to by a Snap-ID. Thinking this might be, uh cumbersome, I thought maybe just adding storage for a rack-file name to the snaps wouldn't be all that difficult for programming and maintaining backward compatibility and that sort of thing...

 

TL/DR: Racks don't 'have' Snapshots, but do they save data that's been stored in snap value modules and snap value array modules in those pesky .nksr files?

Time to muddy the waters even further

The connections between the modules, their internal structure, and the control settings etc. all together are the equivalent of a 'patch' (in an abstract sense) or a 'sound' whatever... So it kind of makes sense to just store the lot every time you make a new sound.
I remember thinking about this when I was a Reaktor noob, and wondering why the heck the snapshot system was so complex!
Of course when Reaktor was new, 50mb or whatever filesize was a LOT of disk space, so it was totally impractical to save every sound as a new instance of an ensemble. So snapshots were developed to allow a disk friendly format that could capture all the settings of a sound without duplication all the coding/structure of the ensemble. Great.
But also lots of cool features were added to snapshots, like morphing and randomization. Also useful modules allowing builders to build snapshot aware components for extreme flexibility.

Now we are presented with a new alternative system. This has a different approach to reducing the file size of a complete instrument by using reference id's, so from one point of view (a fresh start POV) there is no need for snapshots or presets - because they were really just a way to save disk space.

Unfortunately, this has been introduced into a very mature application with a lot of existing content that depends on snapshots. And also a feature set that has developed in the context of snapshots supporting some not insignificant functionality. From this point of view, it seems like it would have made more sense to build a separate application with no attempt at backwards compatibility rather than bolt on a new incompatible layer.

An example of the functionality that the snapshot system provides is my Digit8 instrument.
This allows the creation and editing of bytebeat formulae for generating cool (and awful) noises. It is completely dependent on snapshots as a mechanism for saving the bytebeat expressions that the user develops. It uses the snap value array module for this purpose.

Other devices I've built use similar techniques, as well as one of my current projects, so it would be good to have an answer to this one.

Do racks store data from snap value modules and snap value array modules in the .nksr files when you save the project?
(This would have been easy to test and work through in beta if we'd had builder access to the new features...)

 

No no - your mind is okay. Take your HexViewer and load in a nksr file. There are port IDs a lot. So the function tap can work if the programers want.

 

I must be missing something , but snapshots do work in ensemble mode with the new blocks .
Could someone elaborate what's missing ?

 

It's in post 14: Jim ask about the ports.

 

Yes, snaps works. We want to include the new ports.
At this time cable your Blocks and save a snap. Recable and save another snap. The first cabeling is gone.

 

Is it still the topic about the documentation ?