ensembles and snapshots in a host

With most vsti's, I typically open an instance in a host project (Cubase in my case) and make edits to the various params specific to the song. If I think that set of settings might be usable elsewhere, I'll save an fxp file, but otherwise I just save the song and it saves the instrument's "state" with it so my changes are there next time I open it.

How does Reaktor work with this paradigm? There is a fundamental difference in that the edits in Reaktor could be the the loaded ensemble *or* to the ensemble's parameters (the snapshot).

I'd like to be able to save *all* edits (both ensemble and snapshot settings), and be sure not to screw up the source ensemble I may have originally loaded. Does all this happen for me as part of the Cubase project save? Or do I have to hand-save out an ensemble? Do I have to create a new snapshot in that ensemble as well to contain my parameter changes?

Thanks...

-glenn

 

What you want to do is, for each ensemble, create your own user version of the ensemble which will be stored in your user folder instead of the factory folder.

Then this is the version of the ensemble you really use a lot. It has all your snapshots that you add and save over time.

Then you always load the user version of the ensemble. Because if you load the factory version again, it will not have your snapshots, and when you change it around and add snapshots and then save it to your user folder, it will overwrite the ensemble you have been working with.

Its a little bit complicated, but this is basically how to do it. To create new snapshots, usually just use the "append" button, and name the snapshot whatever you want, and then you save the ensemble. This saves all of your new snapshots. Remember to load from your user folder from now on, and don't overwrite it with the factory version of the ensemble or you will lose all of the previous snapshots you had added!

You can also export snapshots to keep them in a folder.

I recently just got this sorted out myself, I had multiple versions of ensembles saved, several Carbon 2 and 2 Osc ensembles in my user folder, but you only need one.

Now, if you are modifying ensemble structures, not just snapshots, that is another story, then, each ensemble obviously gets saved to the user folder, just be careful to give them all different names so as not to overwrite them.

 

I typically have a master '_AUTOSAVE' folder in same folder/drive as my projects/library. Reaktor remembers this folder once I use it so every project I initiate the autosave settings with a unique ensemble name (my own 'code system attached to original name). My '_AUTOSAVE' folder never changes location and it gets saved with each of my full projects ((which is Logic and updates the ensemble everytime I save the Logic session). So I always know where my 'song' versions of ensembles are. YMMV ;-) Or you could do the same, just using your current project folder, I use a master song folder (my '_AUTOSAVE') so I can identify and reuse particular versions as follow-ups to projects.

 

Okay, just to be sure I'm understanding... with most vstis, the host saves the vsti state as part of the project... there is no need to save anything external at all unless you want to use those changes in another project as well.

But it sounds like with Reaktor, you *do* have to have an external save location somewhere? If I open up an ensemble and tweak it, this state change is not saved as part of the host (cubase in my case) project?

And snapshots? What if I don't need to save a snapshot instance, but I do want the "front panel" tweaks I've made to be saved as part of the project... does that work, or will I need to do the "append" thing and save the ensemble with the new snapshot as a separate thing?

Thanks...

 

There seems to be a little confusion here. I'm not sure what you mean by front panel tweak.

So let's separate the structure change from the parameter change.

If you change a front panel component (placement or style of knob/switch/etc.) - that's a change to the Reaktor ensemble and it has to be saved somewhere if you want to use it again.

Such changes might not affect the sound at all, so presets (or snapshots as it's called in Reaktor) are not involved.

You can save your snapshots (sounds or sound effects) as a separate file and also with (inside) the ensemble file.

When you load an ensemble into a DAW, you have the OPTION of creating a copy of the ensemble to a location of your choosing. You don't need to do this, but if you do it Reaktor will make a copy and a backup (if set up that way) of every change you make to the ensemble. Since snapshot changes also change the ensemble, they are also captured.

Don't forget that Reaktor allows you to use single instruments, or combine several instruments into a 'sort-of' rack. So you could have a totally unique Reaktor tool for every project, customized to that project, and yet made up of multiple separate ensembles.

Another advantage to saving the ensemble is that if your project is older, you save the version of the ensemble that goes with the time period of that project.

 

It's Total-Recall what you mean. ..I think.

Reaktor has it, too.
But not every Ensemble...i believe.
E.g. I tweak a snapshot in Limelite or a recordable XY-pad and then save the DAW-project. All works like i saved it after reloading.
Be 100% sure with saving the snapshot and the ensemble.

Maybe someone can make that more clear.

 

Okay, I *think* that's what I'm looking for. Parameter *and* structure changes come back. I'm basically trying to avoid the all-too-common situation where I answer some dialog box along the way in a way that I don't quite understand, and in the end that causes something somewhere to over-write an ensemble that I didn't want overwritten.

 

Well if you do overwrite Reaktor will warn you and you can enable backup copies.

 

Make a back-up from the original library+U/L downloads. When ever an ensemble feels mocked up, just replace it.
But keep the snapshots, if it is used in a project, or the host (and you) will start whining big-time.