Conference napalm::commusic_v1

    
>Ok. How do you get a "slur" with a midi controller?
>sorry. Pitch bend is not controllable. Try again...

	My Dx7 has both "poly" and "mono" modes of operation.

	If I'm in "mono" mode and strike a key, I get an attack.
	If I hold that key down, then hit another key, I get
	the new frequency but without the attack. This is pretty
	slur-like. I don't recall if I tried portamento as well,
	this experiment was a long time ago, but I would reckon 
	it works (by setting the potra time, you can control the 
	speed of the slur).

	This causes other problems, of course. As you know, 
	the envelope is an important component of a sound's 
	timbre. Some of the Dx7 patches were really "sabotaged"
	by this lack of attack envelope (i.e., the transition
	didn't sound "natural" or even good). But this isn't 
	the fault of MIDI; this has to be corrected by proper
	voice and/or synth design.

	This is still kinda restrictive (only one note per keyboard),
	but its the only thing I can think of now. This would be less
	of a problem with the multi-timbral synths (that's it! more hardware!)

	I am wondering how these "multi-timbral" MIDI synths handle 
	mono/poly operation. That is, can you put some voices in 
	"mono" mode (to be slurred) and others in "poly"? If so, then
	it seems to me you could do pretty well under computer control.

							Scot

    The DX21 allows you to split the keyboard and have either/neither/both
    patches in mono mode.
    
    Slur rate is controlled by portamento.
    
    If I wanted to bend 1 note in a chord, I'd split the keyboard and
    put the same patch on both ends. Put one patch in MONO. Play
    chord minus bending-note on poly side. Play bend notes (ya gotta
    use at least 2) on mono side.
    
    Edd

    	The Korg POLY-800 offers single/multiple triggering.  Of course
    it had to in its price-reduction scheme - it only has a single filter
    for all of its voices.  So in single trigger mode, you have the
    previously described slur effect.  In multiple trigger mode you
    have the new attack on each note but it is always possible that
    it didn't complete its filter envelope.  Something to get used to.
    
    	Dan

    
    The Korg effect is what I was after, but its side-stepping
    the issue: what info goes out the midi port that means
    "single vs. Multiple"?
            
    Re-read the spec last night. It seems that it's possible
    to get slurs as Scot points out: as a 'side effect' of
    mono mode. 
    
    The problem is that the single voice that has it's note
    on and gets a new note on command can react in 3 ways:
    
    	1. Ignore it	(not sure anyone *actually* does this)
    	2. play new note without attack (aka single trigger)
    	3. play new note with attack	(aka mult. trigger)
    
    There is no direct unambiguous slur/tongue info in the
    Note-on command. What you get is whatever was implimented.
    
	rsquared
    

    I'm not sure I would label this as a flaw in the MIDI protocol.
    MIDI is a gestural protocol (it sends and receives messages
    that describe a user's inputs to a set of performance controllers).
    As such, slur control is not in the domain of discourse for the
    protocol.
    
    It would be nice if a computer sequencer package came out that
    allowed you to define two envelopes, one with and one without
    an attack.  Then when a sequence somehow indicated 'slur now',
    the seqeuncer would automatically send out a program change
    or some such to remove the attack.
    
    -jim

    re -1...
    
    MIDI is a 'gestural protocol'.
    
    Just a second, let me write that down

    Well, "flaw" was just to get peoples attention.
    
    Since a slur is a gesture of playing nuance,
    it should be handled by a "Gestural Protocol",
    whatever that is.
    
    The sequencer functions you alude to could 
    also be handled through the protocol alone.
    
    ron
    

>    < Note 506.5 by NOVA::RAVAN >
>    It would be nice if a computer sequencer package came out that
>    allowed you to define two envelopes, one with and one without
>    an attack.  Then when a sequence somehow indicated 'slur now',
>    the seqeuncer would automatically send out a program change
>    or some such to remove the attack.

	Yes, Yes, Yes! This would indeed be a useful feature, 
	and should be possible, at least on the Dx7. The Dx7
	is implemented such that any patch changes you issue
	take place on the next note played. At 31.25Kbaud,
	you should be able to load the EGs fast enough, even
	between rapid 8th notes. 

	Has anyone tried this, either with a commercial sequencer
	or custom software? How'd it work?

						Scot

    re: .8
    
    Scott, are you refering to actually "editing" the eg of a particular
    patch via sequencer or, selecting a second patch with a "pre-edited"
    envelope?
    
    Choice 2 is easy. Tell me more about choice 1....
    
    Edd

    OK, I admit it, I made up the term "gestural protocol".
    (I can see it now, frantic little electrons scampering down
    MIDI cables all waving their little gluon arms in complicated
    patterns... :-))
    
    What I mean is that the MIDI protocol only encodes positions of
    sliders and pitch wheels, whether keys are pressed or released...
    things like that, which are all gestures that a performer makes
    at an instrument.  It makes no attempt to encode anything about
    "music", just "controllers".
    
    I agree that the protocol could have handled slurs.  It could have
    handled lots of useful musical information.  But my point is that
    the folks who designed MIDI were probably not interested in encoding
    musical information, but instead were interested in encoding their
    controller information (so that THEIR synthesizer could be used to
    control all those other inferior synthesizers).  Therefore, all this
    "music stuff" is not there.
    
    And even as a "protocol of gestures" (hence a "gestural protocol"
    [geez, you guys, I still like the term]), it has defencies.  For
    instance, no "ident sequence", that is, the ability to interrogate
    the network and find out who is there.
    
    -jim

    
    I have found, using Deluxe Music Construction Set (no snickers,
    please), that sending a "program change" on a staff in which
    a previous note is still in release, produces annoying gleeks,
    glurks and oohmps on my DX7.  I imagine that sending an entire
    patch could only be worse.
    
    David
    

    There you go again, slagging off on poor MIDI.
    
    .. sounding like a bunch of hardware-and-network-savvy computer
    professionals instead of a bunch of nerdy geeky musicians who
    ought to be GRATEFUL that you didn't have to wait 4.85 years
    for [them] to get it right, and that one can address 16 independent
    devices/channels using just ONE cable with funny ends...
    
    

<Note 506.9 by JAWS::COTE>
>    ...are you refering to actually "editing" the eg of a particular
>    patch via sequencer or, selecting a second patch with a "pre-edited"
>    envelope?
>    Choice 2 is easy. Tell me more about choice 1....

	Ok, Edd, more about choice 1 (which is what I was talking about).

	I'm sure many people recognize the value of being able
	to alter the envelope in certain ways "in real time."
	One simple example is the Keyboard Rate Scaling implemented
	by the Dx7, which alters attack parameters in proportion 
	to key position. By the way, assume through this note that
	I'm talking about a Dx7. It's all I'm familiar with; hope
	this applies to most other MIDI synths...

	I think certain sounds could be more realistic and musically
	flexible if we had even more real-time control of parameters.
	The Envelope Generators, for example. 

	Now for some approaches to implementing this.

	<Note 506.11 by JON::LOW> notes that changing over to 
	a different patch "glitches" the sound. Very true, 
	and Very unfortunate. This is why "program change" 
	is fairly useless in general.

	HOWEVER, You CAN play a voice on the keyboard while in "edit"
	mode. You can change algorithm, operator frequency, EG parameters,
	etc. - all without glitches. The only "catch" is that the
	parameter change does not take effect until the next note.
	This prevents you from doing things like manual frequency 
	sweeps while sustaining a note, but in most cases I think
	this is the proper thing to do. 

	Now, there is a mode called "System Info Available," which is 
	supposed to allow patch and function info to be passed around.
	There are also MIDI codes (which are executed in this mode)
	to push any button you can push on the Dx7 console.
	Computer-controlled patch editors do this all the time.
	
	So, it seems to me what we need are two enhancements - One
	to the Patch editor and one to the Sequencer. Instead of
	simply storing a single set of parameters for a single voice,
	our Extended Patch Editor could allow us to define and
	store a number of possible "modifications" along with the base
	voice. One modification could be a group of EG parameters, 
	another could be a group of operator freqencies or output levels.
	Then, we could select these mods in our scores. Our 
	Extended Sequencer could then put the synth(s) into System Info
	Available/Edit mode, and pump out the data, sending the edit
	info just before it is needed!! This should produce the desired
	mod without glitches, so long as the data can be completely sent
	before it is needed.

	Let's see. Some rough calculations for changing a single EG:

	31.25Kbaud = 3125 bytes/sec

	About 2 bytes/midi_command

	8 parameters (midi_commands)/change

	   sec         2 bytes     8 command
	----------  x  -------  x  ----------   = 5.12 mSec to load the change
	3125 bytes     command     change

	Now this is transmit time. I'm not sure how long it takes
	the Dx7 to execute the stuff it receives. I'll take a SWAG
	(Scientific Wild-Assed Guess) and say the total time comes
	out at 6 milliseconds.

	This is probably fast enough for most situations. Actually,
	if an entire Dx7 patch is 144 bytes (I seem to remember that
	figure from somewhere), this would take (assuming 2 bytes of
	MIDI command to change each parameter) about 92 mSec (100 mSec
	with SWAG). A bit slow, probably slower than "program change",
	but on the other hand is GLITCHLESS!

	What do you think? Anybody implemented this sort of thing?

							Scot
	

    re everything, even though i've lost track of who said what:
    
    mid-note program changes:  it depends on how fanatical the engineers
    were, and what they thought was important.  You can look at program
    changes as analogous to timbre changes on a real instrument, e.g.,
    stuffing a mute into the bell of a horn.  In this case, you might
    say, "well, you can't do this in real time, so we can assume that
    notes will not be sounding when program changes are executed".
    This ignores the fact that you can stick a mute in the bell while
    sounding a note, but it's the cheap way out, so it gets done a lot.
    
    Basically, it's been my experience that one of four things happens,
    depending on the synth:
    
    	the old note cuts off, and nothing happens until the next note
   	on, which plays the new program.  Always glitches!
     
    	the old note continues, and the program change does not take
    	effect until the next note on.  May not be meaningful
    	polyphonically (i.e., turns into next case), unless synth is
    	multitimbral (i.e., same as monophonic case).  Does not glitch
    	monophonically.
    
    	the old note continues, but the new program begins immediately,
    	(re)triggering its envelope.  Probably glitches, given new attack.
    
    	the old note continues, but with the new program continuing
   	from the same place in its envelope.  May glitch depending on
  	envelopes.

    These are progressively more difficult (i.e., expensive) to do.
    Because most synths do not do useful things with program changes
    received while a note is sounding, I send program changes during
    rests or if that's not possible, resort to multitracking.
    
    I disagree that program changes are "useless"; think about the issues
    and you'll agree that the problems "go with the turf".  They are
    certainly useful at the beginning of a part or track, and if you
    got the rests available, can be useful in midpiece.

    It was my impression that slurs and portamentos are not the same
    thing.  A slur is a tie between two notes of different pitch.  I
    suppose in that regard a slur could be viewed as an "instantaneous
    portamento".  I think a portamento is notated differently, as is
    a glissando (like a portamento, but not continuous; a glissando
    passes stepwise through all the intervening pitches).
    
    My SuperJupiter handles slurs very nicely; you just send the note
    off for the first note *after* the note on for the second note,
    and set the SuperJupiter's envelopes to single trigger or
    "non-retrigger".  In this mode, the envelopes do not trigger unless
    there are no notes sounding when the note on arrives.  While the
    POLY-800 provided this feature because it *had to*, the SuperJupiter
    provides it because it *can*.  I'm surprised that this feature isn't
    provided by most synths; neither of my CZ-101 or Juno-106 provide
    it, but the MIDIBass does (no choice; as it's monophonic, it's *always*
    in single trigger mode).  The CZ-101 does something different with
    portamento depending on whether it's in POLY or MONO mode, but I
    don't recall exactly what or whether it extends to the envelopes
    as well.

    
    	I've been using my notation-based Professional Composer to
    drive my sequencer (Performer).  Some of the notations get translated
    into sound, others are ignored (pedal markings, up/down-bow, etc.).
    
    	I was pleasantly surprized to discover that they actually
    process slurs.  Just like Len mentioned about the Super-Jupiter,
    a slurred note's duration will be extended beyond the attack of
    the next note.
    
    	A portamento is a glissando.  A slur is a slur, or in the case
    of instruments which cannot turn off their attack (e.g. piano),
    a slur is also a phrase marking.
    
							- Karl

I have been thinking about this "limitation" stuff for a long time.  I was 
gonna start a more general note along the lines of "MIDI synth gripes"...
I think I will.

Maybe we have to perform these midstream program changes because the 
instruments we are using force us to do that to get the sound we want.
IE: If a program change is necessary for creating a particular sound, 
our synth is not powerful enough.  This is not MIDI's fault.

The point:
I think our gripes in this note address synth limitations, not MIDI 
limitations.

Todd.

    I think Todd hit it right on the head. With system exclusive MIDI
    commands available it's mostly a matter of the synth not being able
    to do what you want. My biggest gripe with most digital synths is
    that you have little or no real time control of the sound. I miss
    being able to grab a pot and sweep a filter in real time like I
    could with my ARP 2600. But, on the other hand I would never go
    back to having to enter patches by hand every time I needed to recall
    a sound.
    
    On the subject of how synths should handle patch changes, the new
    ESQ-1 from Ensoniq does this very nicely. Any notes that are sounding
    when a patch is changed continue to play that sound until they are
    released. Probably an expensive feature but very desirable I think.
    
    Rob

    Whew. 
    
    I concur on the opinion that we are talking about
    what the end synth will or wont do.
    
    In the slur case (and other performance actions) you are
    apparently at the mercy of the synth interpretting the midi
    stream to do what you intend. A similar situation exists
    for program change or system exclusive messages "mid-piece"
    (while there are active note on's).
        
    Note that program change should be sufficient for changing
    voices live IF the synth has enough preset storage and you have
    PREVIOUSLY (not real time) set up the voice to your satisfaction.
    
    Then you hope midi protocol can transfer enough information about
    the execution of the notes, whether live or sequenced, to get the
    playing nuance you desire.
    
    But the answer is still "yes, or no, or maybe". 

    ron    
    
    preset sounds     

    re; 16
    
    	I have no reason to doubt you, but that's sure not the way
    the word 'glissando' is commonly used.  In fact, I can't recall
    the last time I saw the word 'portamento' in a score.
    
    	Xenakis refers to his smooth, non-scalar er, um, 'glides' as
    'glissandi'.  Same for the Polish school.  So, maybe I'm wrong.
    Or, maybe the textbooks haven't caught up with current usage.
    
    						,km

    Since we're discussing midi oversights.....
    
    I wish that my 707 would do those nice cymbol "swells" that a real
    drummer can get using a soft touch or those funy sticks with the
    felt balls on the end....you know where the cymbol starts out soft
    and gets gradually louder but with no "attack"
    
    dave (who needed cymbol swells this weekend)

    
    Ahhhh, what amounts to a 'roll' with a cresendo.
    "funy sticks with the felt balls..." are called
    mallets. They come in various felt hardness gradations.
    
    What does midi have to do with this? Sound generation
    is a function of the sound generator.
    
    Ron-who-used-to-be-a-drummer
    

    Right, and this is exactly analogous to the slur "problem", as it
    has to do with retriggers.  Somewhere else I explained the problem,
    but I'll do it again briefly.  A real cymbal continues to sound
    after you hit, even if you hit it again.  It is the stacking up
    of these later parts of the sound that contributes to that swell
    sound (:^)) you get when you roll on a cymbal.  A sampled cymbal
    in a drum machine truncates the previous sound when you hit it again,
    so the late part of the sound never gets to add up.  It's not a
    MIDI problem, it's a cymbal sound generator problem, and it won't
    be solved until memory becomes even cheaper and designers are willing
    to throw hardware at it.  It's even apparent on an ordinary ride
    beat; I think it's a large part of the reason drum machines cymbals
    sound so patently fake.
    
    len.
    

>    in a drum machine truncates the previous sound when you hit it again,
>    so the late part of the sound never gets to add up.  It's not a
>    MIDI problem, it's a cymbal sound generator problem, and it won't
>    be solved until memory becomes even cheaper and designers are willing
>    to throw hardware at it.  It's even apparent on an ordinary ride

I think it's more of a hardware limitation than a memory limitation.  If
the processor in the average drum machine had more horsepower, it would 
be able to implement multivoice cymbals based on a single cymbal sample,
much in the way a Mirage can play n voices of the same sample at a single
time.  This would still require the same amount of memory.

I still think that cymbals (on a drum machine) could be made to sustain 
longer by utilizing looping with graduated (over time) level suppression.
Of course to sound right, the loopback point should be very close to the
end of the sample...

Todd. (who_now_realizes_that_this_probably_belongs_under_a_seperate_topic)

    Can't you get that effect on a sampler with a separate VCA envelope?
    You could use the looping to "stretch" the sample long enough to
    apply the envelope to it; the envelope would have "instantaneous"
    attack, and a long decay to a 0 sustain level.  The release could
    be short to simulate a "choked" or damped (e.g., by hand) cymbal.
    It seems to me that it would be shortsighted to lock the looping
    parameters and envelope parameters permanently together.
    
    And you're right, the problem with cymbal triggers is not memory
    but hardware - you have to do a whole bunch of adds from multiple
    places within the sample in one output conversion time.  Nowadays
    fast adders are no big deal, but they do cost a little more than
    circuits that have no adders at all.  You'd need a little hairier
    control algorithm as well, capable of keeping (OK, let's see - 16th
    notes at 160 bpm = 640 attacks/minute = about 11 attacks/second,
    so a 4 second decay means keeping about 44 pointers around and doing
    44 adds per output, and a 30 KHz conversion rate to get 15 KHz
    bandwidth necessary for good cymbals means 33 usec per conversion,
    or an add (at least 8 bits, and probably 16) in .75 usec - certainly
    possible!) well it's all back there.
    
    Someday, somebody's gonna do sampled cymbals right...
    
    len.
    

    Sounds like someone needs to design a drum machine that uses a very
    powerful micro 68000 or 68020 maybe and to pay attention to these
    type of details......oh boy I can see it now the new LenDRUM for
    only $1799, but don't balk at the price the cymbols sound right...
                                           
    dave

    This discussion appears to have moved to its own note on Sampled
    Cymbals.
    
    len.