Conference napalm::commusic_v1

    The volume arena has never been clear, and you will find
    that they all are different. The midi continuous controller
    definition is fine....and folks have 'agreed' to allocating
    the same controller number to volume...but thats it.
    
    Your unit MAY send it on power. It WILL send it if you nudge
    it. Your module may SAVE the current volume setting on power
    off and restore it on poweron, or not. The panel control may
    override the messages, or may be the MAX volume that the 
    messages are scaled to...or not.
    
    It shouldnt be too hard to test tho....
    
   

    In general (that is to say, you can't depend on this) MIDI continuous
    controllers only send messages when they are moved.  A pitch-bend
    that is not swung sends no messages (and takes up no MIDI bandwidth,
    that's why it's done this way).
    	
    You might want to look in the MIDI implementation chart for the
    module and see if it implements VOLUME as a recieved controller.
    Your controller almost certainly implements VOLUME as a transmitted
    controller.
    	
    	-Bill
    

	The MIDI implementation chart is VERY scarce for information (as is
most manuals I've ancountered.  It simply says it implements MIDI volume.

	As far as simply checking it at home - I entered this note as a kind
of 'save face' attempt before I brought it in to the shop (Wurly's).  If I
had thought of it before this morning, I would have checked it.

	Still, it is interesting (if not frustrating) that such continuous
controllers are not standardized by the MIDI spec.  Are there any continuous
controllers that ARE set in concrete (I'd think pitch bend, modulation and 
aftertouch are...)?

	Dan

    I don't think that the precise effects of any of the MIDI messages
    are specified in the spec.  That is, how to react to and how to
    generate MIDI messages is essentially a function of what the
    manufacturers think are the appropriate behaviours--we all know
    what pitch bend is, now don't we? (ha ha.)
    
    The same is true of many programming languages--eg, how should you
    evaluate IF a() AND b() THEN foo() END;
    
    Steph
    

    My experience is that you have to diddle just about everything before
    a controller takes effect. To reduce ( and I mean seriously reduce )
    the amount of MIDI traffic, it makes sense to only send changes.
    It is a feature, not a bug. Any other way would quickly flood the
    MIDI channels with irrelevent data. Can you imagine the overhead
    of sending bend, mod, volume, and sustain over, lets say, 6 channels?
    that's a little less than 100 bytes, that's about 3 ms. Figure about
    200 clock ticks/sec, that's 5 ms intervals, you've got less than
    2 ms to send any real data. Sheesh!
    
    The way they did it is just fine.
    
    							John.

    what language? Actually I see no ambiguity there.
    assuming:   a() has a value of 0 or 1
    	 	b() has a value of 0 or 1
		END means ENDIF
    
    then foo() will be evaluated if a() AND b() are both 1.
    
    There are some situations where the ambiguity requires specifying
    to the compiler exactlyl what you mean, usually with nested if/elses.
    
    I think we know what you mean.
    
    Well, what HAS happenned with cont. contr. messages is that theres
    a DEFACTO STANDARD that has arisen from the first implimentations
    of midi (methinks the DX7 won ). Altho the spec says its up to the
    manufacturers, certain controllers have been 'assigned' to functions.
    The following (at least!) have been 'agreed' to:
    Pitch bend, Volume, Mod wheel, sustain pedal, portamento time, and
    breath controller (can you see someone besides Yamaha coming out
    with an alternative Br. Control unit and NOT using the defacto code?
    what a blunder! har har!)
    
    what Im not sure about:
    	foot controller (for modulation etc),pan, sostenuto pedal,
    	portamento on/off (pedal or switch)
    
    any others?
    
    ron
    
    
    		

    Controller 10 is for pan, controller 6 for data entry.. 
    
    re the topic note, if you hear a module 'going away', just move
    the volume slider (#07) down and back up (to 127).
    
    So what's the problem ? 
karl, still scarred from his last wrangle with the KX88    

RE < Note 1293.7 by SALSA::MOELLER "conducting the Silicon Symphony" >

>    re the topic note, if you hear a module 'going away', just move
>    the volume slider (#07) down and back up (to 127).
>    
>    So what's the problem ? 

	Once again, I was entering an emergency note to avoid making a fool
of myself at the store (i.e., I asked here because I didn't have time to go home
and find out).

	Dan

    Re: .6
    
    Perhaps I'm making myself entirely too clear here, but you don't
    seem to understand what I am saying.
    
    The syntax of the messages is perfectly defined, and there are even
    labels for each of the valid messages.  These are listed below,
    for those who wonder.
    
    The semantics are not defined in the spec (as far as I know), and
    never will be.
    
    Take the example of pitch bend (which isn't strictly a continuous
    controller in the IMA sense)--nothing in the spec says that a pitchbend
    message should only be sent when a wheel changes positions.  It would
    be perfectly valid to transmit this message at every idle moment, from
    the spec's statement.  Further, there is no definition of how much
    detuning a voice should undergo for a particular pitch bend value which
    is received.
    
    The way the controller actually behaves on most availible equipment
    is a result of the prevailing opinion about how pitch-bend should
    operate.
    
    
    
    Midi Manufacturers Association continuous controllers:
    
    0	Undefined
    1	Modulation wheel or lever
    2	Breath controller
    3	Undefined
    4	Foot controller
    5	Portamento time
    6	Data entry MSB
    7	Main volume
    8	Balance
    9	Undefined
    10	Pan
    11	Expression controller
    12-15 Undefined
    16-19 General purpose controllers (1-4)
    20-31 Undefined
    32-63 LSB for values 0-31
    64	Damper pedal (sustain)
    65	Portamento
    66	Sostenuto
    67	Soft pedal
    68	Undefined
    69	Hold 2
    70-79 Undefined
    80-83 General purpose controllers (5-8)
    84-91 Undefined
    92	Tremolo depth
    93	Chorus depth
    94	Celeste (detune) depth
    95	Phaser depth
    96	Data increment
    97	Data decrement
    98	Non-registered parameter number LSB
    99	Non-registered parameter number MSB
    100	Registered parameter number LSB
    101	Registered parameter number MSB
    102-121 Undefined
    122-127 Channel Mode messages

    
    Steph

In the programming example, the question is what is the order in which a()
and b() are evaluated, and whether, if the first one is evaluated to be
false, the other one should be evaluated anyway.  When evaluating the
expressions can have side effects (as you have to assume any function call
does except in FORTRAN), this makes a big difference.  And different language
definitions do this differently.

    ah. hmmmmmmm, Im more a hacker, but:
        
    In what language would procedures (or even expressions) a(),b()
    NOT both be evaluated in the construct " IF a() AND b()....." ???
    They BOTH must be executed. ( They arent just static variables,eh? )
    Or was that your point?
        
    similarly, if a(), b() have some side effect, such as BOTH twiddling
    some GLOBAL variable, (ick! but maybe), you should still get repeatable
    execution, since both must be evaluated, right?
    
    You may be in for a surprise from the compiler....I agree.
    
    ron
    

    Re: .11
    
    I know this is off the subject, but...
    
    In the two programming languages that I know best, C and Pascal, this
    is very different. Pascal is "well behaved", both expressions are
    executed in left to right order. In C, this is not the case,
    expressions are not evaluated in any particular order, and there does
    not seem to be a requirement that all logical expressions be evaluated.
    
    pcv

    We're way off the subject, but unless a standard (e.g., ANSI or
    ISO) requires a specific implementation, a typical optimization
    is to not bother evaluating the second term of an AND if the first
    term evaluates to FALSE, as the AND can't possibly evaluate to TRUE
    no matter what the value of the second term.  Similarly, if the
    first term of an OR evaluates to TRUE, there's no need to evaluate
    the second term, as you already know the OR will be true.
    
    len.
    

    Thats fine ONLY if the terms are not expressions or routine
    calls, and I fully understand the technique.
    
    However, I have trouble believing that if they are routines
    (which they most closely resemble to my "C" eyes...) that a
    "CORRECT" run time optimization would be to skip calling 
     b() if a() returns false. (assuming a is evaluated first
    which is a compiler issue, not runtime).
    
    Time for some experiments, eh?
    

    According to the Pascal standard it can evaluate either A
    or B first, or it can even evaluate them in parallel!  If the
    value of the expression can be determined by evaluating one
    operand, the other operand need not be executed.

    If you've written a program in Pascal that depends on the order
    of evaluation of binary operators your program is at the least
    non-transportable.  Certainly, running it with optimized VAX Pascal is
    a crap shoot because VAX Pascal does a reordering optimization.
    
    	Dave Blickstein
        Architect, Language independent code generator/optimizer
    	Technical Languages and Environments

/*ok, a quick test in C */
    #include stdio.h

main () {
	if ( a() && b() ) {
	   c();
	}
}

a() {
	printf("executed a\n");
	return(0);
}

b()  {
	printf("executed b\n");
	return(0);
}

c() {
	printf("executed c\n");
}	
/*end test*/
        
    guess what? VAX C choses not to evaluate "b()". 
    I am humbled.......and amazed.
    
    Ron
    

     
    did you look at the generated code ?  is this the latest 2.3 compiler ?
    it seems to be having some serious optimization problems.
    
    _sjz.

>   Time for some experiments, eh?
    
    Understand that just because a particular C optimizer may not 
    eliminate the function call in "IF FALSE AND F(X)" does not
    mean that it's not allowed to, and thus may not do that when
    you install the next version.
    
    I think the best advice is derived from Len's comments: Do not
    write code that depends on the order of evaluation unless the
    order of evaluation is explicit in the operator (i.e. the language
    has flow operators like "and then" and "or else").
    
    In short, there's not much value in this experiment.  VAX C
    should eliminate the call btw.
    
    Unlike Pascal, in C you have two kinds of operators, boolean
    (and, or, etc) and flow boolean (in english, "and then" and
    "or else").  The regular boolean ops work pretty much like
    Pascal - order of evaluation is indeterminant and short-circuiting
    is permitted (operands may be eliminated).  The flow boolean
    ops guarantee that the right operand is not evaluate if the
    result can be determined from the left operand.
    
    	db

    Ron,
    
    That's not the interesting case.  You used the and then operator
    and thus C was FORCED not to evaluate b.  Try running it with the
    following line:
    
     	if ( a() & b() ) {

    
    	re .. the last few:-
    
    	Bleh !   This is s'posed to be an employee interests conference.
    Its startin' to look aweful  "work related"  :-^)
    
    

    I hope the reader (Dan, etc.) can see the connection between the
    last 10 replies and MIDI continuous controllers, because there is
    a strong one (I couldn't have made it better myself).
    
    The synth manufacturers know how continuous controllers should behave
    like programmers know how an IF statement should work.
    
    By the way, most languages these days specify ``short circuited'
    evaluation so that you can say:
       WHILE ptr # NIL AND f(ptr^) DO g() END;
    
    And not have the f(ptr^) chew on a bogus pointer.  Pascal is a notable
    exception.
    
    Steph
    

    
    re .21
    
    yeah !  I always hated that. _sjz.

    re, Dave:
    
    if ( a() & b() )  c();.... well, different. I see the point.
       in fact it gives: executes a executes b, which would have
       just added fodder (read:air) to my (original) position.
    
    no, the REAL interesting one is:
    
    if ( a(b()) && b()  )  c();
   
    executes: b,a,b	Now b() returned 0, so there was no reason
    			to execute it again....
    
    Before len jumps on us about thouroughness, I admit these are
    not 'robust' experiments....but results were interesting...
    

    
    and steph, I see your point, but disagree with your 
    conclusion. (Maybe its just wording...)
        
    My conclusions are that interpretation will vary when
    specifications are not complete. Interpretations are
    attempts to complete the specification.
        
    The midi spec completetly defined the syntax for continuous
    controllers. It did not define the assignment of functions
    to those controllers. That allowed the manufactures room
    for interpretation. We have seen that defacto standards arose
    based on the first implimentation(s).  
    
    Does anyone move a bend wheel and get any effect other than
    pitch change?

    They DO know what to impliment. AND, yes, the spec is still
    incomplete....

    Well, folks, welcome to the standards business!
    
    I guess there is a sort of MIDI-related message here, about
    interpretation of standards and opportunities for divergent
    (and probably incompatible or non-"interoperable") implementations.
    
    In the standards business (specifically the OSI stuff I am involved
    in) real users are forced to resort to "implementors' agreements",
    where they get together and figure out and agree on how a bunch
    of implementors should interpret the standard the same way, so things
    will really work together.
    
    len.
    

    excellent statements.
    
    See what we've learned here? What Len does...even what
    Blickstein does (no wonder he can moderate a coupla
    notes ;') ), we learned some C code, we learned about compliler
    optimization techniques, we learned about standards and specifications.
    
    Wheres that JEC form? I gotta add this to my job description.
    
    ron(who writes code that doesnt bite him, apparently...)

>    By the way, most languages these days specify ``short circuited'
>    evaluation so that you can say:

>       WHILE ptr # NIL AND f(ptr^) DO g() END;
    
>    And not have the f(ptr^) chew on a bogus pointer.  Pascal is a notable
>    exception.

    I am not aware of any DEC-supported languages for which this is true.  
    The list includes Pascal, PL/I, C, FORTRAN, BLISS, APL, Ada.  Also
    include Pillar and C++.

    Are these all notable exceptions too?  What languages are you 
    using Steph?
    
    Modula does guarantee short-circuiting but THAT seems to be the
    exception.
    
    I think you will find that most languages, particularly modern
    languages,  specifically do NOT do this because it inhibits 
    optimization.  Most modern languages that provide short-circuiting do 
    so explicitly via "and then" and "or else" operators.

    	db

    VAXLISP specifically DOES use the above short-circuiting:
    
    <<<from page 82 of the CLtL:>>>
    	
    ...
    
    		and {form}*
    	
    	(and form1 form2 ...) evaluates each form, from left to right.
    If any form evaluates to nil, the value nil is immediately returned
    without evaluating the remaining forms.
    ^^^^^^^ ^^^^^^^^^^
    
    <<<end quote>>> 
    

	Last night I was playing with my latest toy - Dr T's KCS sequencing
software.  I have now entered the world of individual MIDI event editing!

	Well, one of the first things I did was to download some sequences from 
the MIDI DJ into it to do some cleaning up of some previously ignored sequence 
glitches.  While cleaning up I noticed a lot of extraneous MIDI data - stuff 
that I have NO idea how it got there.

	Fer inst'nce...  At the end of one sequence, I found Control Change (CC)
1, which, I understand, is modulation.  Now all I have for a controller is an 
RD200, which has NO MOD WHEEL!  Another string of bites I found was CC 123 
(anyone know what THAT is?).  On both of these instances, it had a single value 
for EACH MIDI channel, starting from 16 going down to 1.

	Some questions:

	o  Does anyone have the faintest idea where these came from?  Is it 
	   possible that the RD200 is transmitting things it is not spec'd
	   out to do?

	o  Since I can now insert single midi events, I've thought of 
	   initializing modules that accept midi volume with a single volume
	   level command.  My question is this:  do midi modules expect a
	   string of volume control change commands (such as come from a slider)
	   or is one sufficient.  I tried it last night on the fly but didn't 
	   notice much of a difference, though I can think of a number of other 
	   reasons why I may not have noticed the volume change.  Does anyone 
	   have any idea?

	I thought I had another question, but I can't seen to recall...

	Dan

    Could it be some kind of power-up, wake-up or other noise caused
    the DJ to record erroneous events?  Seems to me I've had something
    like this happen when using song pointer and recording what comes
    out of a drum machine.  Seemed the drum machine wasn't given enough
    time to catch up before its output was recorded ...
    
    Steve

    I've had similar experiances with my Suzuki Unisynth (XG1m - sort of
    like a guitar, but not really). It sends way too much stuff for my
    MMT-8 (sequencer) to trap. I lose a substantial amount of data because
    it decides to send pitch bend info, when I never touch the pitch bend
    arm (kind of like a vibrato on a guitar). For the most part, I've given
    up on using it as an input to my sequencer. I'd suspect that your
    system is kicking out some default values, just to make sure the the
    other devices slaved to it know what it's doing. My MT-32 and the Midi
    Merge on the MMT-8 work fine with the Unisynth, but the amount of
    messages is more than the sequencer knows what to do with.

							    Jens

RE: .30 (Dan)

    I *still* think your RD is spitting out garbage - but I've thought that
    all along.  Now that you have Dr. T's, you may just want to put the
    thing in record mode at a very slow tempo and let your RD sit there for
    3 or 4 minutes and see what you get.  Try the same thing playing,
    making sure you use the sustain pedal and the volume sliders.  Could be
    that you have a bad control somewhere. 

    Speaking of control, you will only need 1 MIDI volume command. I do
    this with MTP to set initial volumes of modules all the time.  If you
    want to do things like pitch bends and (de)cresendos, you may want to
    try using a very coarse granularity, then tighten up the gaps - you'll
    find that normal continuous controllers (like pitch bend, mod and
    volume) put out *many* more MIDI events than are necessary in most
    instances. 

-b

RE .31

	I doubt it is a 'noise' related phenomenon, because it comes out so
    
RE .32

	Interesting about the Unisynth.  The only thing, though, is that my
RD has no device that is SUPPOSED to send out pitch bend info for.

RE .33

	O.K., o.k., Brad, I may have to concede this time.  I'll try your test
and see.  And thanks for the info on midi volume/other controllers.

	Dan

Re 1293.32 by Moller

It could be that vibration of the arm is enough to send data.  Since
pitch-bend has lots of bits to play with (compared to key-pressure, say)
it could be that tiny movements are enough to set it off.

According to MidiScope, my Yamaha SHS sends clocks all the time, but it doesn't
send anything else unless I poke it. 

	Well, I found out what ONE of the messages was...

	Looking in my manual, I founf CC 123 stands for ALL NOTES OFF.  Actually
anything from 123 to 127 stands for All notes off, according to the RD MIDI
implementation chart.

	Brad,  I tried recording both idle and active sequences from the Rd into
KCS, and found nothing.  Back to the drawing board.

	Dan

    Did you try adjusting sliders, using the sustain pedal, etc? 

    Another thing you might want to try is playing each note on the kybd
    individually and then reviewing the data to make sure that you don't
    have a "bad key" - i.e., one that xmits bogus data along with the good
    stuff. 

    Of course, you could just buy a Fairlight and be done with it. 

-b