Tuning RPNs: Difference between revisions
Wikispaces>TallKite **Imported revision 450814128 - Original comment: ** |
Wikispaces>TallKite **Imported revision 450815304 - Original comment: ** |
||
| Line 1: | Line 1: | ||
<h2>IMPORTED REVISION FROM WIKISPACES</h2> | <h2>IMPORTED REVISION FROM WIKISPACES</h2> | ||
This is an imported revision from Wikispaces. The revision metadata is included below for reference:<br> | 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-13 | : This revision was by author [[User:TallKite|TallKite]] and made on <tt>2013-09-13 05:06:56 UTC</tt>.<br> | ||
: The original revision id was <tt> | : The original revision id was <tt>450815304</tt>.<br> | ||
: The revision comment was: <tt></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> | 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> | <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: | <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:** | ||
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, | 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. | ||
[[@http://www.midi.org/techspecs/midituning.php]] | |||
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, both Abelton Live and FL Studio actually filter out sysexes and keep them from reaching any VSTi's they host. Two, apparently sysexes aren't guaranteed to be transmitted synchronously with other types of midi messages. Three, a synth developer or designer may have to write additional code to read sysexes, as they are a variable-length message. So sysexes are cumbersome and there's a real disincentive to work with them. | 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, both Abelton Live and FL Studio actually filter out sysexes and keep them from reaching any VSTi's they host. Two, apparently sysexes aren't guaranteed to be transmitted synchronously with other types of midi messages. Three, a synth developer or designer may have to write additional code to read sysexes, as they are a variable-length message. So sysexes are cumbersome and there's a real disincentive to work with them. | ||
| Line 64: | Line 63: | ||
RPN LSB: Bc 64 nn (note to reset)</pre></div> | RPN LSB: Bc 64 nn (note to reset)</pre></div> | ||
<h4>Original HTML content:</h4> | <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>An open letter to tuning software developers:<br /> | <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:</strong><br /> | ||
<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, | 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 /> | ||
<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><br /> | |||
<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, both Abelton Live and FL Studio actually filter out sysexes and keep them from reaching any VSTi's they host. Two, apparently sysexes aren't guaranteed to be transmitted synchronously with other types of midi messages. Three, a synth developer or designer may have to write additional code to read sysexes, as they are a variable-length message. So sysexes are cumbersome and there's a real disincentive to work with them.<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, both Abelton Live and FL Studio actually filter out sysexes and keep them from reaching any VSTi's they host. Two, apparently sysexes aren't guaranteed to be transmitted synchronously with other types of midi messages. Three, a synth developer or designer may have to write additional code to read sysexes, as they are a variable-length message. So sysexes are cumbersome and there's a real disincentive to work with them.<br /> | ||