ARIA's Custom opcodes

Discussion on the SFZ implementation and opcodes available in the ARIA engine.

Moderators: eric_telemaque, davidv

davidv
Site Admin
Posts: 1567
Joined: Tue Mar 02, 2004 7:23 pm
Contact:

ARIA's Custom opcodes

Postby davidv » Mon Aug 24, 2009 1:41 pm

These are some short descriptions of currently ARIA-specific opcodes.

All of those reside in WIKI form elsewhere, but the wiki is not ready for the public yet, so please excuse the seemingly out of order nature of this list.

<master>

We've added a <master> section, which is logically placed between <global> and <group>
So the order of opcode defaults now follow this hierarchy:

<global>
<master> (ARIA Specific)
<group>
<region>

Keyswitches additions:
* sw_label=<text>: Label for activated keyswitch on GUI
* sw_lolast=<key>: Define keyswitch range minimum
* sw_hilast=<key>: Define keyswitch range maximum
* sw_default=<key>: Define keyswitch 'power on default' so that you hear something when a patch loads.

NOTE: sw_last=<key> (SFZ 2.0) puts both sw_lolast and sw_hilast to the value specified in <key>.


Within <curve>:
* curve_index=<ID>: Explicitly defined a curve ID

{target}_curvecc special addition (ARIA 1081+)
{target}_icurvecc has been added to specify whether or not interpolation should be done if source CC value is between points,
Example if CC2=63.5 (MIDI in aria is HDMIDI-esque)


Voice stealing behavior addons
to allow more flexibility in voice killing time, especially for legato action:
* off_mode=fast: Default decay model for voice-stealing (~6ms)
* off_mode=time: To explicitly specify by time
* off_time=<sec>: Release time for voice stealing
* off_shape=<shape-coef>: curvature coefficient
* off_curve=<curveID>: curvature type (usually 10 - ARIA specific)

Panning laws:
* pan_law=<no_law|balance|MMA>: (no_law is deprecated in ARIA 1080+ and maps to balance instead)

Amplitude:
"amplitude" (in linear percent) complements the "volume" opcode (in dB).
(you can use either/or) SFZ 2.0 already has "amplitude" as an EG destination, but not as a normal <region> field,
so we felt it was a logical addition.

* amplitude: //<region> linear gain stage
* group_amplitude: //<group> linear gain stage
* master_amplitude://<master> linear gain stage
* global_amplitude: //<global> linear gain stage
* amplitude_onccX:
* amplitude_smoothccX:
* amplitude_curveccX:

Similarly with the volume opcode:
* volume: //<region> dB volume stage
* group_volume: //<group> dB volume stage
* master_volume: //<master> dB volume stage
* global_volume: //<global> dB volume stage

volume_oncc:
this is just an alias on gain_cc/gain_oncc, in ARIA all three are parsed towards the same construct.

Curvature of SFZ 2.0 Envelopes: (egXX_curve=Y)

ARIA uses curve style "10" which gives plenty of room for Cakewalk's future curves
(they are currently using 0 and 1 with unpublished maths, so we couldn't reproduce them easily)
The shape coefficient then follow the following behavior:

egXX_shape=0 (linear).
Positive values are convex or "slow".
Negative values are concave or "fast".
Upon approaching -10 or 10, increased values make little difference,
as at that point its practically a vertical line.


Addition to SFZ 1.0 level envelopes (ampeg, fileg, pitcheg)

ampeg_attack_shape=<shape-coef>: Attack by shape
ampeg_decay_shape=<shape-coef>: Decay by shape
ampeg_release_shape=<shape-coef>: Release by shape

Q: Why not use egXX_curve and egXX_shape since they have it?
A: Simple, DAHDSR behaves differently!
(decay is specified zeroed or not, sustain=0 kills the whole voice, etc)

ampeg_decay_zero=<bool>: When true/on/1 (SFZ/DLS default), indicates decay time is the time it would take to get from 0dBs to -oo, NOT the time to reach current sustain (as when false/off/0).
ampeg_release_zero=<bool>: Similar theory.

ampeg_decay_zero was added to allow the support of the different definitions of decay time across sampler platforms.

Q: Why dont you pre-calculate decay time according to the known sustain level of the patch and
only use the SFZ definition?
A: ampeg_sustain_oncc can make sustain level dynamic

$DEFINES macros

We've extended Rene's concept of $DEFINES macros with the idea of project OR bank-level defined macros... whereas Rene's macros had to be defined in the SFZ file itself.
This allows us to use the same SFZ files for multiple instruments in a bank, with each instance having different values being injected though the macros. However use of $ macros in a SFZ file does not work outside of the context of its BANK.


<control> addons

ARIA supports specific opcodes in <control> which start with "hint",
these should be ignored by any other SFZ parser. its a "hint" to the engine, others implementations don't have to follow. Other engines could implement other hints as they wished.

<control>
sw_octave_offset
sw_note_offset which follow the same logic as SFZ 2.0's note_offset
but this time for key switches

set_realcc: to affect CC values into the internal real number representation. eg set_realcc2000=3.14159265

<midi> section

Was added for MIDI pre-processor effects. In Aria 1.0.8.0+ you can alternatively use an <effect> section with bus=midi (which would mean be the same thing)

<effect> addon

param_offset: allows to relocate the effect's parameter number in its used context (especially useful for UIs)

vendor_specific : string of characters that should only be interpreted by the target effect module. Parsers beware.

lfoXX_wave addon
lfo07_wave=-1 //Random values
David Viens,
Plogue Art et Technologie Inc. Montreal.
http://www.plogue.com

Return to “SFZ Programming”

Who is online

Users browsing this forum: No registered users and 2 guests