This forum is now locked and moved (back) to Plogue's forum
ARIA's Custom opcodes
  • davidvdavidv
    Posts: 453
    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.


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

    <master> (ARIA Specific)

    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>: Default value for switch (Dimension apparently supports that)

    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 defines a curve ID

    Higher definition CCs (IEEE floats, [0.f:1.f] range (typically)
    <control> set_hdccX=3.1416 //set_realcc is a deprecated alias
    to affect CC values into the internal real number representation.
    NOTE: any curve used with an HDCC will of course be linear interpolated.

    Similarly to start a <region> with more precision:

    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" (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

    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.

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

    <midi> section

    Was added for MIDI pre-processor effects. In Aria 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 ids in another 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

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!