|
|
| (7 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| <h2>IMPORTED REVISION FROM WIKISPACES</h2>
| | #REDIRECT [[New Tuning Method]] |
| This is an imported revision from Wikispaces. The revision metadata is included below for reference:<br>
| |
| : This revision was by author [[User:TallKite|TallKite]] and made on <tt>2013-09-20 22:27:21 UTC</tt>.<br>
| |
| : The original revision id was <tt>452875632</tt>.<br>
| |
| : The revision comment was: <tt></tt><br>
| |
| The revision contents are below, presented both in the original Wikispaces Wikitext format, and in HTML exactly as Wikispaces rendered it.<br>
| |
| <h4>Original Wikitext content:</h4>
| |
| <div style="width:100%; max-height:400pt; overflow:auto; background-color:#f8f9fa; border: 1px solid #eaecf0; padding:0em"><pre style="margin:0px;border:none;background:none;word-wrap:break-word;white-space: pre-wrap ! important" class="old-revision-html">**An open letter to tuning software developers and synth developers:**
| |
|
| |
|
| **__Background__:**
| | [[Category:Midi]] |
| | |
| As we're all painfully aware, the midi spec isn't very microtonal-friendly. The powers that be decided that pitch bend would affect the whole channel, not individual notes, so retuning most synths requires dividing the midi stream among multiple channels. That increases setup time for the user and reduces polyphony, and generally just makes things complicated and difficult. The powers that be threw us a crumb in the form of MTS sysexes, [[@http://www.midi.org/techspecs/midituning.php]], which haven't been widely adopted.
| |
| | |
| The problem with MTS lies in convincing the developers of VSTi's and other softsynths, as well as the designers of hardware sound modules and keyboards, who generally have no personal interest in microtonalism, to invest their time and energy in understanding these sysexes and implementing them. And they're hard to understand. They use checksums, they use tuning banks, they use channel bitmaps, they use a different format for pitch bends than the usual midi pitch bend command, etc. Plus there are problems with sysex in general. One, Abelton Live and perhaps FL Studio actually filter out sysexes and keep them from reaching any VSTi's they host. Two, a synth developer or designer may have to write additional code to read sysexes, as they are a variable-length message. So sysexes are problematic and there's a real disincentive to work with them.
| |
| | |
| So it would be great if there was a simpler, non-sysex way of tuning individual notes. A few of us have cooked up a daring plan. The powers that be will probably never give us what we want, so we'll just __take__ it! We can commandeer an obscure and underused part of the midi spec and use it for our own microtonal purposes. We can simply create a new unofficial microtuning method. By "we" I mean the authors of midi tuning software, aka "retuners". If we all include this new method in alt-tuner, Fractal Tune Smithy, Custom Scale Editor, Scala, LMSO, etc. we will have a more enticing sales pitch for synth developers and designers: Add this simple easy method of retuning and you will sell more synths to microtonalists.
| |
| | |
| After much discussion, we came up with a specific method, and we'd like your input. The original discussion is in this XA facebook megathread: [[@https://www.facebook.com/groups/xenharmonic2/permalink/621829327837373/]] The main contributors were Robert Walker, Kite Giedraitis, Rob Fielding, and Graham Breed.
| |
| | |
| **__Design__:**
| |
| | |
| There are 3 parts to a tuning message: the input note, the output note, and the pitch bend. The input note is a midi note number which specifies a physical **__key__** on the controller. The output note is a midi note number which specifies a __**pitch**__ in the standard A-440 12-ET tuning. The pitch bend, which is the exact same format as the 2 data bytes of a standard midi pitch bend message, specifies how much to bend the output pitch. Upon receiving the input note, the synth produces this frequency:
| |
| | |
| frequency = 440 * 2 ^ [ ((outputNote - 69) / 12) + (pitchBend / 8192 - 1) / 6) ]
| |
| | |
| The pitch bend range is "hard-wired" to 2 semitones, one sixth of an octave, hence the 6 at the end of the equation. If the physical pitch bend wheel is moved, that bend would be added onto the tuning bend. The physical pitch bend wheel is not hard-wired to 200¢ and is governed by the usual pitch bend range.
| |
| | |
| Because microtonalists use array keyboards, there may be a full 128 keys in use. Any input key can be mapped to any output frequency. Because alternate tunings can have more than 12 notes per octave, more than one input note may be be mapped to the same output note. Therefore the pitch bend is associated with the input note, not the output note. Specifying an output note is optional. If none is specified, the output note is understood to be the same as the input note.
| |
| | |
| This might be easier to understand if a hardware implementation is visualized. Imagine a 10-and-a-half octave keyboard with 128 keys. Behind each key is a tiny transposing slider and a tiny pitch bend wheel. The slider runs from 0 to 127 and sets that key's output pitch. The slider doesn't travel smoothly, rather it clicks into place on the whole numbers. The pitch bend wheel runs from -200¢ to 200¢ and sets the bend. When the keyboard is first turned on, all these wheels are set to center and all the sliders are set to match the key -- the lowest key's slider is 0, the 2nd one is 1, etc. Unlike the usual pitch bend wheel, which this keyboard also has, the tiny wheels don't have a spring that returns them to center. If one is moved to +30¢, it stays there until moved again. Using the sliders and wheels, any key on the keyboard can be set to play any pitch in the entire 10-and-a-half octave midi range. The synth's job is to produce whatever pitches are required by the keys and sliders and wheels, which may be further bent by the usual pitch bend wheel.
| |
| | |
| Sometimes the keyboard will actually be a touchscreen device, and instead of pressing a key, the musician simply touches the screen to play a note, with the touch's location determining the pitch. Dragging one's fingers along the surface generates ultra-wide pitch bends. This is a polyphonic device, with each finger being in effect a separate "key". There may be no retuning software, because the controller (or iPad app) will generate its own tuning messages. The imaginary keyboard analogous to this device has no tiny wheels and each tiny slider can travel freely without clicks. From the synth's point of view, the midi stream is the same as from a standard controller: note-ons and note-offs mixed with tuning messages and perhaps standard pitch bends.
| |
| | |
| Multi-timbral synths should be able to handle as many as 16 of these keyboards at once, one per channel. (To be decided: Tuning messages must only affect their own channel, so that a pitch glide on one keyboard won't affect the tuning of another keyboard. **OR** Tuning messages must affect all channels at once, to reduce the volume of the midi traffic. If one keyboard is sending pitch glides, the synth developer can assume that that musician is using a separate instance of the synth.)
| |
| | |
| **__Implementation__:**
| |
| | |
| //(We've recently discovered that RPN data messages are not completely supported, and are considering alternatives to RPNs like undefined CCs, user-defined CCs, and keyswitches - Ed.)//
| |
| | |
| The new method uses RPNs (Registered Parameter Numbers). The technical details: There are about 16,000 possible RPN parameters, and only about a dozen are in use. We can use a block of 128 RPNs, one for each input note number, for retuning. Data MSB and LSB messages for these RPNs contain the cents to retune by, in the exact same format as the standard midi pitch bend message. The retuning is immediate (real-time), just like the standard pitch bend. This makes it easier for the synth developer or designer, because he has already written code that deals with physical pitch bend wheel movement, and can just reuse it to deal with tuning RPNs. We use another block of 128 RPNs to define the output note. The RPN LSB is again the input note number. The data MSB is the output note number, and the data LSB is not used. If this RPN MSB is 100 = 64 hexadecimal, and the first RPN MSB is 101 = 65 hexadecimal, then to bend note nn on channel c to note mm with bend of yyzz would take up to 6 midi CC (Controller Change) messages. In hexadecimal the midi looks like this:
| |
| | |
| RPN MSB: Bc 65 64 (transpose, B means CC message, 65 means set RPN parameter MSB)
| |
| RPN LSB: Bc 64 nn (input note, 64 means set RPN parameter LSB)
| |
| data MSB: Bc 06 mm (output note, optional)
| |
| RPN MSB: Bc 65 65 (set the bend)
| |
| data MSB: Bc 06 yy (coarse tune, optional)
| |
| data LSB: Bc 26 zz (fine tune, required)
| |
| | |
| These messages are always sent in this order. The RPN MSB message need only be sent once (//this sentence needs updating - Ed.//) (NRPN exception below). The CC/channel byte for the other 4 messages can sometimes be omitted via running status. The RPN LSB message need only be sent once per note. As per the midi spec, aditional data MSB/LSB messages continue to affect the current RPN parameter, overwriting previous data messages. This is because the highest priority in designing this new method is to make the coding as easy as possible for the synth developer or designer. By overwriting instead of summing, he doesn't have to maintain an array of current transpositions for all notes on all channels. Similarly, it's the tuning software developer's responsibility to avoid transposing out of range. Thus nn + inc must always be <= 127 and nn - dec must always be >= 0.
| |
| | |
| The data inc/dec message is optional and would generally be omitted for 12-notes-per-octave tunings. The data MSB could be omitted for slight pitch bends that don't change the MSB. The required data LSB functions as an "end of tuning message" marker and the synth waits until receiving this message to actually apply the new tuning.
| |
| | |
| A possible conflict arises with NRPNs, which use the same data inc/dec/MSB/LSB messages. The solution is for the tuning software to monitor the midi stream for NRPNs, and if any are found, take these steps: Remember the current NRPN parameter number, never omit the RPN MSB and LSB when retuning, and send a NRPN MSB/LSB message after retuning to restore the current NRPN parameter. Similar steps should be taken if one of the few RPNs already defined are encountered.
| |
| | |
| An additional RPN of 102, 0 is for resetting the tuning of all notes. On receiving this RPN, the synth should reset all notes on that channel back to standard tuning. The data MSB/LSB/inc/dec messages are not needed. To reset all notes on channel c:
| |
| | |
| RPN MSB: Bc 65 66 (note reset RPN)
| |
| RPN LSB: Bc 64 0
| |
| | |
| A few recommended practices for synths:
| |
| | |
| One aim of the tuning RPN method is to make extremely wide pitch glides possible. The synth should be able to retune a note as it's being played. Specifically, a data inc/dec message that changes the output note number should not trigger a new ADSR envelope. That should only happen in response to note-ons. The midi stream for pitch glides will be reduced to mostly data LSBs, with data MSBs whenever the MSB boundary is crossed, and data inc/dec whenever the note boundary is crossed.
| |
| | |
| ----
| |
| **__Questions__:**
| |
| | |
| Does anyone know of any RPN parameters actually in use other than the following?
| |
| RPN 0,0 pitch bend range
| |
| RPN 0,1 channel fine tuning
| |
| RPN 0,2 channel coarse tuning
| |
| RPN 0,3 tuning program change
| |
| RPN 0,4 tuning bank select
| |
| RPN 0,5 modulation depth range
| |
| RPN 61,0 to 61,8 three dimensional sound controllers [[@http://www.midi.org/techspecs/rp49public.pdf]]
| |
| RPN 111 used by Fractal Tune Smithy
| |
| [[@http://robertinventor.com/software/tunesmithy/help/midi_in.htm#more_midi_in_options|http://robertinventor.com/software/tunesmithy/help/midi_in.htm#more_midi_in_options]]
| |
| RPN 127,127 null parameter (disables all 4 data entry commands)
| |
| | |
| This method assumes that no RPNs other than these will ever be officially defined. Do you have any evidence to the contrary?
| |
| | |
| Any thoughts about just which blocks of RPNs to use for microtuning?
| |
| | |
| Any thoughts on this possible extension?
| |
| An additional RPN block. MSB = 103, would reset the pitch of a single note. The RPN LSB specifies the note. The data MSB/LSB/inc/dec messages are not needed. To reset note nn on channel c:
| |
| RPN MSB: Bc 65 67 (note reset RPN)
| |
| RPN LSB: Bc 64 nn (note to reset)
| |
| | |
| Would it be possible to quickly implement RPN microtuning in Abelton with scripts?</pre></div>
| |
| <h4>Original HTML content:</h4>
| |
| <div style="width:100%; max-height:400pt; overflow:auto; background-color:#f8f9fa; border: 1px solid #eaecf0; padding:0em"><pre style="margin:0px;border:none;background:none;word-wrap:break-word;width:200%;white-space: pre-wrap ! important" class="old-revision-html"><html><head><title>Tuning RPNs</title></head><body><strong>An open letter to tuning software developers and synth developers:</strong><br />
| |
| <br />
| |
| <strong><u>Background</u>:</strong><br />
| |
| <br />
| |
| As we're all painfully aware, the midi spec isn't very microtonal-friendly. The powers that be decided that pitch bend would affect the whole channel, not individual notes, so retuning most synths requires dividing the midi stream among multiple channels. That increases setup time for the user and reduces polyphony, and generally just makes things complicated and difficult. The powers that be threw us a crumb in the form of MTS sysexes, <a class="wiki_link_ext" href="http://www.midi.org/techspecs/midituning.php" rel="nofollow" target="_blank">http://www.midi.org/techspecs/midituning.php</a>, which haven't been widely adopted.<br />
| |
| <br />
| |
| The problem with MTS lies in convincing the developers of VSTi's and other softsynths, as well as the designers of hardware sound modules and keyboards, who generally have no personal interest in microtonalism, to invest their time and energy in understanding these sysexes and implementing them. And they're hard to understand. They use checksums, they use tuning banks, they use channel bitmaps, they use a different format for pitch bends than the usual midi pitch bend command, etc. Plus there are problems with sysex in general. One, Abelton Live and perhaps FL Studio actually filter out sysexes and keep them from reaching any VSTi's they host. Two, a synth developer or designer may have to write additional code to read sysexes, as they are a variable-length message. So sysexes are problematic and there's a real disincentive to work with them.<br />
| |
| <br />
| |
| So it would be great if there was a simpler, non-sysex way of tuning individual notes. A few of us have cooked up a daring plan. The powers that be will probably never give us what we want, so we'll just <u>take</u> it! We can commandeer an obscure and underused part of the midi spec and use it for our own microtonal purposes. We can simply create a new unofficial microtuning method. By &quot;we&quot; I mean the authors of midi tuning software, aka &quot;retuners&quot;. If we all include this new method in alt-tuner, Fractal Tune Smithy, Custom Scale Editor, Scala, LMSO, etc. we will have a more enticing sales pitch for synth developers and designers: Add this simple easy method of retuning and you will sell more synths to microtonalists.<br />
| |
| <br />
| |
| After much discussion, we came up with a specific method, and we'd like your input. The original discussion is in this XA facebook megathread: <a class="wiki_link_ext" href="https://www.facebook.com/groups/xenharmonic2/permalink/621829327837373/" rel="nofollow" target="_blank">https://www.facebook.com/groups/xenharmonic2/permalink/621829327837373/</a> The main contributors were Robert Walker, Kite Giedraitis, Rob Fielding, and Graham Breed.<br />
| |
| <br />
| |
| <strong><u>Design</u>:</strong><br />
| |
| <br />
| |
| There are 3 parts to a tuning message: the input note, the output note, and the pitch bend. The input note is a midi note number which specifies a physical <strong><u>key</u></strong> on the controller. The output note is a midi note number which specifies a <u><strong>pitch</strong></u> in the standard A-440 12-ET tuning. The pitch bend, which is the exact same format as the 2 data bytes of a standard midi pitch bend message, specifies how much to bend the output pitch. Upon receiving the input note, the synth produces this frequency:<br />
| |
| <br />
| |
| frequency = 440 * 2 ^ [ ((outputNote - 69) / 12) + (pitchBend / 8192 - 1) / 6) ]<br />
| |
| <br />
| |
| The pitch bend range is &quot;hard-wired&quot; to 2 semitones, one sixth of an octave, hence the 6 at the end of the equation. If the physical pitch bend wheel is moved, that bend would be added onto the tuning bend. The physical pitch bend wheel is not hard-wired to 200¢ and is governed by the usual pitch bend range.<br />
| |
| <br />
| |
| Because microtonalists use array keyboards, there may be a full 128 keys in use. Any input key can be mapped to any output frequency. Because alternate tunings can have more than 12 notes per octave, more than one input note may be be mapped to the same output note. Therefore the pitch bend is associated with the input note, not the output note. Specifying an output note is optional. If none is specified, the output note is understood to be the same as the input note.<br />
| |
| <br />
| |
| This might be easier to understand if a hardware implementation is visualized. Imagine a 10-and-a-half octave keyboard with 128 keys. Behind each key is a tiny transposing slider and a tiny pitch bend wheel. The slider runs from 0 to 127 and sets that key's output pitch. The slider doesn't travel smoothly, rather it clicks into place on the whole numbers. The pitch bend wheel runs from -200¢ to 200¢ and sets the bend. When the keyboard is first turned on, all these wheels are set to center and all the sliders are set to match the key -- the lowest key's slider is 0, the 2nd one is 1, etc. Unlike the usual pitch bend wheel, which this keyboard also has, the tiny wheels don't have a spring that returns them to center. If one is moved to +30¢, it stays there until moved again. Using the sliders and wheels, any key on the keyboard can be set to play any pitch in the entire 10-and-a-half octave midi range. The synth's job is to produce whatever pitches are required by the keys and sliders and wheels, which may be further bent by the usual pitch bend wheel.<br />
| |
| <br />
| |
| Sometimes the keyboard will actually be a touchscreen device, and instead of pressing a key, the musician simply touches the screen to play a note, with the touch's location determining the pitch. Dragging one's fingers along the surface generates ultra-wide pitch bends. This is a polyphonic device, with each finger being in effect a separate &quot;key&quot;. There may be no retuning software, because the controller (or iPad app) will generate its own tuning messages. The imaginary keyboard analogous to this device has no tiny wheels and each tiny slider can travel freely without clicks. From the synth's point of view, the midi stream is the same as from a standard controller: note-ons and note-offs mixed with tuning messages and perhaps standard pitch bends.<br />
| |
| <br />
| |
| Multi-timbral synths should be able to handle as many as 16 of these keyboards at once, one per channel. (To be decided: Tuning messages must only affect their own channel, so that a pitch glide on one keyboard won't affect the tuning of another keyboard. <strong>OR</strong> Tuning messages must affect all channels at once, to reduce the volume of the midi traffic. If one keyboard is sending pitch glides, the synth developer can assume that that musician is using a separate instance of the synth.)<br />
| |
| <br />
| |
| <strong><u>Implementation</u>:</strong><br />
| |
| <br />
| |
| <em>(We've recently discovered that RPN data messages are not completely supported, and are considering alternatives to RPNs like undefined CCs, user-defined CCs, and keyswitches - Ed.)</em><br />
| |
| <br />
| |
| The new method uses RPNs (Registered Parameter Numbers). The technical details: There are about 16,000 possible RPN parameters, and only about a dozen are in use. We can use a block of 128 RPNs, one for each input note number, for retuning. Data MSB and LSB messages for these RPNs contain the cents to retune by, in the exact same format as the standard midi pitch bend message. The retuning is immediate (real-time), just like the standard pitch bend. This makes it easier for the synth developer or designer, because he has already written code that deals with physical pitch bend wheel movement, and can just reuse it to deal with tuning RPNs. We use another block of 128 RPNs to define the output note. The RPN LSB is again the input note number. The data MSB is the output note number, and the data LSB is not used. If this RPN MSB is 100 = 64 hexadecimal, and the first RPN MSB is 101 = 65 hexadecimal, then to bend note nn on channel c to note mm with bend of yyzz would take up to 6 midi CC (Controller Change) messages. In hexadecimal the midi looks like this:<br />
| |
| <br />
| |
| RPN MSB: Bc 65 64 (transpose, B means CC message, 65 means set RPN parameter MSB)<br />
| |
| RPN LSB: Bc 64 nn (input note, 64 means set RPN parameter LSB)<br />
| |
| data MSB: Bc 06 mm (output note, optional)<br />
| |
| RPN MSB: Bc 65 65 (set the bend)<br />
| |
| data MSB: Bc 06 yy (coarse tune, optional)<br />
| |
| data LSB: Bc 26 zz (fine tune, required)<br />
| |
| <br />
| |
| These messages are always sent in this order. The RPN MSB message need only be sent once (<em>this sentence needs updating - Ed.</em>) (NRPN exception below). The CC/channel byte for the other 4 messages can sometimes be omitted via running status. The RPN LSB message need only be sent once per note. As per the midi spec, aditional data MSB/LSB messages continue to affect the current RPN parameter, overwriting previous data messages. This is because the highest priority in designing this new method is to make the coding as easy as possible for the synth developer or designer. By overwriting instead of summing, he doesn't have to maintain an array of current transpositions for all notes on all channels. Similarly, it's the tuning software developer's responsibility to avoid transposing out of range. Thus nn + inc must always be &lt;= 127 and nn - dec must always be &gt;= 0.<br />
| |
| <br />
| |
| The data inc/dec message is optional and would generally be omitted for 12-notes-per-octave tunings. The data MSB could be omitted for slight pitch bends that don't change the MSB. The required data LSB functions as an &quot;end of tuning message&quot; marker and the synth waits until receiving this message to actually apply the new tuning.<br />
| |
| <br />
| |
| A possible conflict arises with NRPNs, which use the same data inc/dec/MSB/LSB messages. The solution is for the tuning software to monitor the midi stream for NRPNs, and if any are found, take these steps: Remember the current NRPN parameter number, never omit the RPN MSB and LSB when retuning, and send a NRPN MSB/LSB message after retuning to restore the current NRPN parameter. Similar steps should be taken if one of the few RPNs already defined are encountered.<br />
| |
| <br />
| |
| An additional RPN of 102, 0 is for resetting the tuning of all notes. On receiving this RPN, the synth should reset all notes on that channel back to standard tuning. The data MSB/LSB/inc/dec messages are not needed. To reset all notes on channel c:<br />
| |
| <br />
| |
| RPN MSB: Bc 65 66 (note reset RPN)<br />
| |
| RPN LSB: Bc 64 0<br />
| |
| <br />
| |
| A few recommended practices for synths:<br />
| |
| <br />
| |
| One aim of the tuning RPN method is to make extremely wide pitch glides possible. The synth should be able to retune a note as it's being played. Specifically, a data inc/dec message that changes the output note number should not trigger a new ADSR envelope. That should only happen in response to note-ons. The midi stream for pitch glides will be reduced to mostly data LSBs, with data MSBs whenever the MSB boundary is crossed, and data inc/dec whenever the note boundary is crossed.<br />
| |
| <br />
| |
| <hr />
| |
| <strong><u>Questions</u>:</strong><br />
| |
| <br />
| |
| Does anyone know of any RPN parameters actually in use other than the following?<br />
| |
| RPN 0,0 pitch bend range<br />
| |
| RPN 0,1 channel fine tuning<br />
| |
| RPN 0,2 channel coarse tuning<br />
| |
| RPN 0,3 tuning program change<br />
| |
| RPN 0,4 tuning bank select<br />
| |
| RPN 0,5 modulation depth range<br />
| |
| RPN 61,0 to 61,8 three dimensional sound controllers <a class="wiki_link_ext" href="http://www.midi.org/techspecs/rp49public.pdf" rel="nofollow" target="_blank">http://www.midi.org/techspecs/rp49public.pdf</a><br />
| |
| RPN 111 used by Fractal Tune Smithy<br />
| |
| <a class="wiki_link_ext" href="http://robertinventor.com/software/tunesmithy/help/midi_in.htm#more_midi_in_options" rel="nofollow" target="_blank">http://robertinventor.com/software/tunesmithy/help/midi_in.htm#more_midi_in_options</a><br />
| |
| RPN 127,127 null parameter (disables all 4 data entry commands)<br />
| |
| <br />
| |
| This method assumes that no RPNs other than these will ever be officially defined. Do you have any evidence to the contrary?<br />
| |
| <br />
| |
| Any thoughts about just which blocks of RPNs to use for microtuning?<br />
| |
| <br />
| |
| Any thoughts on this possible extension?<br />
| |
| An additional RPN block. MSB = 103, would reset the pitch of a single note. The RPN LSB specifies the note. The data MSB/LSB/inc/dec messages are not needed. To reset note nn on channel c:<br />
| |
| RPN MSB: Bc 65 67 (note reset RPN)<br />
| |
| RPN LSB: Bc 64 nn (note to reset)<br />
| |
| <br />
| |
| Would it be possible to quickly implement RPN microtuning in Abelton with scripts?</body></html></pre></div>
| |