Conference napalm::commusic_v1

    I appreciate your intent, but there's a problem.  Short of having
    a distinct sample for every possible combination of parameters
    you wish to select, I doubt anyone has the requisite knowledge to
    alter the base sample in the way implied by the parameter selection.
    Current technology and understanding of the acoustics of drum sounds
    offer us only very primitive processing alternatives, basically:
    
    	pitch (base pitch and pitch envelope, possibly velocity dependent)
        
    	timbre (possibly time varying and velocity dependent)
    
    	EQ (possibly time varying and velocity dependent)
    
    	amplitude envelope (possibly velocity dependent)
    
    Envelope dependencies on velocity may include time (or rate) and level
    effects.
    
    In particular, even an experienced drummer will be able to make
    only relatively qualitative statements about the consequences of
    the kinds of choices you've proposed.  So even if it were practical
    to throw AI or expert system technology at this problem, I question
    whether the requisite expertise to "teach" the system exists.
    
    I'd rather a simple machine that addressed these basic processing/
    manipulative capabilities, backed up by a large library of samples.
    
    I had a similar reaction when Eirikur proposed elsewhere in this
    conference an analogous kind of programming interface for synths,
    e.g., controls labeled "warmth" or "thickness".  These words mean
    different things to different people, and often their attainment
    even when you know exactly what you mean by them entails the
    simultaneous manipulation of multiple parameters in a coordinated
    fashion.  In addition, if the control interface to the synth only
    allows you to manipulate sounds in terms of these specific combinations
    of operations, you may be rendering certain other "interesting"
    combinations impossible or exceedingly difficult to express.
                 
    The state of the art in drum machine technology (really sampling
    technology tailored to drumming's specific needs) is probably the
    Simmons SDX.  I have my own notions about what the "perfect" drum
    synth would be like, maybe I'll dig them out and summarize them
    here later.
    
    len.
    

    This is related to my "ultimate drum machine" ideas, but not related
    to how each drum (sound) is created/manipulated.
    
    I would like a drum machine oriented toward REAL-TIME playing, that
    is, one that can "jam along" with you.  The new Yamaha RX120 has
    some of the features I like ... but I'd like these features with
    HR-16-quality sounds!  Things like
    
    	Ability to choose patterns QUICKLY
    	Have several (3 or more) variations for each pattern, that are
    		called up by hitting (or stepping on) the appropriate
    		single button/footswitch
    	Have several (3 or more) fills, controllable as above
    	Have one or more "beginnings" and "endings" that are, again,
    		easy to invoke.  
    	have a DEDICATED slider for tempo (none of this "enter TEMPO
    		mode, then ..." stuff
    	Have lots of pre-programmed stuff, AND the ability to program
    		your own patterns/fills/variations, etc.
    
    This way, I could call up my "basic Rock" pattern, and while playing
    be able to call up several (increasingly complex/variant) variations
    that "make sense" given the basic pattern, all doable with single
    key or foot-switch strokes, rather than the many keystrokes I sometimes
    need now.  And, be able to AT ANY TIME change the tempo by small
    amounts or drastically.
    
    There are probably other "real-time-playing" features I'd want,
    these are what come immediately to mind ...
    
    			-Jim

    re .2 - the features you are asking for are really features of a
    sequencer.
    
    Remember that a drum machine is really two machines integrated into
    a single box:
    
    	a drum synth, and
    
    	a pattern oriented sequencer.
    
    Maybe what we should do is put together an "RFP" (request for
    proposals) for a drum machine/synth/sequencer and submit it to all
    our favorite manufacturers.  It'd be interesting to see how each
    of them responded.
    
    len.
    

    RE: .1
    
    That's why I thought that resynthesis would be perfect for this
    beast.  One could take samples of each of the drums, re-synthesize
    them, and then (based on the consistencies of, say, all drums with
    hydraulic heads) alter the resynthesized waveforms.
    
>        I had a similar reaction when Eirikur proposed elsewhere in this
>    conference an analogous kind of programming interface for synths,
>    e.g., controls labeled "warmth" or "thickness".  These words mean
>    different things to different people, and often their attainment
>    even when you know exactly what you mean by them entails the
>    simultaneous manipulation of multiple parameters in a coordinated
>    fashion.  In addition, if the control interface to the synth only
>    allows you to manipulate sounds in terms of these specific combinations
>    of operations, you may be rendering certain other "interesting"
>    combinations impossible or exceedingly difficult to express.

	I think you're missing it.  I don't think that a physical quantity
    such as drumhead type or drum shell depth will mean different things
    to different people.  And these parameters will (could) be modeled
    after samples of waveforms created by drums with these attributes.
    
    Or do I not understand how resynthesis works?
    
    re: .2
    	Yeah, these would be great things, but Len's right, those are
    sequencer properties.  However, I said 'Drum machine' which is (imo)
    both a sound generator *and* a sequencer.  I'd love to be able to
    hit a pad which triggered a bonzo-backbeat so I could play hot-licks
    fills all over the toms. :^)

    The Ultimate Drum Machine?  That's easy for me: Rod Morgenstein.
    
    Actually, I'd be more than happy with an HR-16 that did backward
    stepping.  ;-)
    
    	db

Ashley's wants can be realized.  Resynthesis *is* the way to go -
Multi-sampling and resynthesis using interpolation algorithms is the key
mechanism for implementing the features requested in .0.  The ability to build
and alter your own drum kit using conventional terms electronically is
exciting. 

Caution, Strong statement follows: Resynthesis using interpolation is the key
to the future of acoustic instrument emulation.  The MKS-20 landmarks the
beginning of this technology. 

Todd.

    re .4 - the remarks about the meaning of words had to do with Eirikur's
    wish, not your ideas about drums.  Sorry if I didn't make that clear.
    
    Be that as it may, I still believe your efforts to find some
    "objective" waveform correlates of various "configuration" parameters
    (e.g., head type) will prove exceedingly difficult to exploit.
    Also it's still the case that these things interact in ways that
    will require an enormously complex synthesis model, a model that
    requires more understanding of the acoustics of drums than anyone
    has at this point.
    
    Regarding resynthesis, I wish you all the best of luck.  Interpolation
    is only valid over a relatively small range; that's why accurate
    synthesis of existing intruments is so difficult.
    
    Anyway, a preliminary sketch of *my* notion of the ultimate drum
    machine follows.
    
    len.
    
    

    My "ultimate drum machine" would consist of 4 modules, each ideally a 
    single rack unit high.  The four units would be:
    
    	1) a drum sample player
    
    	2) a pattern oriented sequencer
    
    	3) a drum sample editor
    
    	4) a drum sample recorder.

    
    The Sample Player
    -----------------

    The drum sample player is a 16 stereo voice unit.  There are 16 sample 
    playing modules, and the sample memory can contain an arbitrary number
    of samples (constrained only by available memory) which may be shared
    by multiple voices.  Modules are allocated to voices in either a fixed
    or dynamic fashion.
    
    Note the distinction between samples, modules, voices, and configurations
    of sample assignments to voices.  The unit can have as many samples as 
    will fit; this will probably be arbitrarily limited to 100 total so that
    in memory samples can be identified by a two digit decimal integer.
    The 16 modules mean that up to 16 distinct samples can be played at the
    same time.  The 16 voices mean that up to 16 sounds are available for
    configuration as a "kit".
    
    Memory requirements for samples are determined by the requirement that
    each sample be 44.1 KHz, 16 bit (CD quality) stereo.  Thus, each second
    of sample time requires 2 * 44100 * 2 Bytes = 176400 Bytes of sample
    memory.  Assuming a typical disposition of the 16 voices, with the 
    following ballpark sample length requirements:
    
    	5 4-second samples (1 ride and 4 crash cymbals)
    
        8 2-second samples (snare, kick, 5 toms, open hihat)
    
    	3 1-second samples (closed hihat, partially closed hihat, other)
    
    we require at least 39 (call it 40) seconds' worth of sample memory.
    Note that the configuration above is simply an example configuration.
    Other configurations of voices and samples could be selected, using
    whatever samples are available in sample memory.  In addition, the
    contents of sample memory can changed by loading samples from the
    integral 3.5" floppy disk drive.  Also, allocation of sample memory is 
    not fixed in any way.
    
    40 seconds of sample time requires 7MB of sample memory.  Call it 8MB.
    Taking into account the fact that 2^10 is a little more than 10^3,
    8MB of sample memory means 47.5 seconds of 44.1KHz 16 bit stereo samples.
    
    Looking a few years out into the future, assume the availability of 
    4 megabit DRAM parts, probably organized as 4M * 1.  This means a byte
    addressable memory must be configured in in multiples of 4MB.  We need
    some software space as well as sample space, so be generous and assume
    12 MB of RAM  (this requires 24 chips: 12MB * 8 b/B / 4 Mb/part).
    Depending on how much space the software takes (assume a lot), we then 
    might have:
    
    	sample space	code space	sample time
    	------------	----------	-----------
    
    	    8 MB	   4 MB		 47.54 sec
    	    9 MB	   3 MB		 53.48 sec
    	   10 MB           2 MB          59.42 sec
    
    (1 MB of sample space gives you about 5.94 seconds of 44.1KHz 16 bit
    stereo samples.)  These are certainly adequate sample times for a
    versatile drum machine (remember, these are *stereo* samples!).
    
    2MB of code on a 68030 class microprocessor should be able to handle
    the control requirements of this machine.
    
    Again looking a few years out, 3.5" floppies should be able to handle
    4MB per disk.  This means three disks can fully load this machine with
    samples and operating code.  It'd be nicer if everything fit on a single
    disk, but....  In any case, the code would probably be on one disk, 
    and the samples on the others.  The machine should be on board battery 
    backed up, so it doesn't forget anything when you power it down.
    Given the amount of memory in this machine, this might not be practical.
    
    The machine should also include a hard disk interface.  It should be
    possible to load samples into sample memory one by one.  It may be 
    necessary to keep volume names (disk labels) in with the configuration
    information, so if a configuration is called up that requires a sample
    that's not currently in memory, the software can tell the user what 
    disk to find it on.  It should also be possible to save and load
    samples via the MIDI System Exclusive mechanism, perhaps using data
    compatible with the MIDI standard sample format under development.
    Note, however, that at the 4KB/sec maximum transfer rate (assuming no
    overhead at all) of the MIDI standard, 12MB would take about 3000 
    seconds, or 50 minutes!
    
    The machine has 17 stereo outputs: one for each voice, plus one mix
    of all voices.  A voice's participation in the mix output can be
    controlled by the use of the corresponding individual output, or can
    be set on or off independent of the use of the individual output.
    See the "mix mode" parameter below.  The voice can be panned across its
    individual output or the mix output.  In the center pan position,
    the stereo image is centered.  As the voice is panned away from the
    center position, the stereo image shifts and becomes increasingly 
    focussed, until at the extreme left and right pan positions, the voice
    becomes monophonic at the extreme limits of the stereo stage.  In
    addition, the voice can use the stereo sample in stereo or three
    different flavors of mono (left only, right only, left plus right).
    Note that these mechanisms allow for "stereo" samples to actually be 
    an uncorrelated pair of mono samples, thus increasing the number of
    onboard samples if stereo is not required, or to allow use of the
    left and right samples separately, thus providing two subtly different
    versions of the same sound for timbral variation (e.g., left and right
    hand sticks striking the same snare drum).
    
    Regardless of the module(s) employed to play a particular sample
    for a voice, the voice's output will always be routed to the correct
    individual output (i.e., they are *voice* outputs, not module outputs).
    
    The voice specifies the pitch at which the sample is played.  This
    pitch can be specified as a MIDI note number or as a frequency.
    The latter can be specified to 6 digits of precision (i.e., 1 part in 
    10^6).
    
    Each voice responds to its own combination of MIDI channel number and
    MIDI note number.  A voice can choose to ignore MIDI NOTE OFFs (always
    playing the full length of the selected sample, unless the assigned
    module is reassigned before it complete), or it can respond to note offs
    by truncating the sample with a specified "release" time.
        
    Voices may be statically assigned to a particular module, or may be
    dynamically assigned to any module currently available (i.e., not 
    currently playing a sample).  When the assignment is static, the module
    number (01 .. 16) is specified; when the assignment is dynamic, the
    maximum number of modules that may be assigned to the same voice
    (01 ..16) is specified.  If no modules are currently available
    for dynamic assignment, the module of the lowest priority voice
    "farthest along" in playing its sample is preempted (the idea being
    to not penalize modules for playing a long sample).  Static assignment
    of multiple voices to the same module is used for sounds that necessarily
    preempt one another (e.g., closed and open hihat).  The default assignment
    mode is dynamic with a limit of 1 module.  Higher limits may be set for
    long decay sounds that naturally "overlap" (e.g., ride cymbal or snare).
    
    (An additional option might be for a module to support multiple 
    "pointers" into one or more samples, and add the samples together
    in real time.  The design proposed here does not implement this
    feature.)
    
    When a voice is selected by the appropriate NOTE ON on the appropriate
    channel, the voice's sounding may be delayed by a specified amount.
    The delay time may be specified in terms of absolute time (.001 to
    9999 msec) or in terms of MIDI clock ticks.  Delays of less than 1 MIDI
    clock may be expressed as a decimal fraction (e.g., .001 .. .999) or as
    a reciprocal (e.g., 1/99 .. 1/2).
     
    Thus, each voice has the following set of parameters that determine
    the voice's sound and behaviour:
    
    	sample id 	   - 00 .. 99
   	pitch     	   - 000 .. 127 (MIDI note number),
    			     20.0000 .. 9999.99 (frequency in Hz)
    	output level	   - 00 .. 99
    	MIDI channel	   - 01 .. 16
    	MIDI note number   - 000 .. 127
    	ambience	   - stereo,
    			     left sample only (mono),
    			     right sample only (mono),
    			     left + right samples (mono)
    	pan		   - -50 .. +50 (-50 -> hard left, +50 -> hard right)
    	mix mode	   - not in mix,
    			     always in mix,
    			     in mix if individual out not used
    	module assign mode - always use module 01 .. 16,
    			     dynamically assign up to 01 .. 16 modules
    	assign priority    - 01 .. 16 (higher number means higher priority)
    	delay		   - .001 .. 9999 msec
    			     1/99 .. 9999 MIDI clock ticks
    			     .001 .. 9999 MIDI clock ticks
    	note off mode	   - .001 .. 9999 msec (release time),
    			     ignore
    	    
    A set of parameter values for all 16 voices is called a "kit".  128 kits
    may be defined, corresponding to MIDI patch change numbers 000 .. 127.
    Kits may be selected by MIDI patch change commands issued on the
    machine's patch change channel, which may be set to any MIDI channel.
    Kits may also be selected from the front panel.  A kit is ready to go
    the moment it is selected, unless it employs samples not currently
    in sample memory.  Currently assigned modules will continue playing
    their samples to completion, unless they are preempted by a voice in 
    the new kit.  If a kit employs samples not currently in memory, the user
    is prompted for the disks on which the needed samples are to be found.   
    
    Designing a user interface to all this functionality that fits within 
    the confines of a single height rack unit was a challenge.  However,
    I believe I have a proposal that works.
    
    The front panel of a single height rack unit has an area 1.5" high by
    17" long to work with.
    
    At the left end of the unit are two rows of 8 pushbuttons.  These are 
    the voice select buttons.  Each is a 1/4" square illuminated momentary
    contact pushbutton.  In PLAY mode, each button lights when the 
    corresponding voice receives a NOTE ON.  In VOICE EDIT mode, the button
    for the voice being edited lights up.
    
    The buttons are mounted on 1/2" centers horizontally, separated by 3/4"
    vertically.  This is a compact but usable configuration.  The entire
    voice select button section uses 4" of the panel width.
    
    To the right of the voice select buttons are two (vertically arranged)
    1/4" square buttons labeled AUDIT and FUNCTION.  The AUDIT button is
    momentary contact, and in conjunction with one or more of the voice 
    select buttons causes the selected voice(s) to sound.  The AUDIT button
    and the voice select buttons are all easily within a single hand's span.
    This feature (auditing a voice) is *always* available, regardless of the
    machine's mode, including while it is playing or while a voice is being
    edited.  It can, however, be disabled.
    
    The other button of the pair, FUNCTION, is an illuminated button; it is
    used to go to the top level menu.  More on this later.
    
    Next is a 2" long data entry slider for rapid traversal of a space of
    data values.  Below the slider is another 1/4" square button labeled
    ENTER.  It is used to enter a data value; until ENTERed, a data value
    is temporary and will be "forgotten" if the cursor is moved off its
    parameter.
    
    Next are four 1/2" square cursor moving and value changing buttons;
    the "<-" and "->" buttons are used to move from field to field within 
    a form, and the "^" and "v" buttons are used to increment/decrement
    values.  When held continuously, these buttons cause rapid changes.
    The -> and <- buttons "wrap" across lines as you'd expect, and across
    pages of a long form.
    
    Next is a 3 3/4" wide by 1 1/4" high dot matrix/alphanumeric display.
    This should be easily read in the dark.  This size should accommodate
    4 lines of 24 characters.  This display, the data slider, and the
    cursor/data buttons are the core of the user interface.  The interface
    is structured as a series of forms.  Forms that don't fit into the
    4 line by 24 character available real estate are structured into pages.
    A form is a series of fields.  Each field has a label and a value.
    When a field is selected for editing (by using the -> and <- buttons),
    its label blinks.  When a field's value has been changed (by using the 
    data slider or the ^ and v buttons), its value blinks.  ENTER causes
    the value to be written to the field, and it no longer blinks.  Moving
    to another field before ENTERing a value leaves the old value unchanged.
    A special kind of form is a menu, whose fields have only labels and
    no values; the labels are themselves values.  On menus, the ^ and v
    buttons work like the -> and <- buttons, except they move the cursor
    vertically instead of horizontally.  For a menu, the data slider also 
    functions like the -> and <- buttons.
     
    Finally, at the right end of the unit is the 3.5" floppy drive, its 
    eject button and an "in use" light.
    
    The power switch (if any) would have to go on the back.  The unit is
    obviously powered up if the display is nonblank.
    
    The back of the unit has 17 pairs of audio outputs, MIDI IN, OUT and
    THRU connectors, and a hard disk connector.
    
    The unit powers up in PLAY mode.  The display shows:
    
    	..........................
    	.MODE: PLAY              .       
	.                        .
    	.  SELECT VOICE TO EDIT  .
        .                        .
        ..........................
    
    Hitting any *one* of the voice select buttons sets the mode to EDIT
    VOICE PAGE 1 for that voice.
    
    	..........................
    	.MODE: EDIT VOICE nn    1.
    	.SAMP: nn aaaaaaaaaaaaaaa.  sample number and 16 character name
    	.MIDI CH: nn NOTE:nnn aaa.  channel, note number and name
    	.DEL:nnnn aaaa MIX: aaaaa.  delay and mix mode
    	..........................
    
    	..........................
    	.MODE: EDIT VOICE nn    2.
    	.PITCH:nnnnnnnHz REL:nnnn.  or PITCH:nnn aaa, release time
        .LVL:nnn PAN:snn AMBI:aaa.  aaa = L/R, L , R ,L+R
    	.ASSIGN: aaa nn PRI: nn  .  assignment mode and priority
	..........................
    
    Hitting the FUNCTION button gets you to the top level function menu.
    
    	..........................
    	.FUNCTIONS              1.
    	.PLAY        EDIT VOICE  .
    	.LOAD SAMPLE LOAD VOICE  .
        .            SAVE VOICE  .
    	..........................
    
    	..........................
    	.FUNCTIONS              2.
    	.EDIT CONFIG EDIT GLOBAL .
        .LOAD CONFIG LOAD GLOBAL .
    	.SAVE CONFIG SAVE GLOBAL .
    	..........................
    
    In Function mode the default selection is PLAY, so hitting FUNCTION
    twice gets you back to PLAY mode from anywhere.
    
    This is as much as I've figured out so far.
    
    len.
    
    

    Make sure you include some type of an RGB connect for an external
    monitor, Len.  This thing looks complex enough to need it. 

    Also, if you're going to really build a system out of these modules,
    you may want to allow for some type of a bus interface between the
    things, so that MIDI bandwidth could be conserved. 

    As a general comment, I would not be surprised to see more systems take
    this kind of bus approach in the future - similar to the Korg M1/S1,
    but more VAX-like in actual implementation.  For example: 

	Default System Config:
	  xyz CPU
	  4 Mb memory
	  1 400 mb 5<" hard drive
	  1 4 Mb floppy/firmy
	  2 stereo I/O adapter
	  1 MIDI I/O adapter
	  choice of 1 synth method (see below)
	  RS232/workstation I/O port w/monitor

	Additional H/W Options:
	  xyz CPU modules (let's say up to 4)
	  4Mb memory modules
	  additional disk interfaces
	  stereo I/O adapters
	  MIDI I/O adapters
	  stereo sampling interface
	  pad/pen interface
	  DECnet 8-)

	Additional S/W Options:
	  FM
	  Waveform
	  Resynthesis
	  Additive
	  Software "bus" (allows combinations of above methods)
	  Sample editors
	  Goodies (you decide)

    Of course, a monitor would be required for live use.  If you could get
    a big system in a BA123 cab size, it would be nice. 

    A somewhat more ridiculous requirement would be that everything fit in
    one rackspace and weigh less than 5 lbs.  &*} 

-b

    The RGB display output is a nice idea that I'd overlooked.  In it
    goes.
    
    I had considered a buss to interconnect the 4 different units (sample
    player, recorder, editor and sequencer) but forgot to mention it.
    It would also make it possible to share the disk drives among the
    units.  I assumed the sample player would be the core or first unit
    acquired.
    
    Hmmm...two more big connectors to go onto the back panel.  I could
    always go to stereo jacks for the audio outputs, I suppose.
             
    len.
    

    A rack-mount half-high hard disk could 'serve' multiple modules
    if each were equipped with a sexy (isn't that how YOU pronounce
    'SCSI'?) port.. SCSI allows up to 7 connects on a single cable.
    So the hard drive could be at the bottom with the removable cable
    assembly running up the back of the modules.
    
    Gosh, len, one would think you'd given drum machines some thought!
    Actually I'm looking at your menu interface.. it looks close to
    the Kurzweil's 8-button user interface, which is so confusing, since
    there's SO many submenus, that it's effectively kept me from doing
    any sample tweaking on my own.
    
    The Emax, on the other hand, virtually invites fiddling, since there'
    s (thanx EVE, you bitch!) one button per main menu, and most of
    the menu choices are silkscreened on the front surface. All of these
    cost space, I understand, and more hardware switches instead of
    software switches..
    
karl, looking forward to another HOT weekend (no, not THAT kind)

    Well, the tradeoff is between front panel space and a "concise"
    user interface.  The incorporation of an RGB output will help some,
    as that gives you a lot more display real estate, but there's still
    the "input effector" problem.  Again, Roland offers an escape -
    provide a mouse input as well as an RGB output, but that only appeals
    to the "point and grunt" types.  Still, then you could have real menus
    with noncryptic labels.  But, you need a place to scoot the mouse,
    not exactly convenient with a road-oriented rack mount unit.
    
    My proposed design was driven less by a goal to minimize hardware
    switches than to minimize size - the 1 rack unit high constraint
    is a humdinger.  I'm not even sure if all the necessary electronics
    could be made to fit in such a package (but then I remind myself
    of the SRV2000).  Maybe I should just concede and go to a 2 high
    unit.
    
    Trashing the floppy drive and making it (or a hard drive) a separate
    unit is a reasonable alternative.  I also think it might be desirable
    to provide a real volume control on the front panel, although a machine
    like this assumes a real mixing board out there somewhere.  That's why
    I dropped the idea of onboard EQ and effects.  There was also the notion
    that such things might be better done at sample capture and edit time,
    leaving the drum sample player "lean".  The situation with a "simple"
    sample player's not quite as bad as with a sample editor; still,
    I've got 11 (!) first level menu/forms, and I'm sure I haven't
    considered everything yet. 
                                                                            
    len.
    

Nice Len.  [B+, next time show all your work]

I wouldn't think that current rack mount designs use 1/2/3 rack spaces due to
user interface considerations.  Probably more for thermal reasons - 12 MB of 
DRAM may need more than 1 rack space for cooling through convection.

Why limit this unit to a drum sample player?  A few more software features
would make for a general purpose sampler as well.  Of course, that might
prove confusing from a marketing standpoint [wasn't it me who complained
about adding features around an architecture?].  Ok, so we compromise. 
The hardware is called a 'Digital Sample Player' and you have your choice
of operating systems that you can run with (Percussion or General Purpose).

'nother feature I don't remember seeing was some sort of sample switching
as a function of velocity.  IE, fire the rim_shot sample if MIDI velocity
is 0-63 at velocity = (2 * receive_velocity), or fire a snare sample if
velocity is greater than 63 at velocity = [2 * (receive_velocity - 63)].

OK, OK.  I concede.  You don't have to be 'President'.  How about settling
for Ambassador to Japan?

Todd.

    Well, yeah, the fundamental way this thing differs from a fully
    general sample player is really only in the layout of its "splits".
    Once you start thinking about "pitched" or "tuned" percussion sounds
    (e.g., tabla tarang or a set of concert toms), then you want the
    note numbers to affect pitch rather than having to allocate a voice
    per pitch.  So you want to be able to map any contiguous set of
    note numbers on a channel to some other set of note numbers specifying
    the playback pitch of some sample.  In the limit, you have an
    associative memory mapping key numbers arbitrarily to samples and
    pitches.  You really don't want (necessarily, although who knows
    with aggregate sample times exceeding one minute) a voice per key,
    so you need some concise way of specifying "this voice plays this
    sample in response to these NOTE ONs, and plays these pitches
    corresponding to those NOTE ONs".  Another possibility is to
    interpolate between multiple samples as a function of note number,
    as Todd suggested earlier.  This way you could encode timbral
    variations via note number or velocity (the latter being a
    generalization of the velocity based switch).  Etc..
    
    And yeah, I wonder about a one high rack's ability to dissipate
    12MB worth of heat.
    
    len.
    

    > and yeah, I wonder about a one rack high's ability to dissipate
    > 12 mb worth of heat.
    
    Now introducing the Fehskens-1; the world's first WATER-COOLED drum
    machine!
                         

    I was going to suggest heat-pipes for cooling the system ("Hey,
    Bill, what's this big fin sticking out the back of your rack???")
    
    Now... trash everything about programming this monster from the
    front panel, except kit selection. It'll save A LOT of real-estate.
    Use a computer over MIDI (isn't that *why* we have it?). Sell an
    optional programmer module for the computer-phobic.
    				- HBM