Main difference between .ens and .nksr?

TonvaterJan · 2024-10-18T14:20:22+00:00

There was an error rendering this rich post.

Hi, I´m building some Blocks Synths and am having a hard time understanding when to use an Ensemble and an .nksr.

I learned, when saving as an Ensemble, one could save Snapshots within the Ensemble.

But with a .nksr (whatever that means) one can switch between a wireless and a wired view in the Blocks - but with sacrificing Snapshots…?

Thanks in Advance

Find more posts tagged with

Accepted answers

Sunborn

https://community.native-instruments.com/discussion/37457/main-difference-between-ens-and-nksr

Ensembles are the main file type used for final Reaktor instruments and effects. You can consider them as "studios", since they can contain a number of different instruments, effects and other modules. However they can also be very simple and contain just one instrument (or effect etc.).

Racks facilitate analog-style modular synthesizer patching using pre-build modules in the
Blocks format. In a Rack, you can arrange, connect, and control Blocks directly in the Panel.
The patch is also mirrored in the Structure, allowing you to choose your preferred patching
workflow. (this part it is actually from the manual, which is the best way to have answers to most of your questions…☺️)

The use of Reaktor Racks is very similar to the use of hardware racks in a hardware modular system.

…btw, .nksr means (probably) Native Kontrol Standard Rack and its description is NI REAKTOR Rack Data

Bottom line is, that, if you are building Blocks, you have the option to save them as Racks (while still you can save them as Ensembles too), while if you are building "normal" modules (through Primary or Core) you can save them only as ensembles. Racks is a Block feature.

colB

.nksr is 'rack' format. Only works with blocks.

Racks is a much smaller file size and works way better in a DAW workflow than .ens does.

User blocks need to be in a designated folder to be used in a rack.

Racks allow multicoloured patch cables which is nice.

colB

https://community.native-instruments.com/discussion/comment/185419#Comment_185419

there is no way to use Coloured Cables or even hide them

In ensemble mode, the cables are all white, but you can still hide them.

and the DAW-File is more in danger of getting corrupted by the Ensemble itself.

A DAW file is not going to get corrupted by an Ensemble. It's just a workflow that is slightly more prone to operator error.

If you are disciplined with your file management and keep separate copies of ensembles for each project so they don't get moved or changed, everything will be fine. If you play fast and loose, then you might screw up more easily using ensembles in a DAW than using Racks.

Racks are intended for Blocks though, so if you are using Reaktor based poly synths, probably better to just use them as ensembles. I'm really not sure if you can leverage the Rack system to use polysynths in a DAW, or if that would be a sensible thing to try.

All comments

Sunborn

https://community.native-instruments.com/discussion/37457/main-difference-between-ens-and-nksr

The use of Reaktor Racks is very similar to the use of hardware racks in a hardware modular system.

…btw, .nksr means (probably) Native Kontrol Standard Rack and its description is NI REAKTOR Rack Data

colB

.nksr is 'rack' format. Only works with blocks.

Racks is a much smaller file size and works way better in a DAW workflow than .ens does.

User blocks need to be in a designated folder to be used in a rack.

Racks allow multicoloured patch cables which is nice.

KoaN

I haven't explored the rack format too much but i fail to see the advantage of this really,except maybe a smaller file size.You can still patch cables within an ensemble from the panel without nksr or blocks,you just need to make the out/inports visible.

If you could have snapshots within racks with different cable configurations now that would be different but it's ONE snapshot of the cable configuration per each nksr file,for me it kinds of defeat the purpose.

I prefer to save as Ensemble where i know everything i need is in the file itself.

I guess the main thing is the file size,let's say you have made 20 patch cable variations, if you save as ensemble each time it would get quite big.

colB

https://community.native-instruments.com/discussion/comment/185164#Comment_185164

One thing is that a .nksr is not much difference in practical terms from a snap in terms of file size, so no need for snaps, just save multiple .nksr files…

The real reason though is DAW related.

It's all about the 'host chunk'. My basic understanding is that when a DAW saves a project, there is a limited space in the save file for plugin related information. No where near enough to save an ensemble though. So you need to save the ensemble separately, and then the DAW project file references that… which works… until that ensemble gets changed, edited, moved, or deleted… then the DAW project will be broken. I suspect that a lot of NIs Reaktor related support time was/is spent dealing with this type of issue.

.nksr is small enough to fit in the host chunk, so it is saved inside the DAW project… that means it will 'just work'…

You can build up a rack as you work inside the DAW, and when you save that DAW project, the rack should automagically just get saved along with the project. That's the idea anyway I think?

…unless you use a load of user Blocks, and at some point remove them from the user Blocks folder or update them such that they become incompatible…

KoaN

https://community.native-instruments.com/discussion/comment/185195#Comment_185195

Loading nksr files can take a bit of time though,i sometimes have like 2-3 seconds of waiting,not as fluid as a snapshot.

If i build i always work in standalone and when i bring it in a DAW it's for playing with the presets already done but i get that not everybody does that,you sometimes want to edit stuff in the DAW.

Yah you still need to keep an eye on the rack folder and make sure all your blocks are there.With the snapshot system confusing a lot of people and adding nksr into the mix it's not always easy to make sense of the workflow.

colB

https://community.native-instruments.com/discussion/comment/185197#Comment_185197

Loading nksr files can take a bit of time though,i sometimes have like 2-3 seconds of waiting,not as fluid as a snapshot.

Yeah, good point. Loading the nksr will cause the usual compilation process I guess.

…but the patch cable routings of a blocks ensemble or rack don't get stored in a snapshot, and they are as important as the knob positions.

You can save a bunch of snapshots for a Blocks ensemble, then as it develops, change some of the patch connections around. Now when you load those old snapshots, they can be partly or completely messed up, because their settings are for an earlier version of that patch.

If i build i always work in standalone and when i bring it in a DAW it's for playing with the presets already done but i get that not everybody does that,you sometimes want to edit stuff in the DAW.

When I'm playing around with Blocks, the creative process is all about patching, which includes choosing Blocks to use. I don't use DAWs much, but I can see the value in .nksr for the Blocks use case.

TonvaterJan

Okay thanks a lot for the comments, they help a bit, I guess.

So, in Ensemble Mode, there is no way to use Coloured Cables or even hide them - but there are SnapShots

and the DAW-File is more in danger of getting corrupted by the Ensemble itself.

colB

https://community.native-instruments.com/discussion/comment/185419#Comment_185419

there is no way to use Coloured Cables or even hide them

In ensemble mode, the cables are all white, but you can still hide them.

and the DAW-File is more in danger of getting corrupted by the Ensemble itself.

A DAW file is not going to get corrupted by an Ensemble. It's just a workflow that is slightly more prone to operator error.

TonvaterJan

One question regarding Snapshots in Ensembles:

Yesterday I saved a Blocks-Patch as an Ensemble and saved some Snapshots with it.

Today, I´m working on a different Blocks-Patch and learned that yesterday´s Snapshotsare showing up in this new Patch as well - they are not embedded in the Ensemble I created, but seem to be stored in the User content-Folder as general User Snapshots…

What am I doing wrong?

Is this a question of wrong preferences?

Sunborn

https://community.native-instruments.com/discussion/comment/185474#Comment_185474

This is normal behavior. User made snapshots are saved in the user area.

The only way to embed it in the ensemble, is to re-import it in an empty snapshot (or a new bank, if you have many user snapshots) and then save the ensemble. However, again, the ensemble will be saved in the user content folder, unless if you browse to the original ensemble folder and save it there, replacing the original.

This is a bad idea (especially for factory ensembles) unless you're an expert and you know exactly what you are doing. Yet, nothing "wrong" will be happened really, you will only loose the original ensemble. So, re-saving the ensemble in the user area is the best choice. Of course, you will have to remember to use the modified ensemble if you want your snapshots, not the original.

colB

https://community.native-instruments.com/discussion/comment/185474#Comment_185474

Make sure you are saving your snapshots as 'embedded', not 'user' snapshots.

click on embedded with the camera icon, before saving the snapshot.

Then 'save as' the ensemble to make a copy that includes your new embedded snapshot(s)

gentleclockdivider

I almost never save as rack file or nksr

When migrating all your stuff to a new pc ,you need to have the chunk that points to the rack file
My way of working for years is , always save the ensemble with included snapshots ( you could save snapshotfiles independently when you need to
Name the track and make a note of the snapshot ( preset ) , now when migrating to a new pc all your data is stored in the ensemble file
Coloured cables for ens.blocks would be nice , asked for it years ago ..never happened and probably never will

Quick links

Unanswered questions