Tuning: only change small part of the keyboard

I remember they have said pianoteq supports real-time midi tuning standard, that you may use a sequencer to send the following message to pianoteq to tune note by note:

F0 7F id 08 02 tt ll [kk xx yy zz]x(ll) F7
where

F0 7F = universal realtime SysEx header
id    = target device ID
08    = sub-id #1 (MIDI tuning standard)
02    = sub-id #2 (note change)
tt    = tuning program number from 0 to 127
ll    = number of notes to be changed (sets of [kk xx yy zz])
[kk xx yy zz] = MIDI note number, followed by frequency data for note
F7    = end of SysEx message

(http://www.microtonal-synthesis.com/MIDItuning.html)

It would be possible to make a full keyboard range SCL microtuning file that leaves most of the keyboard in 12 equal, then features a zone with non-12 intervals.

Facing such a task, I would be inclined to create the full range tuning in a spreadsheet using cents values, and just create the offsets needed in the unique zone(s) as a part of the whole tuning.

Knowing that 12 equal is 100 cents steps, create a SCL file that modifies the pitches you wish to offset in that region. MIDI Note 0, would be the 1/1 and have a value of 0 cents, then proceed to create the scale all the way through MIDI Note 127...

It might necessitate creating and using a special KBM file as well, where the 1/1 of the tuning would be mapped to MIDI Note 0, with what ever reference is needed, and I'm assuming standard concert 69.A @ 440 Hz for this.

As we know, usually, 12 equal will be this in cents:

0
100
200
300
400
500
600
700
800
900
1000
1100
1200

But as a framework for doing what you are suggesting, a full range mapping would look like this:

MIDI    Cents
00    0
01    100
02    200
03    300
04    400
05    500
06    600
07    700
08    800
09    900
10    1000
11    1100
12    1200
13    1300
14    1400
15    1500
16    1600
17    1700
18    1800
19    1900
20    2000
21    2100
22    2200
23    2300
24    2400
25    2500
26    2600
27    2700
28    2800
29    2900
30    3000
31    3100
32    3200
33    3300
34    3400
35    3500
36    3600
37    3700
38    3800
39    3900
40    4000
41    4100
42    4200
43    4300
44    4400
45    4500
46    4600
47    4700
48    4800
49    4900
50    5000
51    5100
52    5200
53    5300
54    5400
55    5500
56    5600
57    5700
58    5800
59    5900
60    6000
61    6100
62    6200
63    6300
64    6400
65    6500
66    6600
67    6700
68    6800
69    6900
70    7000
71    7100
72    7200
73    7300
74    7400
75    7500
76    7600
77    7700
78    7800
79    7900
80    8000
81    8100
82    8200
83    8300
84    8400
85    8500
86    8600
87    8700
88    8800
89    8900
90    9000
91    9100
92    9200
93    9300
94    9400
95    9500
96    9600
97    9700
98    9800
99    9900
100    10000
101    10100
102    10200
103    10300
104    10400
105    10500
106    10600
107    10700
108    10800
109    10900
110    11000
111    11100
112    11200
113    11300
114    11400
115    11500
116    11600
117    11700
118    11800
119    11900
120    12000
121    12100
122    12200
123    12300
124    12400
125    12500
126    12600
127    12700

Should theoretically work in Pianoteq with an appropriate KBM file, such as something like this:

! 0-440-69.kbm
!
! Size of map:
0
! First MIDI note number to retune:
0
! Last MIDI note number to retune:
127
! Middle note where the first entry in the mapping is mapped to:
0
! Reference note for which frequency is given:
69
! Frequency to tune the above note to (floating point e.g. 440.0):
440.000000
! Scale degree to consider as formal octave:
0
! Mapping.

Hi Milux,

If you are pasting your tuning into Scala's File/New/Scale dialog, leave off the 1/1, as it will create that for you.

That's the likely reason for the offset of one note.

Hi Milux,

Apologies. Missed that detail.

Of potential interest is a series of articles I've written over the years: Microtuning Virtual Instruments, which can be accessed here:

http://xen-arts.net/xen-articles/

Almost all of them deal with using Scala for creating various kinds of popular microtuning formats, data files and tuning tables used in virtual instruments that feature full keyboard microtuning, including the SCL and KBM files used by Pianoteq.

At the beginning of the below article there is a section that demonstrates how to create and save Scala SCL and KBM files:

Microtuning Virtual Instruments – Part 5 | Scala Workflow
http://xen-arts.net/microtuning-virtual...ts-part-5/

It's fairly straight forward as you will see. It's worth having Scala installed just for that one feature, as it makes it easy to create the SCL/KBM tuning tables.

Hi Milux,

That's a good question about MTS with the VST3 version of Pianoteq, one which I will defer to the developers, although from what I understand, it is the transmission of MIDI data (such as MTS) from plugins, rather than the reception of it, that's changed with the new VST3 standards.

Having made a few Windows VST3i plugins, I can confirm that all of them have been able to faithfully receive MTS transmissions, for example when the MTS data is placed on the timeline of a DAW track (usually with REAPER here for this scenario), routed/transmitted to the virtual instrument.

One word of caution though, from what I gathered from a previous thread on this forum some weeks past, the type of MTS that Pianoteq uses is strictly limited to 12 note intonation systems, and therefore, it would likely do nothing with a full keyboard microtuning that was transmitted to the plugin, where every note across the MIDI range would be retuned.

To be honest, I've done nothing with MTS in Pianoteq, because (a) I'm typically using its elegant SCL/KBM functionality, and (b) often work with intonation systems having less or greater than 12 notes, as well as some that may repeat at intervals other than a 2/1, such as for example Bohlen-Pierce which divides harmonic 3 into 13 equal parts (one of a vast continuum of such possibilities and divisions of other harmonics).