how can i access this slider within HH2
controlling the bend in a vst
i made a quick test
the inlet is created when you move it on the VST gui, but thet don't give name to this parameter so it's not easy to see it but it's here:
the inlet is created when you move it on the VST gui, but thet don't give name to this parameter so it's not easy to see it but it's here:
or, probably try to send to "midi in" standard midi pitch bend events attach that knob to has changed module, set the knob range to 0-127 and use this knob as input for create midi module, and output of "has changed' connect to "create" pin of the create midi module
@nay-seven 
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
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
no, you don't need an has changed module, simply create a wire from the inlet and choose knob
some of VSTs didnt have special inlet for pitchbend, instead of that they listen to standard pitchbend midi event. here: http://www.sensomusic.com/forums/upload ... bender.pat
is simple patch wich is supposed to generate that event (tried that with NI FM8)
is simple patch wich is supposed to generate that event (tried that with NI FM8)
A couple notes on pitch bend, which you may find helpful...
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.
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.
Address the process rather than the outcome. Then, the outcome becomes more likely. - Fripp
Who is online
Users browsing this forum: No registered users and 14 guests