Dynamic Orchestration
Dynamic Orchestration
; The lines starting with ';' are comments and are not evaluated; in the following
; lines, some comments will explain each specific parameter.
; The parameter db_files contains the files of the features; please note that this
is
; a list and can contain different files, corresponding for example to different
datasets.
; The only constraint is that each file should contain the same features (ex. mfcc)
; The parameter sound_paths is the list of folders where the audio files are
located;
; please note that files must be WAV@44100, 16 bit.
; The naming convention for the files in the database is the following:
; instrument-style-note-dynamics-other.wav
; If your files are not named as specified, they will be tagged with 'N' for
; each specific field. The structure of the folder is not important.
db_files /Users/Carmine/Projects/Media/Datasets/TinySOL.spectrum.db
sound_paths /Users/Carmine/Projects/Media/Datasets/TinySOL
; This list specifies the instruments of the orchestra to be used; the names depend
; on the database used. The character '|' in between two or more instruments means
; that the instruments are played by a single player and are consider as doubles;
; the algorithm will pick up either instrument depending on the optimization.
; These parameters are the filters for styles, dynamics and other tags; if the line
; is commented there will be no filter applied.
; OPTIMIZATION -----------------------------------------------------------------
; These are the parameter for the optimization. Normally, you don't need to change
; them unless the solutions are not satisfactory.
; The population size and the number of epochs determines the width of the
research;
; usually the bigger the better, but the computation time can be long.
; Suggestion: For static targets this is often not a problem and using 500 for both
is ok;
; for dynamic targets probably using 100 for both (or 100 and 300 respectively)
; can be more appropriate.
pop_size 200
max_epochs 200
; To determine the initial population for the optimization, Orchidea uses a method
; called 'stochastic pursuit'. Generally speaking, the method tries to generate
right
; away some solutions that are close to the target. This is usually better but can
; produce final solutions that are too homogeneous. Using 0, the initial population
; is random; using 1 the pursuit will be not relaxed and the initial population
will
; be made of a single solution repeated (so it is not good). Increasing this value,
; for example to 3, means that the initial population will be made of a number of
; different solutions that are somehow close to the target.
; Suggestion: use 0 if you are unsure, 3 or more if you understand this parameter.
pursuit 5
; Cross-over rate and mutation rate have the usual meaning in genetic optimization.
; Generally speaking, you should not change cross-over rate and you should increase
; mutation rate only to increase diversity of solutions, in spite of consistency.
; Suggestion: mutation rate should stay between 0.001 and 0.1
xover_rate 0.8
mutation_rate 0.01
; Sparsity determines the freedom that the algorithm has to remove instruments of
; the given orchestra from the solution. If sparsity is 0, each solution will use
; all instruments; if this value increases, the probability of dropping an
instrument
; increases correspondingly.
; Suggestion: use 0.01 for general targets, 0.001 for symphonic targets, 0.1 for
; single notes of instruments used as targets.
sparsity 0.001
; The way Orchidea determines if a solution is close or not to the target is given
; by an asymmetric function that considers differently cases in which a solution
; found partials that are present in the target or partials that are not present.
; In the latter case, usually, the penalization should be stronger since we don't
; want to hear partials that do not exist in the target.
; Suggestion: keep a ratio >10 between negative/positive, increasing negative
penalization
; if you notice that there are too many spurious partials and increasing positive
; penalization if you notice that there are not enough partials.
positive_penalization .5
negative_penalization 10
hysteresis 0.1
regularization 0
; TARGET -----------------------------------------------------------------------
; The following parameters refer to the analysis of the target and subsequent
; filtering of the search space. The window size (in samples) should be large
; if you know that the target contains very low frequency (ex. A1).
; The valid segmentation policies are: flux, powerflux, frames.
; Partials filtering works like that: if it is 0 there is no filtering and all
; the sounds in the database are used. If it is between 0 < x < 1 than the database
; is reduced by removing the sounds that does not correspond to the partials in the
; target. Increasing this value produces a stricter selection and only strongest
; partials (dynamically) are retained.
; Suggestion: use 0 for inharmonic or noisy sounds where timbre is more important
; than pitch, and something between 0.1 < x < 0.3 if pitches are also important.
segmentation flux
partials_window 32768
partials_filtering .2
; If, after the target analysis, there are still some pitches that are missing
; you can add them here in standard notation (ex. A4, B#3, ...)
extra_pitches N
onsets_threshold .1
onsets_timegate .1
; EXPORT -----------------------------------------------------------------------
; This final parameters are related to the exported solution. You can determine
; how many of them are saved (please keep in mind that for temporal solutions
; there is also the file connection.wav that represents the final orchestration).
; T60 specifies the reverberation time and you can control the dry/wet ratio with
; respective parameters.
export_solutions 0
t60 2.8
dry_wet .8 .4
; eof