]]>
The most important thing to know about pitch bend is that the sending controller and the receiving synth/VST must be configured with the same value for pitch bend range, or PBR (or range, or bend, etc...), for it to sound right. Otherwise the instrument may think the max wheel value is 2 semitones and the VST may think the max wheel value is 12 semitones.
Legato will NOT WORK if the PBRs do not agree between the controller & the synth. Most controllers & instruments default to a value of 2 semitones. Most controllers send legato as wheel events.
(Note, you can, in fact, get some wild effects having the VST PBR set to a higher # than the controller PBR, but legato will not work properly...)
No need to change the wheel events to CCs, you should be able to just work off of the wheel events.
I always use the MIDI values. Your controller should properly calculate & xmit the corresponding 'Wheel' MIDI data. (I don't think I've seen a VST with a separate wheel input before the above post...) Most recent gear sends the full 14 bit values. Some gear only sends the 7-bit MSB value. The Wheel value = MSB*128 + LSB.
More here, which may be helpful if you want to do math with these values:
http://forum.pdpatchrepo.info/topic/747 ... whammy-bar
Important part extracted here. (I shared this on the PureData forum a while back. Note in PureData, notein simply refers to the midi input note values & bendin simply refers to the 14-bit Wheel event values):
Frequency calculation, using notein and bendin:
I had a VERY hard time finding how to actually honor pitch bends in pd. Lots of folks have asked the question out there on the web, only to receive kinda useless theoretical answers. It took me a while to work out the formula:
[expr $f2*pow(2, (($f3*($f1-8192))/98304))]
Where:
$f1 = bendin value
$f2 = mtof value from midi note from notein
$f3 = pbr, pitch bend range
Formula explained:
freq-w-pb = freq * 2^((pbr/12)*((bendin-8192)/8192))
Which simplifies to:
freq-w-pb = freq * 2^((pbr*(bendin-8192))/98304)
Note similarity to:
next-note-freq = freq * 2^(1/12)
I.e., it's all about powers of 2... In increments of 1/12ths, it's your semitones. But when applying pitchbend, you don't want increments of semitones, you want increments of 1/8192ths of pbr # of semitones.
Bendin values range from 0-16383, where:
0 = bend the note DOWN by pbr# of semitones
8192 = NO bend
16384 = bend the note UP by pbr# of semitones
Yes, I know there is a one-off error (max is 16383, not 16384), and you can't actually get all the way to 16384, but it's so close nobody will ever hear the difference...
I hope this makes sense!
Caveats:
Pitchbend is a 14-bit value, requiring TWO bytes of data from your MIDI controller, one with MSB and one with LSB. Some gear only sends MSB (0-63=down and 64-127=up). The good news is that bendin properly reports it in the 0-16383 range, so no special coding is needed. However, the bend will NOT sound smooth, there will be audible steps, especially when using high PBR values. You'd need to modify this algorithm with a [line~] somewhere to even out the steps. Or stick to low PBR values when using very old gear.
Statistics: Posted by shawnb — 27 Mar 2015, 18:05
]]>
is simple patch wich is supposed to generate that event (tried that with NI FM8)
Statistics: Posted by drakh — 27 Mar 2015, 14:45
]]>
Statistics: Posted by nay-seven — 27 Mar 2015, 14:21
]]>
can i have this with "has changed" ?
i use "has changed" back to a the fader but the fader now stays permamently at 1 !?
@drakh ???
i am not sure i understand u. i tried a generate midi with pitchbend as cc but the code1 and code2 parameters are not willing to show something usefull
Statistics: Posted by ahs — 27 Mar 2015, 14:00
]]>
]]>
Statistics: Posted by nay-seven — 27 Mar 2015, 13:06
]]>
how can i access this slider within HH2
Statistics: Posted by ahs — 27 Mar 2015, 11:52
]]>