[RWP] My Podcast and a samplomatic question

[Chris Belle]

I don't think it has level 2 opcodes, it's been around for a while.

It's a good tool, I like it for importing sound fonts, and it actually 
get's the high-hat off_by opcodes right for opening and closing high-hats.

I use a couple of vb scripts for importing large amounts of samples, and 
then go in and hand edit.

When you learn to put samples  in groups, it becomes a lot easier to 
control things in bunches.


On 10/28/2014 8:44 PM, Ken Downey wrote:
> I found a great sfz editor called sf zed. Totally accessible so far, 
> though it's still easier just to edit old files in text editors than 
> in sf zed, this program's great for building new sfz files from 
> scratch, and it may have the level 2 opp codes. You have to have 
> Cakewalk's sfz player to audition the font, but I'm not sure where to 
> find that anymore.
> ----- Original Message ----- From: "Chris Belle" <cb1963 at sbcglobal.net>
> To: "Reapers Without Peepers" <rwp at reaaccess.com>
> Sent: Tuesday, October 28, 2014 12:43 PM
> Subject: Re: [RWP] My Podcast and a samplomatic question
>
>
> Looking for those my self.
>
> YOu guys go buy that cakewalk book and scan it for us 'grin'.
>
>
> On 10/27/2014 4:56 PM, Ken Downey wrote:
>> Could I please get the level 2 codes as well? I can't seem to find 
>> them on the net, just a bunch of basic tutorials on how to start 
>> working with sfz files, but no level 2 opcodes. Thanks again for all 
>> this! I'm going to have quite a full load for the students.
>> ----- Original Message ----- From: "Chris Belle" <cb1963 at sbcglobal.net>
>> To: "Reapers Without Peepers" <rwp at reaaccess.com>
>> Sent: Monday, October 27, 2014 5:41 AM
>> Subject: Re: [RWP] My Podcast and a samplomatic question
>>
>>
>> Ken, there is nothing better than the sfz format to build sample
>> libraries for us.
>>
>> Of late my favorite sfz player is sforzando.
>>
>> Learn a few opcodes, and you'll be in sample hog heaven, sfz supports
>> round robin, sequencial positioning, key-switching triggers, filters,
>> bout anything you could want, unlimited zones and regions,
>> it's all done with a text file and wavs or flac or ogg files at any
>> sample rate or bit depth.
>>
>> I've been making my own sfz instruments for years,
>> I use sound forge to do the trimming and such, any old wav editor 
>> will do,
>> but the forge is nice to do looping samples and such, I don't bother
>> looping things much anymore because why bother when we have such big
>> memory and natural decay and envelopes sound so much better,
>> even from hardware synths now adays I just take the natural decay.
>>
>> Sforzando also can parse sf2 files, but the old sfz is better for
>> playing multi-tembral fonts if you need that.
>>
>> But sforzando supports level one and 2 sfz
>> and also plogue specific opcodes, and just to get you started here is
>> the manual for level one opcodes, this will keep you busy for a while.
>>
>> The sfz Format: Basics
>> What is the sfz format?
>> The sfz format is a file format to define how a collection of samples
>> are arragned
>> for performance.
>> The goal behind the sfz format is to provide a free, simple,
>> minimalistic and expandable
>> format to arrange, distribute and use audio samples with the highest
>> possible quality and the highest possible performance flexibility.
>> A sfz format file can be played in our freeware sfz player.
>> Soundware, software and hardware developers can create, use and
>> distribute the sfz
>> format files for free, for either free or commercial applications.
>> Some of the features of the sfz format are:
>> Liste de 15 éléments
>> • Samples of any bit depth (8/16/24/32-bit) support, mono or stereo
>> • Samples taken at any samplerate (i.e. 44.1k, 48k, 88.2k, 96k, 176.4k,
>> 192k, 384k)
>> • Compressed samples. Compressed and uncompressed can be combined
>> • Looped samples
>> • Unlimited keyboard splits and layers
>> • Unlimited velocity splits and layers
>> • Unlimited regions of sample playback based on MIDI controllers
>> (continuous controllers,
>> pitch bend, channel and polyphonic aftertouch, keyboard switches)
>> and internal generators (random, sequence counters)
>> • Sample playback on MIDI control events
>> • Unlimited unidirectional and bidirectional exclusive regions (mute 
>> groups)
>> • Unlimited release trigger regions with release trigger attenuation 
>> control
>> • Unlimited crossfade controls
>> • Trigger on first-note and legato notes
>> • Sample playback synchronized to host tempo
>> • Dedicated Envelope Generators for pitch, filter and amplifier
>> • Dedicated LFO for pitch, filter and amplifier
>> Fin de la liste
>> How is the sfz format structured?
>> The sfz format is a collection of sample files plus one or multiple .sfz
>> definition
>> files. This structure, containing multiple files instead of a single
>> file is defined as non-monolithic.
>> Two kinds of sample files were selected to be included in the sfz
>> format: a basic
>> PCM uncompressed format (standard Windows wave files) and a basic,
>> adjustable-quality,
>> royalty free compressed format (ogg-vorbis encoded files).
>> The inclusion of a compressed format allows sample developers and
>> soundware creators
>> to easily create preview or demonstration files in a small package
>> so they can be transferred with minimum bandwidth, while retaining
>> complete performance
>> functionality.
>> Both formats are 100% royalty-free, so players can be created to
>> reproduce them without
>> fixed or per-copy fees. They can also be freely distributed on the
>> web (provided that the contents of the files are copyright cleared).
>> Each .sfz definition file represents one or a collection of instruments.
>> An instrument
>> is defined as a collection of regions. Regions include the definition
>> for the input controls, the samples (the wav/ogg files) and the
>> performance parameters
>> to play those samples.
>> How is the .sfz definition file created?
>> A .sfz definition file is just a text file. Consequently, it can be
>> created by using
>> any text editor (i.e. Notepad).
>> Why non-monolithic?
>> While both monolithic and non-monolithic formats have advantages and
>> disadvantages,
>> there are several reasons which moved us to adopt a non-monolithic 
>> sample
>> format. Technological and conceptual reasons can hardly be separated, so
>> here's a
>> basic explanation.
>> The most important reason is the file size limitation of a non-monolitic
>> file on
>> FAT32 partitions. Samples are getting really big nowadays, with 
>> thousands
>> of individual samples collected in single instruments, and triggered
>> according to
>> many input control combinations.
>> Samples with high bit resolution (i.e. 24-bit samples) and high
>> samplerate settings
>> (96kHz, 192kHz) make the collection size even bigger. In the case of
>> a non-monolithic format, the limitation still applies, but it applies to
>> each sample
>> instead of to the sum of all samples, making the limit virtually
>> unreachable.
>> While this limitation doesn't apply to NTFS, NTFS partitions are less
>> efficient than
>> FAT32 disks in terms of raw disk performance for streaming applications.
>> Additionally, editing a single sample in a monolithic file implies
>> loading the whole
>> file, and after edit, saving the whole file again to disk. When 
>> collection
>> size is big, the loading and saving operation is very time-consuming.
>> However, we have not discharged the possibility of incorporating a
>> monolithic format
>> for the sfz format, as soon as the format structure is completely
>> implemented.
>> Small sound sets (or NTFS users) could chose between the two options
>> appropriately.
>> Why not XML?
>> XML was actually the first choice for the .sfz definition file, mainly
>> due the simplicity
>> from the development point of view as the XML parser and transaction
>> code is already available.
>> However, XML was designed to exchange data over the web. Musicians,
>> players, composers,
>> soundware developers and audio technicians generally do not know
>> about XML at all.
>> In addition, as a universal information exchange format designed for
>> general-purpose
>> applications, XML is inefficient (in terms of information over total
>> data terms), and editing a XML file requires the use of a XML editor
>> instead of a
>> text editor.
>> A .sfz file is extremely self-explanatory. Most of the functionality of
>> an instrument
>> can be easily discovered by reading the file.
>> Is there a .sfz dedicated editor?
>> From rgc:audio, not yet... and not anytime soon.
>> However, we're working with several developers in the industry, creators
>> of sample-conversion
>> software to implement the .sfz format in their converters
>> and editors.
>> The nature of the format allows creating instruments using other
>> general-purpose
>> software, like spreadsheets, wordprocessors, simple-scripting languages
>> and other custom tailored software applications.
>> Implementation
>> How is an instrument defined?
>> The basic component of an instrument is a region. An instrument then, is
>> defined
>> by one or more regions. Multiple regions can be arranged in a group. 
>> Groups
>> allow entering common parameters for multiple regions.
>> A region can include three main components: the definition for a sample,
>> a set of
>> input controls and a set of performance parameters.
>> Sample
>> The sample opcode defines which sample file will be played when the
>> region is defined
>> to play.
>> If a sample opcode is not present in the region, the region will play
>> the sample
>> defined in the last <group>. If there's no previous group defined, or
>> if the previous group doesn't specify a sample opcode, the region will
>> be ignored.
>> Input Controls
>> Input controls define when the sample defined in a region will play,
>> based in real-world
>> controller values and/or internally calculated values.
>> Real-world controllers are the elements that players, musicians or
>> composers actually
>> use to play music. Internal values are calculated by the player, like
>> sequence counters and random generators.
>> The sfz format relies in the standard Musical Instruments Digital
>> Interface (MIDI)
>> specification for all input controls. Most available performance 
>> controllers
>> implement MIDI, and it's still the dominating specification for software
>> audio sequencers
>> in all platforms.
>> Keyboard controllers are the most significant example of an Input
>> Controls generator.
>> Other generators could be MIDI guitars and string instruments, wind
>> controllers, drum and percussion controllers. With individual
>> differences, they all
>> generate a common set of messages defined in the MIDI specification.
>> A set of input controls then, are the combination of a played MIDI note
>> with its
>> velocity, continuous controllers, pitch bend, channel and polyphonic
>> aftertouch,
>> etc.
>> When a particular set of input controls matches the definition for a
>> region, the
>> sample specified in that region plays, using a particular set of 
>> performance
>> parameters also specified in the region.
>> Inside the definition file, a region starts with the <region> header. A
>> region is
>> defined between two <region> headers, or between a <region> header and
>> a <group> header, or between a <region> header and the end of the file.
>> Following the <region> header one or more opcodes can be defined. The
>> opcodes are
>> special keywords which instruct the player on what, when and how to play
>> a sample.
>> Opcodes within a region can appear in any order, and they have to be
>> separated by
>> one or more spaces or tabulation controls. Opcodes can appear in 
>> separated
>> lines within a region.
>> Opcodes and assigned opcode values are separated by the equal to sign
>> (=), without
>> spaces between the opcode and the sign. For instance:
>> sample=trombone_a4_ff.wav
>> sample=cello_a5_pp first take.wav
>> are valid examples, while:
>> sample = cello_a4_pp.wav
>> Is not (note the spaces at the sides of the = sign).
>> Input Controls and Performance Parameters opcodes are optional, so they
>> might not
>> be present in the definition file. An 'expectable' default value for
>> each parameter is pre-defined, and will be used if there's no 
>> definition.
>> Example region definitions:
>> <region> sample=440.wav
>> This region definition instructs the player to play the sample file
>> '440.wav' for
>> the whole keyboard range.
>> <region> lokey=64 hikey=67 sample=440.wav
>> This region features a very basic set of input parameters (lokey and
>> hikey, which
>> represent the low and high MIDI notes in the keyboard), and the sample
>> definition.
>> This instructs the player to play the sample '440.wav', if a key in the
>> 64-67 range
>> is played.
>> It is very important to note that all Input Controls defined in a region
>> act using
>> the AND boolean operator. Consequently, all conditions must be matched
>> for the region to play. For instance:
>> <region> lokey=64 hikey=67 lovel=0 hivel=34 locc1=0 hicc1=40 
>> sample=440.wav
>> This region definition instructs the player to play the sample '440.wav'
>> if there
>> is an incoming note event in the 64-67 range AND the note has a velocity
>> in the 0~34 range AND last modulation wheel (cc1) message was in the
>> 0~40 range.
>> Performance parameters
>> The Performance Parameters define how the sample specified will play,
>> once the region
>> is defined to play.
>> A simple example of a Performance Parameter is volume. It defines how
>> loud the sample
>> will be played when the region plays.
>> Groups
>> As previously stated, groups allow entering common parameters for
>> multiple regions.
>> A group is defined with the <group> opcode, and the parameters 
>> enumerated
>> on it last till the next group opcode, or till the end of the file.
>> <group>
>> ampeg_attack=0.04 ampeg_release=0.45
>> <region> sample=trumpet_pp_c4.wav key=c4
>> <region> sample=trumpet_pp_c#4.wav key=c#4
>> <region> sample=trumpet_pp_d4.wav key=d4
>> <region> sample=trumpet_pp_d#4.wav key=d#4
>> <group>
>> <region> sample=trumpet_pp_e4.wav key=e4 // previous group parameters 
>> reset
>> Comments
>> Comment lines can be inserted anywhere inside the file. A comment line
>> starts with
>> the slash character ('/'), and it extends till the end of the line.
>> <region>
>> sample=trumpet_pp_c4.wav
>> // middle C in the keyboard
>> lokey=60
>> // pianissimo layer
>> lovel=0 hivel=20 // another comment
>> Where do the sample files have to be stored?
>> Sample files can be stored either in the same folder where the .sfz
>> definition file
>> resides, or in any alternative route, specified relatively to the 
>> location
>> of the definition file. Consequently:
>> sample=trumpet_pp_c3.wav
>> sample=samples\trumpet_pp_c3.wav
>> sample=..\trumpet_pp_c3.wav
>> Are all valid sample names.
>> Alternatively, the player might specify one or several 'user folders',
>> where it will
>> search for samples if it doesn't find them in the same folder as the
>> definition file.
>> What can the sfz format do?
>> The sfz format is aimed to allow the arrange of a sample collection in a
>> flexible
>> and expandable way. It's up to the player to decide which functionality
>> it wants to implement.
>> Units
>> All units in the sfz format are in real-world values. Frequencies are
>> expressed in
>> Hertz, pitches in cents, amplitudes in percentage and volumes in 
>> decibels.
>> Notes are expressed in MIDI Note Numbers, or in note names according to
>> the International
>> Pitch Notation (IPN) convention. According to this rules, middle
>> C in the keyboard is C4 and the MIDI note number 60.
>> Opcode List
>> The following is a description of all valid opcodes for the sfz format
>> version 1.0:
>> Tableau: 5 colonnes et 181 lignes
>> Opcode
>> Description
>> Type
>> Default
>> Range
>> Sample Definition
>> sample
>> This opcode defines which sample file the region will play.
>> The value of this opcode is the filename of the sample file, including
>> the extension.
>> The filename must be stored in the same folder where the definition
>> file is, or specified relatively to it.
>> If the sample file is not found, the player will ignore the whole region
>> contents.
>> Long names and names with blank spaces and other special characters
>> (excepting the
>> = character) are allowed in the sample definition.
>> The sample will play unchanged when a note equal to the pitch_keycenter
>> opcode value
>> is played. If pitch_keycenter is not defined for the region, sample
>> will play unchanged on note 60 (middle C).
>> Examples:
>> sample=guitar_c4_ff.wav
>> sample=dog kick.ogg
>> sample=out of tune trombone (redundant).wav
>> sample=staccatto_snare.ogg
>> string
>> (filename)
>> n/a
>> n/a
>> Input Controls
>> lochan
>> hichan
>> If incoming notes have a MIDI channel between lochan and hichan, the
>> region will
>> play.
>> Examples:
>> lochan=1 hichan=5
>> integer
>> lochan=1
>> hichan=16
>> 1 to 16
>> lokey
>> hikey
>> key
>> If a note equal to or higher than lokey AND equal to or lower than hikey
>> is played,
>> the region will play.
>> lokey and hikey can be entered in either MIDI note numbers (0 to 127) or
>> in MIDI
>> note names (C-1 to G9)
>> The key opcode sets lokey, hikey and pitch_keycenter to the same note.
>> Examples:
>> lokey=60 // middle C
>> hikey=63 // middle D#
>> lokey=c4 // middle C
>> hikey=d#4 // middle D#
>> hikey=eb4 // middle Eb (D#)
>> integer
>> lokey=0, hikey=127
>> 0 to 127
>> C-1 to G9
>> lovel
>> hivel
>> If a note with velocity value equal to or higher than lovel AND equal to
>> or lower
>> than hivel is played, the region will play.
>> integer
>> locc=0, hicc=127
>> for all controllers
>> 0 to 127
>> lobend
>> hibend
>> Defines the range of the last Pitch Bend message required for the region
>> to play.
>> Examples:
>> lobend=0 hibend=4000
>> The region will play only if last Pitch Bend message received was in the
>> 0~4000 range.
>> integer
>> lobend=-8192,
>> hibend=8192
>> -8192 to 8192
>> lochanaft
>> hichanaft
>> Defines the range of last Channel Aftertouch message required for the
>> region to play.
>> Examples:
>> lochanaft=30 hichanaft=100
>> The region will play only if last Channel Aftertouch message received
>> was in the
>> 30~100 range.
>> integer
>> lochanaft=0, hichanaft=127
>> 0 to 127
>> lopolyaft
>> hipolyaft
>> Defines the range of last Polyphonic Aftertouch message required for the
>> region to
>> play.
>> The incoming note information in the Polyphonic Aftertouch message is
>> not relevant.
>> Examples:
>> lopolyaft=30 hipolyaft=100
>> The region will play only if last Polyphonic Aftertouch message received
>> was in the
>> 30~100 range.
>> integer
>> lopolyaft=0, hipolyaft=127
>> 0 to 127
>> lorand
>> hirand
>> Random values. The player will generate a new random number on every
>> note-on event,
>> in the range 0~1.
>> The region will play if the random number is equal to or higher than
>> lorand, and
>> lower than hirand.
>> Examples:
>> lorand=0.2 hirand=0.4
>> lorand=0.4 hirand=1
>> floating point
>> lorand = 0
>> hirand = 1
>> 0 to 1
>> lobpm
>> hibpm
>> Host tempo value. The region will play if the host tempo is equal to or
>> higher than
>> lobpm, and lower than hibpm.
>> Examples:
>> lobpm=0 hibpm=100
>> lobpm=100 hibpm=200.5
>> floating point
>> lobpm = 0
>> hibpm = 500
>> 0 to 500 bpm
>> seq_length
>> Sequence length. The player will keep an internal counter creating a
>> consecutive
>> note-on sequence for each region, starting at 1 and resetting at 
>> seq_length.
>> Examples:
>> seq_length=3
>> integer
>> 1
>> 1 to 100
>> seq_position
>> Sequence position. The region will play if the internal sequence counter
>> is equal
>> to seq_position.
>> Examples:
>> seq_length=4 seq_position=2
>> In above example, the region will play on the second note every four 
>> notes.
>> integer
>> 1
>> 1 to 100
>> sw_lokey
>> sw_hikey
>> Defines the range of the keyboard to be used as trigger selectors for
>> the sw_last
>> opcode.
>> sw_lokey and sw_hikey can be entered in either MIDI note numbers (0 to
>> 127) or in
>> MIDI note names (C-1 to G9)
>> Examples:
>> sw_lokey=48 sw_hikey=53
>> integer
>> sw_lokey=0, sw_hikey=127
>> 0 to 127
>> C-1 to G9
>> sw_last
>> Enables the region to play if the last key pressed in the range
>> specified by sw_lokey
>> and sw_hikey is equal to the sw_last value.
>> sw_last can be entered in either MIDI note numbers (0 to 127) or in MIDI
>> note names
>> (C-1 to G9)
>> Examples:
>> sw_last=49
>> integer
>> 0
>> 0 to 127
>> C-1 to G9
>> sw_down
>> Enables the region to play if the key equal to sw_down value is 
>> depressed.
>> Key has to be in the range specified by sw_lokey and sw_hikey.
>> sw_down can be entered in either MIDI note numbers (0 to 127) or in MIDI
>> note names
>> (C-1 to G9)
>> Examples:
>> sw_down=Cb3
>> integer
>> 0
>> 0 to 127
>> C-1 to G9
>> sw_up
>> Enables the region to play if the key equal to sw_up value is not 
>> depressed.
>> Key has to be in the range specified by sw_lokey and sw_hikey.
>> sw_up can be entered in either MIDI note numbers (0 to 127) or in MIDI
>> note names
>> (C-1 to G9)
>> Examples:
>> sw_up=49
>> integer
>> 0
>> 0 to 127
>> C-1 to G9
>> sw_previous
>> Previous note value. The region will play if last note-on message was
>> equal to sw_previous
>> value.
>> sw_previous can be entered in either MIDI note numbers (0 to 127) or in
>> MIDI note
>> names (C-1 to G9)
>> Examples:
>> sw_previous=60
>> integer
>> none
>> 0 to 127
>> C-1 to G9
>> sw_vel
>> This opcode allows overriding the velocity for the region with the
>> velocity of the
>> previous note. Values can be:
>> current: Region uses the velocity of current note.
>> previous: Region uses the velocity of the previous note.
>> Examples:
>> sw_vel=previous
>> text
>> current
>> current, previous
>> trigger
>> Sets the trigger which will be used for the sample to play. Values 
>> can be:
>> attack (default): Region will play on note-on.
>> release: Region will play on note-off. The velocity used to play the
>> note-off sample
>> is the velocity value of the corresponding (previous) note-on message.
>> first: Region will play on note-on, but if there's no other note going
>> on (staccato,
>> or first note in a legato phrase).
>> legato: Region will play on note-on, but only if there's a note going on
>> (notes after
>> first note in a legato phrase).
>> Examples:
>> trigger=release
>> integer
>> attack
>> attack,
>> release, first, legato
>> group
>> Exclusive group number for this region.
>> Examples:
>> group=3
>> group=334
>> integer
>> 0
>> 0 to 4Gb (4294967296)
>> off_by
>> Region off group. When a new region with a group number equal to off_by
>> plays, this
>> region will be turned off.
>> Examples:
>> off_by=3
>> off_by=334
>> integer
>> 0
>> 0 to 4Gb (4294967296)
>> off_mode
>> Region off mode. This opcode will determinate how a region is turned off
>> by an off_by
>> opcode. Values can be:
>> fast (default): The voice will be turned off immediately. Release
>> settings will not
>> have any effect.
>> normal: The region will be set into release stage. All envelope
>> generators will enter
>> in release stage, and region will expire when the amplifier envelope
>> generator expired.
>> Examples:
>> off_mode=fast
>> off_mode=normal
>> text
>> fast
>> fast, normal
>> on_loccN
>> on_hiccN
>> Sample trigger on MIDI continuous control N. If a MIDI control message
>> with a value
>> between on_loccN and on_hiccN is received, the region will play.
>> Examples:
>> on_locc1=0 on_hicc1=0
>> Region will play when a MIDI CC1 (modulation wheel) message with zero
>> value is received.
>> integer
>> -1 (unassigned)
>> 0 to 127
>> Performance Parameters
>> Sample Player
>> delay
>> Region delay time, in seconds.
>> If a delay value is specified, the region playback will be postponed for
>> the specified
>> time.
>> If the region receives a note-off message before delay time, the region
>> won't play.
>> All envelope generators delay stage will start counting after region
>> delay time.
>> Examples:
>> delay=1
>> delay=0.2
>> floating point
>> 0
>> 0 to 100 seconds
>> delay_random
>> Region random delay time, in seconds.
>> If the region receives a note-off message before delay time, the region
>> won't play.
>> Examples:
>> delay_random=1
>> delay_random=0.2
>> floating point
>> 0
>> 0 to 100 seconds
>> delay_ccN
>> Region delay time after MIDI continuous controller N messages are
>> received, in seconds.
>> If the region receives a note-off message before delay time, the region
>> won't play.
>> Examples:
>> delay_cc1=1
>> delay_cc2=.5
>> floating point
>> 0
>> 0 to 100 seconds
>> offset
>> The offset used to play the sample, in sample units.
>> The player will reproduce samples starting with the very first sample in
>> the file,
>> unless offset is specified. It will start playing the file at the offset
>> sample in this case.
>> Examples:
>> offset=3000
>> offset=32425
>> integer
>> 0
>> 0 to 4 Gb (4294967296)
>> offset_random
>> Random offset added to the region offset, in sample units.
>> Examples:
>> offset_random=300
>> offset_random=100
>> integer
>> 0
>> 0 to 4 Gb (4294967296)
>> offset_ccN
>> The offset used to play the sample according to last position of MIDI
>> continuous
>> controller N, in sample units.
>> This opcode is useful to specify an alternate sample start point based
>> on MIDI controllers.
>> Examples:
>> offset_cc1=3000
>> offset_cc64=1388
>> integer
>> 0
>> 0 to 4 Gb (4294967296)
>> end
>> The endpoint of the sample, in sample units.
>> The player will reproduce the whole sample if end is not specified.
>> If end value is -1, the sample will not play. Marking a region end with
>> -1 can be
>> used to use a silent region to turn off other regions by using the group
>> and off_by opcodes.
>> Examples:
>> end=133000
>> end=4432425
>> integer
>> 0
>> -1 to 4 Gb (4294967296)
>> count
>> The number of times the sample will be played. If this opcode is
>> specified, the sample
>> will restart as many times as defined. Envelope generators will not
>> be retriggered on sample restart.
>> When this opcode is defined, loopmode is automatically set to one_shot.
>> Examples:
>> count=3
>> count=2
>> integer
>> 0
>> 0 to 4 Gb (4294967296)
>> loop_mode
>> If loop_mode is not specified, each sample will play according to its
>> predefined
>> loop mode. That is, the player will play the sample looped using the 
>> first
>> defined loop, if available. If no loops are defined, the wave will play
>> unlooped.
>> The loop_mode opcode allows playing samples with loops defined in the
>> unlooped mode.
>> The possible values are:
>> no_loop: no looping will be performed. Sample will play straight from
>> start to end,
>> or until note off, whatever reaches first.
>> one_shot: sample will play from start to end, ignoring note off.
>> This mode is engaged automatically if the count opcode is defined.
>> loop_continuous: once the player reaches sample loop point, the loop
>> will play until
>> note expiration.
>> loop_sustain: the player will play the loop while the note is held, by
>> keeping it
>> depressed or by using the sustain pedal (CC64). The rest of the sample
>> will play after note release.
>> Examples:
>> loop_mode=no_loop
>> loop_mode=loop_continuous
>> text
>> no_loop for samples without a loop defined,
>> loop_continuous for samples with defined loop(s).
>> n/a
>> loop_start
>> The loop start point, in samples.
>> If loop_start is not specified and the sample has a loop defined, the
>> sample start
>> point will be used.
>> If loop_start is specified, it will overwrite the loop start point
>> defined in the
>> sample.
>> This opcode will not have any effect if loopmode is set to no_loop.
>> Examples:
>> loop_start=4503
>> loop_start=12445
>> integer
>> 0
>> 0 to 4 Gb (4294967296)
>> loop_end
>> The loop end point, in samples. This opcode will not have any effect if
>> loopmode
>> is set to no_loop.
>> If loop_end is not specified and the sample have a loop defined, the
>> sample loop
>> end point will be used.
>> If loop_end is specified, it will overwrite the loop end point defined
>> in the sample.
>> Examples:
>> loop_end=34503
>> loop_end=212445
>> integer
>> 0
>> 0 to 4 Gb (4294967296)
>> sync_beats
>> Region playing synchronization to host position.
>> When sync_beats is specified and after input controls instruct the
>> region to play,
>> the playback will be postponed until the next multiple of the specified
>> value is crossed.
>> Examples:
>> sync_beats=4
>> In this example, if note is pressed in beat 2 of current track, note
>> won't be played
>> until beat 4 reaches.
>> This opcode will only work in hosts featuring song position information
>> (vstTimeInfo
>> ppqPos).
>> floating point
>> 0
>> 0 to 32 beats
>> sync_offset
>> Region playing synchronization to host position offset.
>> When sync_beats is specified and after input controls instruct the
>> region to play,
>> the playback will be postponed until the next multiple of the specified
>> value plus the sync_offset value is crossed.
>> Examples:
>> sync_beats=4 sync_offset=1
>> In this example, if note is pressed in beat 2 of current track, note
>> won't be played
>> until beat 5 reaches.
>> This opcode will only work in hosts featuring song position information
>> (vstTimeInfo
>> ppqPos).
>> floating point
>> 0
>> 0 to 32 beats
>> Pitch
>> transpose
>> The transposition value for this region which will be applied to the 
>> sample.
>> Examples:
>> transpose=3
>> transpose=-4
>> integer
>> 0
>> -127 to 127
>> tune
>> The fine tuning for the sample, in cents. Range is ±1 semitone, from
>> -100 to 100.
>> Only negative values must be prefixed with sign.
>> Examples:
>> tune=33
>> tune=-30
>> tune=94
>> integer
>> 0
>> -100 to 100
>> pitch_keycenter
>> Root key for the sample.
>> Examples:
>> pitch_keycenter=56
>> pitch_keycenter=c#2
>> integer
>> 60 (C4)
>> -127 to 127
>> C-1 to G9
>> pitch_keytrack
>> Within the region, this value defines how much the pitch changes with
>> every note.
>> Default value is 100, which means pitch will change one hundred cents
>> (one semitone) per played note.
>> Setting this value to zero means that all notes in the region will play
>> the same
>> pitch, particularly useful when mapping drum sounds.
>> Examples:
>> pitch_keytrack=20
>> pitch_keytrack=0
>> integer
>> 100
>> -1200 to 1200
>> pitch_veltrack
>> Pitch velocity tracking, represents how much the pitch changes with
>> incoming note
>> velocity, in cents.
>> Examples:
>> pitch_veltrack=0
>> pitch_veltrack=1200
>> integer
>> 0
>> -9600 to 9600 cents
>> pitch_random
>> Random tuning for the region, in cents. Random pitch will be centered,
>> with positive
>> and negative values.
>> Examples:
>> pitch_random=100
>> pitch_random=400
>> integer
>> 0
>> 0 to 9600 cents
>> bend_up
>> Pitch bend range when Bend Wheel or Joystick is moved up, in cents.
>> Examples:
>> bend_up=1200
>> bend_up=100
>> integer
>> 200
>> -9600 to 9600
>> bend_down
>> Pitch bend range when Bend Wheel or Joystick is moved down, in cents.
>> Examples:
>> bend_down=1200
>> bend_down=100
>> integer
>> -200
>> bend_step
>> Pitch bend step, in cents.
>> Examples:
>> bend_step=100 // glissando in semitones
>> bend_step=200 // glissando in whole tones
>> integer
>> 1
>> 1 to 1200
>> Pitch EG
>> pitcheg_delay
>> Pitch EG delay time, in seconds. This is the time elapsed from note on
>> to the start
>> of the Attack stage.
>> Examples:
>> pitcheg_delay=1.5
>> pitcheg_delay=0
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> pitcheg_start
>> Pitch EG start level, in percentage.
>> Examples:
>> pitcheg_start=20
>> pitcheg_start=100
>> floating point
>> 0 %
>> 0 to 100 %
>> pitcheg_attack
>> Pitch EG attack time, in seconds.
>> Examples:
>> pitcheg_attack=1.2
>> pitcheg_attack=0.1
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> pitcheg_hold
>> Pitch EG hold time, in seconds. During the hold stage, EG output will
>> remain at its
>> maximum value.
>> Examples:
>> pitcheg_hold=1.5
>> pitcheg_hold=0.1
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> pitcheg_decay
>> Pitch EG decay time, in seconds.
>> Examples:
>> pitcheg_decay=1.5
>> pitcheg_decay=3
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> pitcheg_sustain
>> Pitch EG release time (after note release), in seconds.
>> Examples:
>> pitcheg_release=1.34
>> pitcheg_release=2
>> floating point
>> 100 %
>> 0 to 100 %
>> pitcheg_release
>> Pitch EG release time (after note release), in seconds.
>> Examples:
>> pitcheg_release=1.34
>> pitcheg_release=2
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> pitcheg_depth
>> Depth for the pitch EG, in cents.
>> Examples:
>> pitcheg_depth=1200
>> pitcheg_depth=-100
>> integer
>> 0
>> -12000 to 12000
>> pitcheg_vel2delay
>> Velocity effect on pitch EG delay time, in seconds.
>> Examples:
>> pitcheg_vel2delay=1.2
>> pitcheg_vel2delay=0.1
>> Delay time will be calculated as
>> delay time = pitcheg_delay + pitcheg_vel2delay * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> pitcheg_vel2attack
>> Velocity effect on pitch EG attack time, in seconds.
>> Examples:
>> pitcheg_vel2attack=1.2
>> pitcheg_vel2attack=0.1
>> Attack time will be calculated as
>> attack time = pitcheg_attack + pitcheg_vel2attack * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> pitcheg_vel2hold
>> Velocity effect on pitch EG hold time, in seconds.
>> Examples:
>> pitcheg_vel2hold=1.2
>> pitcheg_vel2hold=0.1
>> Hold time will be calculated as
>> hold time = pitcheg_hold + pitcheg_vel2hold * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> pitcheg_vel2decay
>> Velocity effect on pitch EG decay time, in seconds.
>> Examples:
>> pitcheg_vel2decay=1.2
>> pitcheg_vel2decay=0.1
>> Decay time will be calculated as
>> decay time = pitcheg_decay + pitcheg_vel2decay * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> pitcheg_vel2sustain
>> Velocity effect on pitch EG sustain level, in percentage.
>> Examples:
>> pitcheg_vel2sustain=30
>> pitcheg_vel2sustain=20
>> Sustain level will be calculated as
>> sustain level = pitcheg_sustain + pitcheg_vel2sustain
>> floating point
>> 0 %
>> -100 % to 100 %
>> pitcheg_vel2release
>> Velocity effect on pitch EG release time, in seconds.
>> Examples:
>> pitcheg_vel2release=1.2
>> pitcheg_vel2release=0.1
>> Release time will be calculated as
>> release time = pitcheg_release + pitcheg_vel2release * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> pitcheg_vel2depth
>> Velocity effect on pitch EG depth, in cents.
>> Examples:
>> pitcheg_vel2depth=100
>> pitcheg_vel2depth=-1200
>> integer
>> 0 cents
>> -12000 to 12000 cents
>> Pitch LFO
>> pitchlfo_delay
>> The time before the Pitch LFO starts oscillating, in seconds.
>> Examples:
>> pitchlfo_delay=1
>> pitchlfo_delay=0.4
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> pitchlfo_fade
>> Pitch LFO fade-in effect time.
>> Examples:
>> pitchlfo_fade=1
>> pitchlfo_fade=0.4
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> pitchlfo_freq
>> Pitch LFO frequency, in hertz.
>> Examples:
>> pitchlfo_freq=0.4
>> pitchlfo_freq=1.3
>> floating point
>> 0 Hertz
>> 0 to 20 hertz
>> pitchlfo_depth
>> Pitch LFO depth, in cents.
>> Examples:
>> pitchlfo_depth=1
>> pitchlfo_depth=4
>> integer
>> 0 cent
>> -1200 to 1200 cents
>> pitchlfo_depthccN
>> Pitch LFO depth when MIDI continuous controller N is received, in cents.
>> Examples:
>> pitchlfo_depthcc1=100
>> pitchlfo_depthcc32=400
>> integer
>> 0 cent
>> -1200 to 1200 cents
>> pitchlfo_depthchanaft
>> Pitch LFO depth when channel aftertouch MIDI messages are received, in
>> cents.
>> Examples:
>> pitchlfo_depthchanaft=100
>> pitchlfo_depthchanaft=400
>> integer
>> 0 cent
>> -1200 to 1200 cents
>> pitchlfo_depthpolyaft
>> Pitch LFO depth when polyphonic aftertouch MIDI messages are received,
>> in cents.
>> Examples:
>> pitchlfo_depthpolyaft=100
>> pitchlfo_depthpolyaft=400
>> integer
>> 0 cent
>> -1200 to 1200 cents
>> pitchlfo_freqccN
>> Pitch LFO frequency change when MIDI continuous controller N is
>> received, in hertz.
>> Examples:
>> pitchlfo_freqcc1=5
>> pitchlfo_freqcc1=-12
>> floating point
>> 0 hertz
>> -200 to 200 hertz
>> pitchlfo_freqchanaft
>> Pitch LFO frequency change when channel aftertouch MIDI messages are
>> received, in
>> hertz.
>> Examples:
>> pitchlfo_freqchanaft=10
>> pitchlfo_freqchanaft=-40
>> floating point
>> 0 hertz
>> -200 to 200 hertz
>> pitchlfo_freqpolyaft
>> Pitch LFO frequency change when polyphonic aftertouch MIDI messages are
>> received,
>> in hertz.
>> Examples:
>> pitchlfo_freqpolyaft=10
>> pitchlfo_freqpolyaft=-4
>> floating point
>> 0 hertz
>> -200 to 200 hertz
>> Filter
>> fil_type
>> Filter type. Avaliable types are:
>> lpf_1p: one-pole low pass filter (6dB/octave).
>> hpf_1p: one-pole high pass filter (6dB/octave).
>> lpf_2p: two-pole low pass filter (12dB/octave).
>> hpf_2p: two-pole high pass filter (12dB/octave).
>> bpf_2p: two-pole band pass filter (12dB/octave).
>> brf_2p: two-pole band rejection filter (12dB/octave).
>> Examples:
>> fil_type=lpf_2p
>> fil_type=hpf_1p
>> text
>> lpf_2p
>> lpf_1p, hpf_1p, lpf_2p, hpf_2p, bpf_2p, brf_2p
>> cutoff
>> The filter cutoff frequency, in Hertz.
>> If the cutoff is not specified, the filter will be disabled, with the
>> consequent
>> CPU drop in the player.
>> Examples:
>> cutoff=343
>> cutoff=4333
>> floating point
>> filter disabled
>> 0 to
>> SampleRate / 2
>> cutoff_ccN
>> The variation in the cutoff frequency when MIDI continuous controller N
>> is received,
>> in cents.
>> Examples:
>> cutoff_cc1=1200
>> cutoff_cc2=-100
>> integer
>> 0
>> -9600 to 9600 cents
>> cutoff_chanaft
>> The variation in the cutoff frequency when MIDI channel aftertouch
>> messages are received,
>> in cents.
>> Examples:
>> cutoff_chanaft=1200
>> cutoff_chanaft=-100
>> integer
>> 0
>> -9600 to 9600 cents
>> cutoff_polyaft
>> The variation in the cutoff frequency when MIDI polyphonic aftertouch
>> messages are
>> received, in cents.
>> Examples:
>> cutoff_polyaft=1200
>> cutoff_polyaft=-100
>> integer
>> 0
>> -9600 to 9600 cents
>> resonance
>> The filter cutoff resonance value, in decibels.
>> Examples:
>> resonance=30
>> floating point
>> 0 dB
>> 0 to 40 dB
>> fil_keytrack
>> Filter keyboard tracking (change on cutoff for each key) in cents.
>> Examples:
>> fil_keytrack=100
>> fil_keytrack=0
>> integer
>> 0 cents
>> 0 to 1200 cents
>> fil_keycenter
>> Center key for filter keyboard tracking. In this key, the filter
>> keyboard tracking
>> will have no effect.
>> Examples:
>> fil_keycenter=60
>> fil_keycenter=48
>> integer
>> 60
>> 0 to 127
>> fil_veltrack
>> Filter velocity tracking, represents how much the cutoff changes with
>> incoming note
>> velocity.
>> Examples:
>> fil_veltrack=0
>> fil_veltrack=1200
>> integer
>> 0
>> -9600 to 9600 cents
>> fil_random
>> Random cutoff added to the region, in cents.
>> Examples:
>> fil_random=100
>> fil_random=400
>> integer
>> 0
>> 0 to 9600 cents
>> Filter EG
>> fileg_delay
>> Filter EG delay time, in seconds. This is the time elapsed from note on
>> to the start
>> of the Attack stage.
>> Examples:
>> fileg_delay=1.5
>> fileg_delay=0
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> fileg_start
>> Filter EG start level, in percentage.
>> Examples:
>> fileg_start=20
>> fileg_start=100
>> floating point
>> 0 %
>> 0 to 100 %
>> fileg_attack
>> Filter EG attack time, in seconds.
>> Examples:
>> fileg_attack=1.2
>> fileg_attack=0.1
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> fileg_hold
>> Filter EG hold time, in seconds. During the hold stage, EG output will
>> remain at
>> its maximum value.
>> Examples:
>> fileg_hold=1.5
>> fileg_hold=0.1
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> fileg_decay
>> Filter EG decay time, in seconds.
>> Examples:
>> fileg_decay=1.5
>> fileg_decay=3
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> fileg_sustain
>> Filter EG sustain level, in percentage.
>> Examples:
>> fileg_sustain=40.34
>> fileg_sustain=10
>> floating point
>> 100 %
>> 0 to 100 %
>> fileg_release
>> Filter EG release time (after note release), in seconds.
>> Examples:
>> fileg_release=1.34
>> fileg_release=2
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> fileg_depth
>> Depth for the filter EG, in cents.
>> Examples:
>> fileg_depth=1200
>> fileg_depth=-100
>> integer
>> 0
>> -12000 to 12000
>> fileg_vel2delay
>> Velocity effect on filter EG delay time, in seconds.
>> Examples:
>> fileg_vel2delay=1.2
>> fileg_vel2delay=0.1
>> Delay time will be calculated as
>> delay time = fileg_delay + fileg_vel2delay * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> fileg_vel2attack
>> Velocity effect on filter EG attack time, in seconds.
>> Examples:
>> fil_vel2attack=1.2
>> fil_vel2attack=0.1
>> Attack time will be calculated as
>> attack time = fileg_attack + fileg_vel2attack * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> fileg_vel2hold
>> Velocity effect on filter EG hold time, in seconds.
>> Examples:
>> fileg_vel2hold=1.2
>> fileg_vel2hold=0.1
>> Hold time will be calculated as
>> hold time = fileg_hold + fileg_vel2hold * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> fileg_vel2decay
>> Velocity effect on filter EG decay time, in seconds.
>> Examples:
>> fileg_vel2decay=1.2
>> fileg_vel2decay=0.1
>> Decay time will be calculated as
>> decay time = fileg_decay + fileg_vel2decay * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> fileg_vel2sustain
>> Velocity effect on filter EG sustain level, in percentage.
>> Examples:
>> fileg_vel2sustain=30
>> fileg_vel2sustain=-30
>> Sustain level will be calculated as
>> sustain level = fileg_sustain + fileg_vel2sustain
>> Result will be clipped to 0~100%.
>> floating point
>> 0 %
>> -100 % to 100 %
>> fileg_vel2release
>> Velocity effect on filter EG release time, in seconds.
>> Examples:
>> fileg_vel2release=1.2
>> fileg_vel2release=0.1
>> Release time will be calculated as
>> release time = fileg_release + fileg_vel2release * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> fileg_vel2depth
>> -12000 to 12000 cents
>> integer
>> 0 cents
>> -12000 to 12000 cents
>> Filter LFO
>> fillfo_delay
>> The time before the filter LFO starts oscillating, in seconds.
>> Examples:
>> fillfo_delay=1
>> fillfo_delay=0.4
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> fillfo_fade
>> Filter LFO fade-in effect time.
>> Examples:
>> fillfo_fade=1
>> fillfo_fade=0.4
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> fillfo_freq
>> Filter LFO frequency, in hertz.
>> Examples:
>> fillfo_freq=0.4
>> fillfo_freq=1.3
>> floating point
>> 0 Hertz
>> 0 to 20 hertz
>> fillfo_depth
>> Filter LFO depth, in cents.
>> Examples:
>> fillfo_depth=1
>> fillfo_depth=4
>> floating point
>> 0 dB
>> -1200 to 1200 cents
>> fillfo_depthccN
>> Filter LFO depth when MIDI continuous controller N is received, in 
>> cents.
>> Examples:
>> fillfo_depthcc1=100
>> fillfo_depthcc32=400
>> integer
>> 0 cent
>> -1200 to 1200 cents
>> fillfo_depthchanaft
>> Filter LFO depth when channel aftertouch MIDI messages are received, in
>> cents.
>> Examples:
>> fillfo_depthchanaft=100
>> fillfo_depthchanaft=400
>> integer
>> 0 cent
>> -1200 to 1200 cents
>> fillfo_depthpolyaft
>> Filter LFO depth when polyphonic aftertouch MIDI messages are received,
>> in cents.
>> Examples:
>> fillfo_depthpolyaft=100
>> fillfo_depthpolyaft=400
>> integer
>> 0 cent
>> -1200 to 1200 cents
>> fillfo_freqccN
>> Filter LFO frequency change when MIDI continuous controller N is
>> received, in hertz.
>> Examples:
>> fillfo_freqcc1=5
>> fillfo_freqcc1=-12
>> floating point
>> 0 hertz
>> -200 to 200 hertz
>> fillfo_freqchanaft
>> Filter LFO frequency change when channel aftertouch MIDI messages are
>> received, in
>> hertz.
>> Examples:
>> fillfo_freqchanaft=10
>> fillfo_freqchanaft=-40
>> floating point
>> 0 hertz
>> -200 to 200 hertz
>> fillfo_freqpolyaft
>> Filter LFO frequency change when polyphonic aftertouch MIDI messages are
>> received,
>> in hertz.
>> Examples:
>> fillfo_freqpolyaft=10
>> fillfo_freqpolyaft=-4
>> floating point
>> 0 hertz
>> -200 to 200 hertz
>> Amplifier
>> volume
>> The volume for the region, in decibels.
>> Examples:
>> volume=-24
>> volume=0
>> volume=3.5
>> floating point
>> 0.0
>> -144 to 6 dB
>> pan
>> The panoramic position for the region.
>> If a mono sample is used, pan value defines the position in the stereo
>> image where
>> the sample will be placed.
>> When a stereo sample is used, the pan value the relative amplitude of
>> one channel
>> respect the other.
>> A value of zero means centered, negative values move the panoramic to
>> the left, positive
>> to the right.
>> Examples:
>> pan=-30.5
>> pan=0
>> pan=43
>> floating point
>> 0.0
>> -100 to 100 %
>> width
>> Only operational for stereo samples, width defines the amount of channel
>> mixing applied
>> to play the sample.
>> A width value of 0 makes a stereo sample play as if it were mono (adding
>> both channels
>> and compensating for the resulting volume change). A value of 100
>> will make the stereo sample play as original.
>> Any value in between will mix left and right channels with a part of the
>> other, resulting
>> in a narrower stereo field image.
>> Negative width values will reverse left and right channels.
>> Examples:
>> width=100 // stereo
>> width=0 // play this stereo sample as mono
>> width=50 // mix 50% of one channel with the other
>> floating point
>> 0.0
>> -100 to 100 %
>> position
>> Only operational for stereo samples, position defines the position in
>> the stereo
>> field of a stereo signal, after channel mixing as defined in the width
>> opcode.
>> A value of zero means centered, negative values move the panoramic to
>> the left, positive
>> to the right.
>> Examples:
>> // mix both channels and play the result at left
>> width=0 position=-100
>> // make the stereo image narrower and play it
>> // slightly right
>> width=50 position=30
>> floating point
>> 0.0
>> -100 to 100 %
>> amp_keytrack
>> Amplifier keyboard tracking (change in amplitude per key) in dB.
>> Examples:
>> amp_keytrack=-1.4
>> amp_keytrack=3
>> floating point
>> 0 dB
>> -96 to 12 dB
>> amp_keycenter
>> Center key for amplifier keyboard tracking. In this key, the amplifier
>> keyboard tracking
>> will have no effect.
>> Examples:
>> amp_keycenter=60
>> amp_keycenter=48
>> integer
>> 60
>> 0 to 127
>> amp_veltrack
>> Amplifier velocity tracking, represents how much the amplitude changes
>> with incoming
>> note velocity.
>> Volume changes with incoming velocity in a concave shape according to
>> the following
>> expression:
>> Amplitude(dB) = 20 log (127^2 / Velocity^2)
>> The amp_velcurve_N opcodes allow overriding the default velocity curve.
>> Examples:
>> amp_veltrack=0
>> amp_veltrack=100
>> floating point
>> 100 %
>> -100 to 100 %
>> amp_velcurve_1
>> amp_velcurve_127
>> User-defined amplifier velocity curve. This opcode range allows defining
>> a specific
>> curve for the amplifier velocity. The value of the opcode indicates
>> the normalized amplitude (0 to 1) for the specified velocity.
>> The player will interpolate lineraly between specified opcodes for
>> unspecified ones:
>> amp_velcurve_1=0.2 amp_velcurve_3=0.3
>> // amp_velcurve_2 is calculated to 0.25
>> If amp_velcurve_127 is not specified, the player will assign it the
>> value of 1.
>> Examples:
>> // linear, compressed dynamic range
>> // amplitude changes from 0.5 to 1
>> amp_velcurve_1=0.5
>> floating point
>> standard curve (see amp_veltrack)
>> 0 to 1
>> amp_random
>> Random volume for the region, in decibels.
>> Examples:
>> amp_random=10
>> amp_random=3
>> floating point
>> 0
>> 0 to 24 dB
>> rt_decay
>> The volume decay amount when the region is set to play in release
>> trigger mode, in
>> decibels per second since note-on message.
>> Examples:
>> rt_decay=6.5
>> floating point
>> 0 dB
>> 0 to 200 dB
>> output
>> The stereo output number for this region.
>> If the player doesn't feature multiple outputs, this opcode is ignored.
>> Examples:
>> output=0
>> output=4
>> integer
>> 0
>> 0 to 1024
>> gain_ccN
>> Gain applied on MIDI control N, in decibels.
>> Examples:
>> gain_cc1=12
>> floating point
>> 0
>> -144 to 48 dB
>> xfin_lokey
>> xfin_hikey
>> Fade in control.
>> xfin_lokey and xfin_hikey define the fade-in keyboard zone for the 
>> region.
>> The volume of the region will be zero for keys lower than or equal to
>> xfin_lokey,
>> and maximum (as defined by the volume opcode) for keys greater than or
>> equal to xfin_hikey.
>> Examples:
>> xfin_lokey=c3 xfin_hikey=c4
>> integer
>> xfin_lokey=0
>> xfin_hikey=0
>> 0 to 127
>> C-1 to G9
>> xfout_lokey
>> xfout_hikey
>> Fade out control.
>> xfout_lokey and xfout_hikey define the fade-out keyboard zone for the
>> region.
>> The volume of the region will be maximum (as defined by the volume
>> opcode) for keys
>> lower than or equal to xfout_lokey, and zero for keys greater than
>> or equal to xfout_hikey.
>> Examples:
>> xfout_lokey=c5 xfout_hikey=c6
>> integer
>> xfout_lokey=127
>> xfout_hikey=127
>> 0 to 127
>> C-1 to G9
>> xf_keycurve
>> Keyboard crossfade curve for the region. Values can be:
>> gain: Linear gain crossfade. This setting is best when crossfading
>> phase-aligned
>> material. Linear gain crossfades keep constant amplitude during the
>> crossfade,
>> preventing clipping.
>> power: Equal-power RMS crossfade. This setting works better to mix very
>> different
>> material, as a constant power level is kept during the crossfade.
>> text
>> power
>> gain, power
>> xfin_lovel
>> xfin_hivel
>> Fade in control.
>> xfin_lovel and xfin_hivel define the fade-in velocity range for the 
>> region.
>> The volume of the region will be zero for velocities lower than or equal
>> to xfin_lovel,
>> and maximum (as defined by the volume opcode) for velocities greater
>> than or equal to xfin_hivel.
>> Examples:
>> xfin_lovel=0 xfin_hivel=127
>> integer
>> xfin_lovel=0
>> xfin_hivel=0
>> 0 to 127
>> xfout_lovel
>> xfout_hivel
>> Fade out control.
>> xfout_lokey and xfout_hikey define the fade-out velocity range for the
>> region.
>> The volume of the region will be maximum (as defined by the volume
>> opcode) for velocities
>> lower than or equal to xfout_lovel, and zero for velocities greater
>> than or equal to xfout_hivel.
>> Examples:
>> xfout_lovel=0 xfout_hivel=127
>> integer
>> xfout_lokey=127
>> xfout_hikey=127
>> 0 to 127
>> xf_velcurve
>> Velocity crossfade curve for the region. Values can be:
>> gain: Linear gain crossfade. This setting is best when crossfading
>> phase-aligned
>> material. Linear gain crossfades keep constant amplitude during the
>> crossfade,
>> preventing clipping.
>> power: Equal-power RMS crossfade. This setting works better to mix very
>> different
>> material, as a constant power level is kept during the crossfade.
>> text
>> power
>> gain, power
>> xfin_loccN
>> xfin_hiccN
>> Fade in control.
>> xfin_loccN and xfin_hiccN set the range of values in the MIDI continuous
>> controller
>> N which will perform a fade-in in the region.
>> The volume of the region will be zero for values of the MIDI continuous
>> controller
>> N lower than or equal to xfin_loccN, and maximum (as defined by the
>> volume opcode) for values greater than or equal to xfin_hiccN.
>> Examples:
>> xfin_locc1=64 xfin_hicc1=127
>> integer
>> 0
>> 0 to 127
>> xfout_loccN
>> xfout_hiccN
>> Fade out control.
>> xfout_loccN and xfout_hiccN set the range of values in the MIDI
>> continuous controller
>> N which will perform a fade-out in the region.
>> The volume of the region will be maximum (as defined by the volume
>> opcode) for values
>> of the MIDI continuous controller N lower than or equal to xfout_loccN,
>> and zero for values greater than or equal to xfout_hiccN.
>> Examples:
>> xfout_locc1=64 xfout_hicc1=127
>> integer
>> 0
>> 0 to 127
>> xf_cccurve
>> MIDI controllers crossfade curve for the region. Values can be:
>> gain: Linear gain crossfade. This setting is best when crossfading
>> phase-aligned
>> material. Linear gain crossfades keep constant amplitude during the
>> crossfade,
>> preventing clipping.
>> power: Equal-power RMS crossfade. This setting works better to mix very
>> different
>> material, as a constant power level is kept during the crossfade.
>> text
>> power
>> gain, power
>> Amplifier EG
>> ampeg_delay
>> Amplifier EG delay time, in seconds. This is the time elapsed from note
>> on to the
>> start of the Attack stage.
>> Examples:
>> ampeg_delay=1.5
>> ampeg_delay=0
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> ampeg_start
>> Amplifier EG start level, in percentage.
>> Examples:
>> ampeg_start=20
>> ampeg_start=100
>> floating point
>> 0 %
>> 0 to 100 %
>> ampeg_attack
>> Amplifier EG attack time, in seconds.
>> Examples:
>> ampeg_attack=1.2
>> ampeg_attack=0.1
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> ampeg_hold
>> Amplifier EG hold time, in seconds. During the hold stage, EG output
>> will remain
>> at its maximum value.
>> Examples:
>> ampeg_hold=1.5
>> ampeg_hold=0.1
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> ampeg_decay
>> Amplifier EG decay time, in seconds.
>> Examples:
>> ampeg_decay=1.5
>> ampeg_decay=3
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> ampeg_sustain
>> Amplifier EG sustain level, in percentage.
>> Examples:
>> ampeg_sustain=40.34
>> ampeg_sustain=10
>> floating point
>> 100 %
>> 0 to 100 %
>> ampeg_release
>> Amplifier EG release time (after note release), in seconds.
>> Examples:
>> ampeg_release=1.34
>> ampeg_release=2
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> ampeg_vel2delay
>> Velocity effect on amplifier EG delay time, in seconds.
>> Examples:
>> ampeg_vel2delay=1.2
>> ampeg_vel2delay=0.1
>> Delay time will be calculated as
>> delay time = ampeg_delay + ampeg_vel2delay * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> ampeg_vel2attack
>> Velocity effect on amplifier EG attack time, in seconds.
>> Examples:
>> ampeg_vel2attack=1.2
>> ampeg_vel2attack=0.1
>> Attack time will be calculated as
>> attack time = ampeg_attack + ampeg_vel2attack * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> ampeg_vel2hold
>> Velocity effect on amplifier EG hold time, in seconds.
>> Examples:
>> ampeg_vel2hold=1.2
>> ampeg_vel2hold=0.1
>> Hold time will be calculated as
>> hold time = ampeg_hold + ampeg_vel2hold * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> ampeg_vel2decay
>> Velocity effect on amplifier EG decay time, in seconds.
>> Examples:
>> ampeg_vel2decay=1.2
>> ampeg_vel2decay=0.1
>> Decay time will be calculated as
>> decay time = ampeg_decay + ampeg_vel2decay * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> ampeg_vel2sustain
>> Velocity effect on amplifier EG sustain level, in percentage.
>> Examples:
>> ampeg_vel2sustain=30
>> ampeg_vel2sustain=-30
>> Sustain level will be calculated as
>> sustain level= ampeg_sustain + ampeg_vel2sustain
>> The result will be clipped to 0~100%.
>> floating point
>> 0%
>> -100 % to 100 %
>> ampeg_vel2release
>> Velocity effect on amplifier EG release time, in seconds.
>> Examples:
>> ampeg_vel2release=1.2
>> ampeg_vel2release=0.1
>> Release time will be calculated as
>> release time = ampeg_release + ampeg_vel2release * velocity / 127
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> ampeg_delayccN
>> Amplifier EG delay time added on MIDI control N, in seconds.
>> Examples:
>> ampeg_delaycc20=1.5
>> ampeg_delaycc1=0
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> ampeg_startccN
>> Amplifier EG start level added on MIDI control N, in percentage.
>> Examples:
>> ampeg_startcc20=20
>> ampeg_startcc1=100
>> floating point
>> 0 %
>> -100 to 100 %
>> ampeg_attackccN
>> Amplifier EG attack time added on MIDI control N, in seconds.
>> Examples:
>> ampeg_attackcc20=1.2
>> ampeg_attackcc1=0.1
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> ampeg_holdccN
>> Amplifier EG hold time added on MIDI control N, in seconds.
>> Examples:
>> ampeg_holdcc20=1.5
>> ampeg_holdcc1=0.1
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> ampeg_decayccN
>> Amplifier EG decay time added on MIDI control N, in seconds.
>> Examples:
>> ampeg_decaycc20=1.5
>> ampeg_decaycc1=3
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> ampeg_sustainccN
>> Amplifier EG sustain level added on MIDI control N, in percentage.
>> Examples:
>> ampeg_sustaincc20=40.34
>> ampeg_sustaincc1=10
>> floating point
>> 100 %
>> -100 to 100 %
>> ampeg_releaseccN
>> Amplifier EG release time added on MIDI control N, in seconds.
>> Examples:
>> ampeg_releasecc20=1.34
>> ampeg_releasecc1=2
>> floating point
>> 0 seconds
>> -100 to 100 seconds
>> Amplifier LFO
>> amplfo_delay
>> The time before the Amplifier LFO starts oscillating, in seconds.
>> Examples:
>> amplfo_delay=1
>> amplfo_delay=0.4
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> amplfo_fade
>> Amplifier LFO fade-in effect time.
>> Examples:
>> amplfo_fade=1
>> amplfo_fade=0.4
>> floating point
>> 0 seconds
>> 0 to 100 seconds
>> amplfo_freq
>> Amplifier LFO frequency, in hertz.
>> Examples:
>> amplfo_freq=0.4
>> amplfo_freq=1.3
>> floating point
>> 0 Hertz
>> 0 to 20 hertz
>> amplfo_depth
>> Amplifier LFO depth, in decibels.
>> Examples:
>> amplfo_depth=1
>> amplfo_depth=4
>> floating point
>> 0 dB
>> -10 to 10 dB
>> amplfo_depthccN
>> Amplifier LFO depth when MIDI continuous controller N is received, in
>> decibels.
>> Examples:
>> amplfo_depthcc1=100
>> amplfo_depthcc32=400
>> floating point
>> 0 dB
>> -10 to 10 dB
>> amplfo_depthchanaft
>> Amplifier LFO depth when channel aftertouch MIDI messages are received,
>> in cents.
>> Examples:
>> amplfo_depthchanaft=100
>> amplfo_depthchanaft=400
>> floating point
>> 0 dB
>> -10 to 10 dB
>> amplfo_depthpolyaft
>> Amplifier LFO depth when polyphonic aftertouch MIDI messages are
>> received, in cents.
>> Examples:
>> amplfo_depthpolyaft=100
>> amplfo_depthpolyaft=400
>> floating point
>> 0 dB
>> -10 to 10 dB
>> amplfo_freqccN
>> Amplifier LFO frequency change when MIDI continuous controller N is
>> received, in
>> hertz.
>> Examples:
>> amplfo_freqcc1=5
>> amplfo_freqcc1=-12
>> floating point
>> 0 hertz
>> -200 to 200 hertz
>> amplfo_freqchanaft
>> Amplifier LFO frequency change when channel aftertouch MIDI messages are
>> received,
>> in hertz.
>> Examples:
>> amplfo_freqchanaft=10
>> amplfo_freqchanaft=-40
>> floating point
>> 0 hertz
>> -200 to 200 hertz
>> amplfo_freqpolyaft
>> Amplifier LFO frequency change when polyphonic aftertouch MIDI messages
>> are received,
>> in hertz.
>> Examples:
>> amplfo_freqpolyaft=10
>> amplfo_freqpolyaft=-4
>> floating point
>> 0 hertz
>> -200 to 200 hertz
>> Equalizer
>> eq1_freq
>> eq2_freq
>> eq3_freq
>> Frequency of the equalizer band, in Hertz.
>> Examples:
>> eq1_freq=80 eq2_freq=1000 eq3_freq=4500
>> floating point
>> eq1_freq=50
>> eq2_freq=500
>> eq3_freq=5000
>> 0 to 30000 Hz
>> eq1_freqccN
>> eq2_freqccN
>> eq3_freqccN
>> Frequency change of the equalizer band when MIDI continuous control N
>> messages are
>> received, in Hertz.
>> Examples:
>> eq1_freqcc1=80
>> floating point
>> 0
>> -30000 to 30000 Hz
>> eq1_vel2freq
>> eq2_vel2freq
>> eq3_vel2freq
>> Frequency change of the equalizer band with MIDI velocity, in Hertz.
>> Examples:
>> eq1_vel2freq=1000
>> floating point
>> 0
>> -30000 to 30000 Hz
>> eq1_bw
>> eq2_bw
>> eq3_bw
>> Bandwidth of the equalizer band, in octaves.
>> Examples:
>> eq1_bw=1 eq2_bw=0.4 eq3_bw=1.4
>> floating point
>> 1 octave
>> 0.001 to 4 octaves
>> eq1_bwccN
>> eq2_bwccN
>> eq3_bwccN
>> Bandwidth change of the equalizer band when MIDI continuous control N
>> messages are
>> received, in octaves.
>> Examples:
>> eq1_bwcc29=1.3
>> floating point
>> 0
>> -4 to 4 octaves
>> eq1_gain
>> eq2_gain
>> eq3_gain
>> Gain of the equalizer band, in decibels.
>> Examples:
>> eq1_gain=-3 eq2_gain=6 eq3_gain=-6
>> floating point
>> 0 dB
>> -96 to 24 dB
>> eq1_gainccN
>> eq2_gainccN
>> eq3_gainccN
>> Gain change of the equalizer band when MIDI continuous control N
>> messages are received,
>> in decibels.
>> Examples:
>> eq1_gaincc23=-12
>> floating point
>> 0 dB
>> -96 to 24 dB
>> eq1_vel2gain
>> eq2_vel2gain
>> eq3_vel2gain
>> Gain change of the equalizer band with MIDI velocity, in decibels.
>> Examples:
>> eq1_vel2gain=12
>> floating point
>> 0
>> -96 to 24 dB
>> Effects
>> effect1
>> Level of effect1 send, in percentage (reverb in sfz).
>> Examples:
>> effect1=100
>> floating point
>> 0
>> 0 to 100 %
>> effect2
>> Level of effect2 send, in percentage (chorus in sfz).
>> Examples:
>> effect2=100
>> floating point
>> 0
>> 0 to 100 %
>> Fin du tableau
>>
>>
>> On 10/26/2014 12:24 PM, Ken Downey wrote:
>>> I've had to delay doing the Reaper podcast because the only way I 
>>> can do it currently is through a recorder over the mikes. I'd rather 
>>> be able to plug the computer directly into my recorder, but that 
>>> means I can't mike myself and the computer at the same time, so only 
>>> one of those gets through. I can't record stereo mix because it 
>>> infinitely loops everything, so I'm going to have to go buy a 
>>> splitter, use my iPhone as a mike, and connect both it and the 
>>> computer to my recorder. then I'll be podcasting.
>>> I also am wondering if any of you have found a way to get the 
>>> sustain pedal to work with Samplomatic. It doesn't respond, though 
>>> all my other instruments do. If not, does anyone know of a good, 
>>> accessible sampler that's at least somewhat easy to use? I know that 
>>> Synthfont makes a good one, but building Sound fonts in Viena tends 
>>> to be more a pain in the neck than its worth. Thoughts?
>>> Ken Downey
>>> For a fresh perspective of Christianity, visit my blog at
>>> longing4god.wordpress.com,
>>> and my podcast network at
>>> www.audioboom.fm/channel/honest2god 
>>> <http://www.audioboom.fm/channel/honest2god> .
>>> For experimental electroacoustic music that is out of this world, visit
>>> www.BlindLabyrinth.com <http://www.BlindLabyrinth.com> .
>>> Feel free to add me as a friend on Skype and Facebook. My user name 
>>> is always the same, KenWDowney.
>>>
>>>
>>> _______________________________________________
>>> RWP mailing list
>>> RWP at reaaccess.com
>>> http://reaaccess.com/mailman/listinfo/rwp_reaaccess.com
>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at reaaccess.com
>> http://reaaccess.com/mailman/listinfo/rwp_reaaccess.com
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at reaaccess.com
>> http://reaaccess.com/mailman/listinfo/rwp_reaaccess.com
>>
>
>
> _______________________________________________
> RWP mailing list
> RWP at reaaccess.com
> http://reaaccess.com/mailman/listinfo/rwp_reaaccess.com
>
> _______________________________________________
> RWP mailing list
> RWP at reaaccess.com
> http://reaaccess.com/mailman/listinfo/rwp_reaaccess.com
>