by Theo Verelst

Long ago, (in software terms, 5+ years?) I made a early version of bwise, which already had a drum subwindow in it, which worked in the way described here, too, I'd one would compile the accompanying C program, which was made on networked windows 95 systems.

The idea of the block is that all the little circles can be clicked, in which case they change color and become representative for a drum (or other sound) trigger at a certain 1/16tg note, counting from left to right. So by simply clicking in this bwise block, one can make drum patterns with various sounds.

The tcl routine to make something machine readable from this pattern on the bwise Tk canvas, should be updated from the bwise one, to:

 proc drumscan { {bl {drum0}} {tr {bd hho hhc sd}} } {
    global mc
    set maxi 0
    foreach k [listunion [$mc find withtag drumbol] [$mc find withtag $bl] ]  {
       if {[$mc itemcget $k -outline] != {}} {
           eval lappend outlist \{  [string range [lindex [$mc itemcget $k -tag] 2]  4 end] [string range [lindex [$mc itemcget $k -tag] 3]  4 end] \}
       }
       set ii [string range [lindex [$mc itemcget $k -tag] 3]  4 end]
       if {$ii > $maxi} {set maxi $ii}
    }
    set outlist [lsort -index 1 -int $outlist]

    set argi "len [expr 1000+(1000/8)*$maxi] 0 0 0\n"
    foreach i $outlist {
       set start " [expr [lindex $i end] * 2000.0 / 16]"
       switch [lindex $i 0] {
          bd    {append argi "kick01  $start 200 0.9 1"}
          sd    {append argi "snare01 $start 300 0.7 1"}
          hhc   {append argi "hat01   $start 100 0.3 1"}
           default   {append argi "[lindex $i 0] $start 200 0.3 1"}
       }
       append argi "\n"
    }
    return $argi
 }

For the above pattern, this routine returns the following:

 len 2875 0 0 0
 kick01  0.0 200 0.9 1
 hat01  0.0 100 0.3 1
 kick01  125.0 200 0.9 1
 hat01  250.0 100 0.3 1
 snare01  250.0 300 0.7 1
 hat01  375.0 100 0.3 1
 kick01  500.0 200 0.9 1
 hat01  750.0 100 0.3 1
 snare01  750.0 300 0.7 1
 hat01  875.0 100 0.3 1
 kick01  1000.0 200 0.9 1
 kick01  1125.0 200 0.9 1
 hat01  1250.0 100 0.3 1
 snare01  1250.0 300 0.7 1
 kick01  1375.0 200 0.9 1
 hat01  1375.0 100 0.3 1
 hat01  1500.0 100 0.3 1
 snare01  1500.0 300 0.7 1
 hat01  1750.0 100 0.3 1

We will no look at how to use this upated drumscan procedure to generate a drum sample which corresponds to the pattern we entered in bwise (and which can be saved with the canvas). The built in routines are not suitable for the latest sample processing program, which allows detuning.

Replace the drumscan button command with an updated one, containing the name (and possibly path) of your sample processing executable:

 .fb.bscan conf -command {exec drtry.exe drum1.wav << [drumscan] &}

I've assumed ms windows here, but I've also used the same setup on linux before, possibly even without much change at all, except maybe a few compile option issues, which on this page aren't ironed out. I've used cygwin to compile, which does that job fine.

The sample processing program is written in C, it allows loading of a sample set and pasting them at any time in the output sample, sample accurate, with individual starting-point, length (both in milliseconds), amplitude and detune parameters. The program reads and writes mono CD quality .wav files (a well know uncompressed RIFF format variation, 44100 samples/sec). It can be downloaded here (one source file, about 12 kB):

   [http://www.theover.org/Wiki/drumitd.c]

An input example:

 len 2000 0 0 0
 ../Drums/kick 0 300 0.8 1.0
 ../Drums/sd 500 500 0.7 0.6
 ../Drums/ohh 250 300 0.5 1.3

The first line defines the size of the output sample (2 seconds), the next line reads in a bass drum from the file ../Drums/kick.wav and copies it to the output sample starting at the first sample point, for a maximum of 0.3 sec, amplitude 80%, tuning equal to the input sample.

The third line does a similar thing for a snaredrum sample, which is detuned to sound lower, and the fourth line adds an open high hat. The order in which the samples are specified is irrelevant, also when the order is non-chronological, and samples can be 'paste'-ed repeatedly efficiently, without reloading. all processing takes place in core, until when stdin is exhausted, the program writes the output sample to disc and exists.

Assuming the above is stores in file 'drumpattern.txt'

   ./drtry outputsample.wav < drumpattern.txt

will perform the above commands and create output file outsample.wav (first and only argument to the program). On a reasonably fast machine, this should take hardly any time at all.

compile with:

   gcc -mno-cygwin -o drtry.exe drumitd.c -lm

Or #define CYGWIN and the permissions are set a but more aimable when you compile without the -mno-cygwin option, which is also probably the way to go on linux.

A standalone (no cygwin lib needed) version can be downloaded here:

   [http://www.theover.org/Wiki/drtry.exe]

It's a small executable for a recent windows version (16kB), which has been strip-ped.

The rendering of the above pattern with translation to the drumsample references below as made in the example, mpeg compressed is here (about 13kB):

   [http://www.theover.org/Wiki/drum1.mp3]

You'll need samples files (44.1kHz, mono) like these:

   http://www.theover.org/Wiki/kick01.wav
   http://www.theover.org/Wiki/hat01.wav
   http://www.theover.org/Wiki/snare01.wav

Put them in the current directory of tcl at the time of the drtry.eze startup.

With everything set up such that the program and the samples are in the current directory, the bwise block can be edited, followed by pressing the 'Scan Drum' button, to make a sample output file. Double click the appearing output file, or load it in som eaudio player to hear the result.

Some audio players don't close the file when done, so you must quit the player first, before you can overwrite the file with a new version. Defaults as they are seem to result in rather limited file permissions, even read-only, see the 'open' command of initwav(). Cygwin is a bit nicer.

Have fun !

---

NOTES FOR LINUX USERS

I just tried the same linux, which worked, but can use a little extra info. First, I updated the C code, and one of course would understand that the define on top must be set according to the compiler/env used, and on linux one would simply compile with:

  gcc -o drtry drumitd.c -lm

which is smooth and fast and with no errors/warnings.

of course the 'Scan Drum' button command needs to reflect our executable now has no .exe extension, and I integrated the linux 'play' command to work on at least RedHat as a sample player, which is called automatically when the button is pushed, hiding warning messages:

 .fb.bscan conf -command { exec drtry drum1.wav << [drumscan] ;
   catch { exec play -c 1 drum1.wav 2>/dev/null & }
 }

Edit the pattern, hit the botton: and the pattern sounds immedeately.

---

TV For the orignal page, and more drum samples, see http://members.tripod.com/%7Etheover/bwiseapp.html .

---