[RWP] My Podcast and a samplomatic question

[Chris Belle]

Well, that's the work around anyway, and having multiple samples avoids 
aliasing and
just sounds better, even when you make those samples from existing ones.


On 10/29/2014 1:44 PM, Ken Downey wrote:
> You can tune each sample, but for scaling and temprament you'd have to 
> have one sample per key. There is also pitch tracking, so you can 
> have, say, a one and a quarter semitone pitch change for notes, but 
> not outright temperaments and scales. I've looked through pretty 
> thoroughly, so if I've still missed it I'll be surprised. That's not 
> to say the level 1 opcodes can't do much, because they can. It's 
> actually quite incredible all i can do just with them. By the way, I 
> was quite pleased to find the FluidR3 soundfont made into an sfz. It 
> sounds quite good.
> ----- Original Message ----- From: "Chris Belle" <cb1963 at sbcglobal.net>
> To: "Reapers Without Peepers" <rwp at reaaccess.com>
> Sent: Wednesday, October 29, 2014 8:58 AM
> Subject: Re: [RWP] My Podcast and a samplomatic question
>
>
> Well, I think sforzando can do some scaling stuff, so can dimension pro.
>
> You do have tuning functions,
> with every sample and every group, so you can definitely make your own
> by adjusting opcodes,
> read through that doc, even level one will get you a long ways.
>
> I have made many instruments and use them in my productions.
>
>
> On 10/29/2014 10:47 AM, Ken Downey wrote:
>> What I mean by temperament is different tuning systems. There's the 
>> western temperament everybody knows, but there are others, like 
>> Zarlino, where the c, e, and g are so tightly tuned with each other 
>> that there's no movement within the chord. Then, there's the G major 
>> chord which almost sounds too out of tune to sound good, like a badly 
>> tuned piano. Other chords in that temperament fall between the tight 
>> c major and loose g major. So in one temperament a might be 440 herts 
>> and c sharp at 550, while in another a might be at 430 and c sharp 
>> might be at 470. My ears get sick of the western temperament.
>> ----- Original Message ----- From: "Chris Belle" <cb1963 at sbcglobal.net>
>> To: "Reapers Without Peepers" <rwp at reaaccess.com>
>> Sent: Wednesday, October 29, 2014 8:37 AM
>> Subject: Re: [RWP] My Podcast and a samplomatic question
>>
>>
>> Sfz can do both sequencial patterns of samples or randomly pick one
>> according to the values you set.
>>
>> So you don't always get the same sample.
>>
>> I'm happy to tutor you at my ridiculously low rates.
>>
>>
>> On 10/29/2014 8:12 AM, Ken Downey wrote:
>>> I guess I just always find the limits to things as soon as I see 
>>> them lol. What I was looking for the level two opcodes for is that I 
>>> want to be able to change temperaments and scales without having to 
>>> create a bunch of pretuned samples. There is, of course, pitch 
>>> tracking which can detune a scale, but it won't get you the Zarlino 
>>> temperament for example.
>>> Also, can you explain the round robin thing? I didn't see that 
>>> anywhere in the codes and don't quite know what it is, unless it's 
>>> the thing where you can have it play an exact number of loops with 
>>> the count command?
>>> ----- Original Message ----- From: "Chris Belle" <cb1963 at sbcglobal.net>
>>> To: "Reapers Without Peepers" <rwp at reaaccess.com>
>>> Sent: Wednesday, October 29, 2014 12:41 AM
>>> Subject: Re: [RWP] My Podcast and a samplomatic question
>>>
>>>
>>> yes, I've seen that.
>>>
>>> Don't worry, those level one opcodes will keep you busy, and there's
>>> plenty of power to be had there.
>>>
>>> You can also go peak in to other sfz files,
>>> you're not a sonar man, but I'm always taking hints from looking at how
>>> other things are constructed,
>>> dimension pro and rapture and such, if you can get your hands on 
>>> some of
>>> those things, the newer opcodes are evolving too,
>>> the few I know about are things like having control groups, and common
>>> paths for samples,
>>> and there's some things using higher cc values than 127.
>>>
>>> I guess we'll have to go buy that power cakewalk book, there's also a
>>> google doc, but you have to sign up and it's passworded,
>>> some guy on linux sampler keeps it, if we can get at that, it might 
>>> help.
>>>
>>>
>>> On 10/28/2014 9:08 PM, Ken Downey wrote:
>>>> Not exactly explanatory, but here's an incomplete list of opcodes. 
>>>> http://www.linuxsampler.org/sfz/
>>>> ----- 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> RWP mailing list
> RWP at reaaccess.com
> http://reaaccess.com/mailman/listinfo/rwp_reaaccess.com
>