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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
