Table of Content
Core Object Settings
The “Core Object Settings” window is used to control core object transitions and target states. Any core object can be added here optionally, but instances with active set groups for the slot are automatically added.
You can specify which processing state the core object should transition to during the slot load, and if that transition should involve ramping or an instant change.
Core Object Settings includes following processing states:
- Normal Processing state
- Bypass without processing
- Mute with processing
- Mute without processing
You can change Ramping state for each instance in a core using drop down option. There are three type of ramping state you can configure.
- Ramping
- No Ramping
- Swoosh Mode
By default, Ramping is enabled for all instances if not configured.
No Ramping
– There is no rampdown to mute phase before applying preset data (but calc is momentarily disabled during the actual load to protect data).
– There is no ramping between processing state changes.
Swoosh Mode: This mode describes as a seamless preset application, which means in this case no fade-out, mute and fade-in steps are performed. The preset(s) are loaded onto the core objects while calc is running, with a request to tune XTP to attempt ramping.
This mode should be used very carefully, as not all audio objects support ramping during runtime tuning, and not all tunings are guaranteed to be applied without artifacts (audible and/or measurable).
The swoosh mode is stored in the slot map on a per core object basis, meaning that in general the user could apply one preset to an xAF instance in a swooshed manner and another in the normal fade out, mute, fade in manner. This only makes sense if the core objects are running independently, otherwise it could interfere with the swoosh effect in an unexpected and unwanted way. Note: It is possible to select processing states in swoosh mode, but they will not be applied.
Things to know about Ramp state configuration window and how objects transitions will function.
- The ramp time used is configured in the slot, it overrides default core object ramp times.
- Automatically added core objects (instances with active set groups) cannot be deleted from the list.
- You can also manually add and remove other core instances and objects.
If performing control set custom actions or other non preset object tuning – you may end up with multiple ramps (once from core object and once from AO tuning) multiplying against each other.
– When loading a preset though – the tuning method is called with ramping disabled so the object should not ramp.
- Ramp Setting for instances, which load presets function differently than ramp settings for core object switches or instances which do not load presets.
- With Ramping on:
- Core objects and Instances which do not load will use only one ramp if possible.
- example: going from normal to mute we do not need to ramp back up after the mute.
- example: going from normal to bypass we have to ramp down to mute and then up to bypass.
- Instances that load presets will always go to mute for loading the preset and then transition to whatever proper state after.
- Core objects and Instances which do not load will use only one ramp if possible.
- With Ramping off:
- During the ‘muted’ phase which occurs after any rampdowns are finished (if there are indeed rampdowns in the slot) all non-ramping core objects (whether loading presets or not) will instantly switch state to the target state.
- With Ramping on:
Instances which load presets are disabled during the load even if they are unmuted.
The user interface will remain unchanged for Ramp state configuration for audio library versions (S+2).
