Tuning RPNs: Difference between revisions

: This revision was by author [[User:TallKite|TallKite]] and made on <tt>2013-09-12 20:51:44 UTC</tt>.<br>

: The original revision id was <tt>450747684</tt>.<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;white-space: pre-wrap ! important" class="old-revision-html">An open letter to tuning software authors:

The problem with MTS lies in convincing the authors of VSTi's and other softsynths, as well as the designers of hardware sound modules and keyboards, who generally have no personal interst 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 author 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.

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 microtuning method. By "we" I mean the authors of midi tuning software. 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 authors: Add this simple easy method of retuning and you will sell more synths to microtonalists.

A couple of us 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/621829327837373/?notif_t=group_comment_reply The main contributors were Robert Walker, Kite Giedraitis, Rob Fielding, and Graham Breed.

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 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 author, 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 either a data increment or a data decrement message to transpose the input note by so many semitones, allowing for non-12-note tunings. If the RPN MSB is 100 = 64 hexadecimal, then to bend note nn on channel c to note mm with bend of yyzz would take up to 5 midi CC (Controller Change) messages. In hexadecimal the midi looks like this:

These messages are always sent in this order. The RPN MSB message need only be sent once (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. Unlike the midi spec, data inc/dec messages are not summed, instead the newest one overwrites any older ones. Thus inc = 3 followed by inc = 5 results in inc = not 8 but 5. Furthermore data MSB/LSB values are not affected by inc/dec. This is because the highest priority in designing this new method is to make the coding as easy as possible for the synth author. 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 author's responsibility to avoid transposing out of range. Thus nn + inc must always be &lt;= 127 and nn - dec must always be &gt;= 0.

RPN 61,0 to 61,8 three dimensional sound controllers

<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">&lt;html&gt;&lt;head&gt;&lt;title&gt;Tuning RPNs&lt;/title&gt;&lt;/head&gt;&lt;body&gt;An open letter to tuning software authors:&lt;br /&gt;

The problem with MTS lies in convincing the authors of VSTi's and other softsynths, as well as the designers of hardware sound modules and keyboards, who generally have no personal interst 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 author 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.&lt;br /&gt;

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 microtuning method. By &amp;quot;we&amp;quot; I mean the authors of midi tuning software. 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 authors: Add this simple easy method of retuning and you will sell more synths to microtonalists.&lt;br /&gt;

A couple of us came up with a specific method, and we'd like your input. The original discussion is in this XA facebook megathread: &lt;!-- ws:start:WikiTextUrlRule:55:https://www.facebook.com/groups/xenharmonic2/621829327837373/?notif_t=group_comment_reply --&gt;&lt;a class="wiki_link_ext" href="https://www.facebook.com/groups/xenharmonic2/621829327837373/?notif_t=group_comment_reply" rel="nofollow"&gt;https://www.facebook.com/groups/xenharmonic2/621829327837373/?notif_t=group_comment_reply&lt;/a&gt;&lt;!-- ws:end:WikiTextUrlRule:55 --&gt; The main contributors were Robert Walker, Kite Giedraitis, Rob Fielding, and Graham Breed.&lt;br /&gt;

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 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 author, 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 either a data increment or a data decrement message to transpose the input note by so many semitones, allowing for non-12-note tunings. If the RPN MSB is 100 = 64 hexadecimal, then to bend note nn on channel c to note mm with bend of yyzz would take up to 5 midi CC (Controller Change) messages. In hexadecimal the midi looks like this:&lt;br /&gt;

These messages are always sent in this order. The RPN MSB message need only be sent once (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. Unlike the midi spec, data inc/dec messages are not summed, instead the newest one overwrites any older ones. Thus inc = 3 followed by inc = 5 results in inc = not 8 but 5. Furthermore data MSB/LSB values are not affected by inc/dec. This is because the highest priority in designing this new method is to make the coding as easy as possible for the synth author. 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 author's responsibility to avoid transposing out of range. Thus nn + inc must always be &amp;lt;= 127 and nn - dec must always be &amp;gt;= 0.&lt;br /&gt;

RPN 61,0 to 61,8 three dimensional sound controllers&lt;br /&gt;