One of the main reasons to have tis page is to show the validity of various proposals I've made, by sharing development phase demonstrations or simply experimental results.
The next example is created by using an additive synthesis generator program to produce samples that are made into chords and detuned to produce a leslie-type effect, as on an electronic organ. It also contains a completely synthetically generated rythm. The sample process program can generate reverb (and of course delay) effects as well: reverb added.
Currently I'm looing at filtering, as in analog synth filters, that sounds roughly like this for a 4th order (24dB/Octave) non-resonating filter, sweeped from 20 Hz to 20 kHz over the above sample. This version needs work because it is way to noisy, but the design was made based on the simulation of the electronical cicruit, and roughly meets it specs. I'm building a text on the subject (definately preliminary, I've later notes and corrections I didn;t add yet) , and a program (C source) that implements the above filter as a parameterized IIR .WAV file processing block, with linearly sweepable filter characteristics over the sample time span (resonance is not ok yet, so should be zero).
As as I have time (and generated a more elaborate Bwise interface), I clarify the use programs.
Addsyn can be used by simply looking
at the required command line arguments:
Usage c:/theover/drum/addsyn.exe
(sound.wav> (fundamental relative to 440Hz>
(number of funds> (harmonic relative_ampl} ...
the output file, the relative pitch compared to standard A, the
desired number of complete fundamental sines in the output (220 for
half a second of standard A), followed by any
number of harmonics defined by their (integer) relation to
the fundamental, and their relative amplitude.
Beware that an amplitude of one means near clipping!
drumit takes one argument, the output .wav file, and
then starts reading from its input.
The first command to it must be a 'len
A possible application of the drumit program is to merge samples
into one, and it can use the sample used for output also
as input. The next track was generated by taking
(the control Z and the return are to stop the input from being
read further on MSDOS).
snorg2 is merged with linn1 and written back to itself,
and the mix ratio is determined by the amplitudes, here
both set to one half, otherwise the result might clip.
Roughly all amplitudes together should add up to 1 for
the best use of the available headroom (assuming the
input samples are at 0dB).
The result is
semi leslied electronic organ chords with Linn drum
The reverb mentioned in the first paragrap is generated by
using drumit with input from a tcl procedure:
The data is fed to the input of drumit snorg2r.wav to
generate the reverb type of effect.
Note that because of the relative fast operation of drumit's
sample processing quite some reverb elements could be added,
to achieve high quality, and they can simply be fed to the
tcl 'rev' routine as a list of pairs of delay, amplitude
values. Of course it is possible to apply the reverb to
each desired sample, also to samples with mixdowns that
would normally come from a mixers 'aux send' output,
to generated portions of reverb for all instruments in the
desired proportion.
Evidently, many of these types of operations call for
graphical user interfaces on top of the textual ones, and
more functions can be constructed. This is of course on of the
future functions of bwise, which can provide a powerfull
and rather unique combination of procedural, graphical,
interacive (even real time) and interaction driven
composition and synthesis. Because samples can be decomposed
in varous ways, it is for instance possible to maintain
the desired chorusing effects on the electronic organ
sound be using varying detune rates for the notes making up
chords, yet grouping the results together for further processing.
Clearly some of the processing mentioned is more generally
known as hard disk editing, track editing adn composition,
and such. In fact all samples are kept in core, which
limits the total number of samples (in fact the total sample
time) to roughly the amount of megabytes times 12 seconds.
for extensive editing of a few bars this is usually quite
sufficient, and memory is still getting cheaper...
The loading of samples i intelligent, i.e. a sample can be
reused (and detuned) many times after having been loaded, and
the loading is normally tranparent to the user.
Midi files are on the implementation wishlist, their link with
the drumit type of input is reasonably one on one.
A lot of interesting possibilities open up when socket connections
with the Tcl/Tk (Bwise++) environment are feasible in my development
setup. They are perfectly well available, but my cygnus (or GNU)
compiler doesn't support them properly. Using sckets, the graphical
user interface, textual interaction, and inter-block communication
is lifted to a (near, dependent on the platform) real time
level.
name start length amplitude tuning
where name is the name of a .WAV sample file int he current
directory, minus the extension (so kick.wav becomes kick),
start is the position in the output sample where it will start
to sound, in Milli Seconds (so 1000 is one second, or half a bar
at 120 Beats per Minute), length is the time the sample is
to sound (same notation as start), or 0 when the sample
simply is to sound as long as it is, amplitude is the relative
amplitude compared to 1.0 (linear measure, i.e. -6dB is 0.5),
and finally tuning is
the relative tuning of the note compared to the original
sample, that is 1.0 means original pitch, 2.0 is an octave
higher, 0.25 four octaves lower.
To make it possible to produce tonal intervals, a twelveth
square root of 2 table is needed, where each line indicates
the relative tuning as compared to the original pitch:
-24,0.25
-23,0.26486577359
-22,0.280615512077
-21,0.297301778751
-20,0.314980262474
-19,0.333709963543
-18,0.353553390593
-17,0.374576769219
-16,0.396850262992
-15,0.420448207627
-14,0.44544935907
-13,0.471937156341
-12,0.5
-11,0.52973154718
-10,0.561231024155
-9,0.594603557501
-8,0.629960524947
-7,0.667419927085
-6,0.707106781187
-5,0.749153538438
-4,0.793700525984
-3,0.840896415254
-2,0.89089871814
-1,0.943874312682
0,1.0
1,1.05946309436
2,1.12246204831
3,1.189207115
4,1.25992104989
5,1.33483985417
6,1.41421356237
7,1.49830707688
8,1.58740105197
9,1.68179283051
10,1.78179743628
11,1.88774862536
12,2.0
13,2.11892618872
14,2.24492409662
15,2.37841423001
16,2.51984209979
17,2.66967970834
18,2.82842712475
19,2.99661415375
20,3.17480210394
21,3.36358566101
22,3.56359487256
23,3.77549725073
24,4.0
The line starting with 0 is the original pitch. To get a
minor third interval, count the number of semitones between
the third and the ground note, in this case 3, look up the
relative pitch (in this case 1.1892)m and you're set.
This is the way the organ chord samples were made.
drumit snorg2.wav
len 2000 0 0 1
snorg2 0 0 0.5 1
linn1 0 0 0.5 1
proc rev {{n} {r {{0 0.8} {80 0.2} {101 0.1} {105 0.1} {160 0.07}} } } {
set o ""
append o "len 2000 0 0 1\n"
foreach i $r {
append o "$n [lindex $i 0] 0 [lindex $i 1] 1\n"
}
return $o
}
rev snorg2
len 2000 0 0 1
snorg2 0 0 0.8 1
snorg2 80 0 0.2 1
snorg2 101 0 0.1 1
snorg2 105 0 0.1 1
snorg2 160 0 0.07 1