Talk:Velocity keyswitches retuning

Instructions to reduce amount of data for pitch glides, midi controlled pitch vibrato and other frequent retunes - should these be required or optional? - DECIDED TO REMOVE THIS
This was an idea but in practise doesn't seem to be much benefit and slightly complicates the code

Even if you are doing a continuous glide, if gliding more than one note at once, then you need to send the input note on every retune as you rotate through the notes you are gliding on. So is only going to help in case where you have a pitch glide on a single note and that isn't so very much message traffic

These instructions reduce data for pitch glides over midi cables. Over USB cables and internally within a computer the data rate is so fast that the difference is not likely to be noticeable, probably talking about nanoseconds rather than ms (USB midi transmits data at a rate hundreds of times faster than a midi cable USB Midi spec).

So, I am not sure if there is enough demand for this to make it a requirement of the synth. If not could be just optional instructions that a synth can program or not as desired and retuning programs would normally do a full retune of every note using 127,4 only.

However, the amount of extra programming for a synth to support these is likely to be low once you have programmed 127, 4, just a few extra instructions. So for that reason might be reasonable to make them a requirement.

The example Kontakt script supports these extra instructions.

What do you think, should these be a requirement or optional? (After reading the suggestion below)

For pitch glides, to reduce number of messages, could have:

So the idea here is, first you do a full retune of the note with a 127, 4. After that you can do further retunes of the same note using 127, 3. The input note of the 127, 4 is remembered by the synth until the next 127,4 or until a 12-et reset 127, 126.

This should be followed by

Similarly if you just want to adjust the bend for the most recently retuned input note, and want to leave its output note unchanged:

(with switch off and normal type running status, 4 for header + 8 bytes per note)

And, if we like, could have:

(with switch off and normal type running status, 4 for header + 4 bytes per note)

So - the idea is, multitimbral synths can be in mono tuning mode only, multi channel tuning mode only, or optionally both, and if both modes are supported, can, again optionally, respond to these instructions to change the tuning mode via midi.

For technical reasons, this script does not currently permit switching between mono and multi channel tuning mode via midi, and these instructions are ignored.

This Kontakt script acts on the instrument instance as a whole. So, it will be in multi channel tuning mode if you load a different copy of the instrument in each midi channel, and mono tuning mode if you load a single instance of the instrument set to receive midi notes on all channels.

(Q: Is there any way for a Kontakt script to check which midi channel the notes were received on? If so I could make it switchable between the two modes in case where user has it set to receive notes on all midi channels).