Re: Patch: Setting pan, chorus and reverb in MIDI

[Heikki Tauriainen]

David Kastrup <dak <at> gnu.org> writes:

> Heikki Tauriainen <g034737 <at> welho.com> writes:
> 
> > In short, these patches will add the following three context properties
> > for controlling additional MIDI parameters:
> >
> >     Staff.midiPanPosition   [an integer from 0 to 127]
> >          Pan position (0 = hard left, 64 = center, 127 = hard right)
> 
> Should be #LEFT hard left  #CENTER center  #RIGHT  hard right.
> 
> The range is not entirely symmetric.  Pan has a fine control also where
> 0000 is left, 2000 is center, and 3fff is hard right.  I think I'd use
> the conversion formula
> round ((dir+1)*max/2)
> where max is the available maximal value and round is the normal
> round-to-even rule.

It seems to be recommended that synthesizers should treat both values 0 and
1 as "hard left" to overcome the problem of having no way to represent the
exact center position otherwise (see <http://www.midi.org/techspecs/rp36.php>).

As to the "fine control" (14-bit) values, I didn't consider them (again for
simplicity) since, according to the source that I used as a reference
(<http://home.roadrunner.com/~jgglatt/tech/midispec/pan.htm>; this is only a
secondary source, but I don't own a copy of the official MIDI specification):

   Most all devices ignore the Fine adjust (#42) for Pan, and just 
   implement Coarse adjust (#10) because 14-bit resolution isn't needed for 
   this.

Of course, this statement doesn't necessarily give sufficient reason to
restrict support for setting the pan position to 7-bit accuracy.
 
> >     Staff.midiReverbLevel   [an integer from 0 to 127]
> >          Reverb effect level (0 = no effect, 127 = full effect)
> >     Staff.midiChorusLevel   [an integer from 0 to 127]
> >          Chorus effect level (0 = no effect, 127 = full effect)
> 
> Effects should probably scale from 0 to 1 rather than 0 to 127.

This is certainly true if the goal is to have the new settings behave like
the current settings for adjusting MIDI velocity (volume).

On the other hand, it could be worth considering if it were (even if the
values were scaled by default) possible to still have a way to control the
actual controller values that will end up in the generated MIDI files
directly so that the scaling does not "get in the way" of those who think
they know better what they're doing (and are used to thinking in terms of
the 0–127 range used in MIDI).  When thinking in this range, the additional
scaling just forces one to perform extra calculations.

One way to achieve this could possibly be to implement the scaled versions
of controlling the MIDI parameters using higher-level music functions which
set the properties by converting input values in the 0.0 to 1.0 range to the
"raw" integer values in the 0–127 range, and have the low-level properties
work using the 0–127 range.  The same could be done the other way around, of
course (that is, provide music functions which take care of scaling values
given in the 0–127 range to the 0.0 to 1.0 range for the properties,
although in this case the values in the input will end up being converted
from one range into another and then back).

I don't have any strong opinions about whether the effect parameters should
be given in the 0.0 to 1.0 range or not as I am no expert on neither
LilyPond design principles nor MIDI.

> I don't see "Balance".

It's hard to see something that isn't there... please don't read too much
into this omission, I only picked a set of properties that I remember having
seen in some software synthesizers just as a first attempt. Now that there's
possibly a mechanism available to handle changes to MIDI controller values,
it's easy to extend the implementation with support for additional
controllers which differ only in their control number.

(If I'd not considered ever sharing my changes to the code, I'd probably
have been satisfied with just a single new property to set the value of an
arbitrary controller, instead of defining explicit properties for separate
controllers.  However, this seemed to be against the existing principle of
having separate Midi_items in the code for representing different controls,
so I tried to keep following this design.  The idea of having a more generic
property to set the value of "any" controller might become more attractive
if the number of control numbers that need to be supported grows significantly.)

-- 
Heikki Tauriainen