Controlling dynamics via modwheel in live playing

[burningbusch]

Just wanted to clarify something. Orchestral VIs often DO distinguish between shorts and longs and how each is affected by key velocity or controller expression. For example, I'm working with Spitfire Audio Albion One at the moment. If I bring up the string .NKI with all the articulations available, and then set DYNAMICS to be controlled by CC#02 or CC#01, the short articulations, e.g. staccato, spiccato, pizz, col legno are unaffected. They remain controlled by velocity, which makes sense. So it's only with the longs that CC modulation controls dynamics and x-fade between timbre layers. Cinematic Studio Strings functions similarly. Some others do not and blindly apply the dynamics/expression CC to all articulations.

If that were the case you could create two instances, one for CC controlled longs and the other for velocity controlled shorts.

 

Busch.

[Reezekeys]

Simply converting velocity to CC1 will only give you the single starting value. If you want any more expressivity after you trigger the sound, you'd need to also program another control source (aftertouch, expression pedal, whatever)

At which point one might ask: why convert velocity at all, if you're going to use a controller to shape it? Just use the controller to begin with.

In live performance, you could use a foot pedal or aftertouch to affect the sound after you play it, when desired. You wouldn't want to have to use the controller for every single note you play, just for simple control of how loud you want to play the note, that's where you'd want to use velocity. Just like with standard workstation sounds. The fact that you might use your keyboard's wheels, pedals, or aftertouch after you strike a note in no way eliminates the usefulness of having the sound also modified by the velocity of the initial strike.

I thought we were talking about converting velocity to CC data, not using velocity to control volume then using a CC to further shape the sound, as you described. Velocity to volume does not involve converting doesnt every sample playing VI use velocity to control volume, regardless of what the sample developer may do?

[AnotherScott]

Velocity to volume does not involve converting doesnt every sample playing VI use velocity to control volume, regardless of what the sample developer may do?

Apparently not, which is exactly what led to this conversation.

[Willem]

Hag01, I completely follow you, This year I switched to Mainstage/Kontakt only to find out that it wasnt easy to find the right (string) libraries.

 

Controlling a mod wheel isnt possible while playing two handed. Operating an expression pedal works for long cresc & desc, but requires control over your foot to keep the curve smooth and its impossible to phrase each note in a melody line using only your foot when youre so used to key velocity as a pianist.

 

I tried remapping velocity to CC (using Bidule or Mainstage) but that doesnt work either because with each new key stroke the new velocity/CC value is applied to ALL sounding notes. It doesnt work on an individual note basis. So while playing legato or pedal notes, the overall volume jumps up and down with each key touch.

 

Last, the best libraries (eg Cinematic Studio Strings and Spitfire) are really optimised to sequencing, not live playing. They lack ensemble patches covering the entire keyboard and expect you to input each line (violin, viola, cello, etc) individually. Stacking multiple instrument patches in overlapping layers doesnt give a nice result either.

 

Fortunately there are a few libraries that support velocity based dynamics. I bought Berlin Inspire from Orchestral Tools and I really like it. Kirk Hunter can do this too, but hearing the demos I liked the sound less.

 

Im still looking for the ultimate library that lets me set the initial dynamics value using velocity and then let me increase or decrease it using using a controller like after touch, mod wheel or expression pedal. That would give the most realistic effect in my opinion. Its a pity none of the libraries can do this.

[J. Dan]

I've come back to this a few times now and had not commented as of yet because it still seems a bit unclear to me the specific functionality that is causing the problems. It may not be work the way you want out of the box, but most of this seems attainable. The parts that are less attainable are not possible using the libraries you speak of using modulation, and I'll explain.

 

Maybe the first problem is the use of generic terms like "dynamics" and then interweaving single events, continuous controllers, and channel vs note based controls. So let's start by breaking it down into some specifics.

 

Note On Velocity and Note Off Velocity are transmitted any time you strike or release a note. One value is sent of each, but it is PER NOTE, meaning if you strike 5 different notes with different velocities, they will each respond to the velocity received.

This at a bare minimum typically controls volume, and very often will also trigger different samples due to sample cross-fading, but at that point, unless you've made edits, will typically be what you hear until release. I don't have a lot of expertise with the software instruments, but in almost every hardware workstation I've ever laid hands on, it is also very easy to assign velocity to things like attack/release time, filter cutoff, etc. So as an example, you could have a string patch where a light touch will have a slow attack and darker sound, where hitting it harder has a sharper attack and brighter sound, and even switch from a bowed string to a pizzicato sample, so that as you hit it harder it goes from bowed to plucked and more staccato and brighter. This is fairly trivial, and will occur individually on a note by note basis. But once you've struck the note, it will only respond the way you've programmed it for that velocity without additional interaction.

 

Let's move on to continuous controllers. With one exception, these are CHANNEL based - this applies to mod wheel, pitch bend, foot pedal, and Channel Aftertouch. Anything received will affect all notes being sustained. This is one area where I was a bit confused because you complained that remapping velocity to a controller affected all notes. Well you're mapping to a channel based message. If the software uses Mod wheel, then it would be exactly the same because modulation is also channel based. If you want to control some aspect of the sound after the strike and before the release, any of these controllers including aftertouch, footpedal, etc can do this.

 

If you really need PER note modulation after the initial strike of the key, then the only solution I can think of is POLY Aftertouch. In this case, pressure of each individual finger will separately modify the note that each finger is sustaining. This is well beyond what software is achieving with mod wheel, but is still possible. It's not as common to find things that respond to PolyAT and even more rare to find a keyboard that transmits PolyAT. If using a hardware synth, using this approach would have challenges if you wanted to crossfade between a large number of samples. Certainly things like filter cutoff, volumes, etc could be controlled but if you want to crossfade between more than a few samples, it would be cumbersome for a hardware workstation and at a minimum, it would severely limit polyphony. But again, I'm not aware of software sample libraries doing this on a per note basis (impossible using a channel based controller like mod wheel). It's possible some may respond to poly AT if you have a controller that generates it.

 

To further help understand what you actually need to achieve at the end of the day, dynamics typically mostly are understood to refer to volume articulation (attack, decay, release, swell, etc), whereas timbre is used to discuss articulations in the SOUND (dark, bright, resonant, harmonic content, etc).

[AnotherScott]

Correct, Dan, we are not talking about post-strike variation on a per note basis.

 

If you haven't watched it yet, it is definitely worth checking out the video Busch posted earlier in this thread. That's what cleared things up for me.

[J. Dan]

Correct, Dan, we are not talking about post-strike variation on a per note basis.

 

If you haven't watched it yet, it is definitely worth checking out the video Busch posted earlier in this thread. That's what cleared things up for me.

 

Yes, great video and I understand all that, but then the OP came back with "maybe I'm not making myself clear, I want to use velocity instead of CC11". I thought the video pretty well cleared up the issues with that, but there has been a bunch of discussion since then mixing up things like velocity and continuous controllers, with the comment about affecting all notes muddying the waters further. So I guess I'm wondering what about that video made it seem that the forum was misunderstanding him. I was trying to clarify in my post that velocity is a per note static condition, where as any CC is a per channel continuous control and you can't use one to control the other. So again, which exact things is he trying to control with velocity? Simply the sample set? Attack/Release? Bright/Dark? There are a lot of ways to work around that through a combination of velocity for certain things, but then aftertouch and/or foot pedal for others.

[AnotherScott]

Yes, great video and I understand all that, but then the OP came back with "maybe I'm not making myself clear, I want to use velocity instead of CC11". I thought the video pretty well cleared up the issues with that

I believe the OP was saying that he was not looking for velocity to do all the stuff shown in that video, but simply to be able to use velocity the way it works on a typical rompler, i.e. you strike the key harder to get a louder sound (and depending on the rompler and how it's programmed, possibly one with a brighter sounds, alternate attack, whatever, whether due to selecting a different sample based on velocity, or just different processing).

 

but there has been a bunch of discussion since then mixing up things like velocity and continuous controllers, with the comment about affecting all notes muddying the waters further.

I think you're referring here to this comment:

I tried remapping velocity to CC (using Bidule or Mainstage) but that doesnt work either because with each new key stroke the new velocity/CC value is applied to ALL sounding notes. It doesnt work on an individual note basis. So while playing legato or pedal notes, the overall volume jumps up and down with each key touch.

Willem's observing that, if a VST is designed to invoke those different kinds of expression (volume, brightness) ONLY through the mod wheel, and you attempt to get around that by having velocity mapped to mod wheel (CC #1)--even with the understanding that such mapping disregards CC1's ability to further modify the sound after the initial strike--you can be bitten by the fact that any new note you strike is sending a new value to CC#1 which will affect not only the new note, but also any existing notes you may be holding (because, as you point out, CCs are channel-based, and "anything received will affect all notes being sustained"). That means that the note that you just played (and held) using a soft velocity will suddenly become louder and brighter when it is joined by a note struck with a higher velocity, since the very act of hitting that next key with high velocity (with that CC#1 remapping employed) has the same effect as turning up the Mod wheel, which will affect all held sounds. This is typically not what you want! Which also means that--despite my earlier post--Hag was right that this method may only be feasible when playing monophonically rather than polyphonically.

 

Note that hosts have an internal virtual mixer, which itself can be controlled by CC. So the velocity remapped to CC controls volume downstream of the VI. And good hosts let you filter what CC messages each VI receives.

So you're saying that, if you're using a VST that does all volume-related expression through the mod wheel (and your goal is instead to affect volume with velocity), the idea is not to map velocity to that VST's CC1 function, but rather to route velocity to your host's volume function, right? What raises an eyebrow there is that you put this in the context of the host's "virtual mixer." We don't want velocity to adjust the volume of a channel, which is what I think you mean when you talk about a virtual mixer, because (related to what's discussed earlier in this post), that would affect the volume of all notes being held from previous keystrikes, which we don't want. We need velocity to affect the volume of each note played, without affecting the volume of previously held notes. I don't see a way to do this at the host level, this would seem to have to be done by the VST. And if the VST can only determine (individual note) volume via a continuous controller, we're back at the problem where any remapping which alters that value will affect all held notes.

 

(As a secondary issue, if I understand correctly, if you're not using the VSTs own dynamic controls--i.e. you're using velocity to control volume at the host level instad--then you would not be getting, for example, the increased/decreased brightness of the VST's higher/lower velocity samples.)

 

Im still looking for the ultimate library that lets me set the initial dynamics value using velocity and then let me increase or decrease it using using a controller like after touch, mod wheel or expression pedal. That would give the most realistic effect in my opinion. Its a pity none of the libraries can do this.

The "increase or decrease" part is tricky, I think any such implementation would have to use two different controllers, one for increase and one for decrease, and each would have to be programmed to generate an offset to current value rather than sending any absolute value; and you'd probably want to use return-to-zero controllers (mod wheel, aftertouch) rather than something like expression pedal where the starting point could be anywhere in its travel.

[Nathanael_I]

Im still looking for the ultimate library that lets me set the initial dynamics value using velocity and then let me increase or decrease it using using a controller like after touch, mod wheel or expression pedal. That would give the most realistic effect in my opinion. Its a pity none of the libraries can do this.

 

I don't know whether anyone else shares your preference. The media composing community certainly doesn't, and prefers mod wheels and breath controllers. I don't have any expectation of using a keyboard to play other instruments in an idiomatic way without heavily altering what a pianist would play or do.

 

The good news is that Kontakt is a fully featured sampler. You can take many libraries and reprogram the sampler to suit your preference. You can even record your own samples that are designed to work with your preferred control paradigm. What you want is completely possible. If no one has done it - perhaps you will be the one to do it and no doubt someone else will agree with you once it exists. Sometimes the world needs a frustrated artist to move the ball forward... It's how most sample libraries were made...

[Ashville.Guru]

@AnotherScott - agreed, CC remapping will indeed affect all held notes.

 

But frankly speaking, I see all of this as merely an academic exercise. I'd be quite surprised if there's a good library, especially a Kontakt one, that absolutely cannot be configured to respond to velocity.

 

Sure, the default configuration out of the box may not respond to CC11. But Kontakt is a beast when it comes to flexibility. A VI dev would probably have to put in a huge effort to ensure that there's no way a library to respond to velocity!

 

To someone in the OP's position, the best solution would be to invest time in learning the tool one intends to use. There is much wisdom in @Nathaniel_I's post above.

[Theo Verelst]

Samples might not be the easiest to control in terms of dynamically changing the volume. Even cross fade samples that really work are a bit of a rarity, which is logical, because in order for the cross fading to work, you'd best have a good model of the instrument, and use that to prepare the cross fade. Otherwise it's likely phases of all frequencies vary between the cross fade layers, and so the mix of the layers to be cross faded will sound strange.

 

Even harder when you take something like a violin and you increase the bow speed (I don't know what a violinist calls that), to increase the volume and change the tonality. On some boards pretty deep intrinsic algorithms are used to get some of thus effect to work, but I think using random cross fade sampling that's hard to do, and certainly hard to do right.

 

T.

[AnotherScott]

@AnotherScott - agreed, CC remapping will indeed affect all held notes.

 

But frankly speaking, I see all of this as merely an academic exercise. I'd be quite surprised if...

That's the thing, I was surprised as well, this doesn't seem to be academic at all. What I learned in this thread and its sister thread at https://forums.musicplayer.com/ubbthreads.php/topics/2921179 is that there are indeed VSTs designed for compositional/tracking use only, that go beyond merely being optimized for those purposes, but actually are designed exclusively for those purposes. They apparently cannot respond to velocity in a way suitable for live performance. The solution is simply, choose a different VST. Some quality VSTs with these advanced articulations still include patches design for live playability, but apparently, some simply do not, and it seems like attempts to adapt them through MIDI rerouting or whatever will simply lead to putting a lot of time and effort into something that still will likely be unsatisfactory. Better to buy something designed to do what you need than to try to adapt something that doesn't.

[Nathanael_I]

there are indeed VSTs designed for compositional/tracking use only, that go beyond merely being optimized for those purposes, but actually are designed exclusively for those purposes.

 

In their intended environment, this makes complete sense. A top shelf string library like Berlin Strings or VSL's new Synchron strings has half a dozen CC messages that control very sophisticated scripting within the sampler. The Sample Modeling Brass instruments are capable of shocking realism in certain contexts, but you need more than even a breath controller to get everything they have on tap - their are another handful of CC controls that drive the final bits of inflection and realism.

 

These are not designed for live play - they are for commercial media composition when the budget cannot afford live players, or the deadlines don't, or for sketching prior to a real recording session with top $$ players. When you need sign-off from an ad agency or director before spending big bucks in a studio, these are the tools that are used to sell the vision. It is normal to make multiple passes with a MIDI fader box to write in the various controls, regardless of intended use.

 

These libraries do sound great - they are very deeply sampled, with some of the top players in the world. Even with just CC 11 and 1, they will easily beat anything in a keyboard for realism. But you will only be playing notes with one hand, expression with the other. I believe this is normal in theatre and other applications where you can have multiple musicians covering parts. In a bar band, it would be hard to see the utility of this approach.

 

 

[J. Dan]

Not only that, but in a bar, would these nuances even come through with enough clarity to be heard? I think plenty of workstations have dynamic controls intended for live performance that cover the limits of what can be perceived by the crowd in this type of environment. Choose the right tool for the application.

[AnotherScott]

In a bar band, it would be hard to see the utility of this approach.

I understand. What surprised me was learning that these high end libraries didn't also include at least a couple of patches designed for live playing. It seems kind of counter-intuitive that after you spend $400 on a brass library or whatever, it is very possible you'd still need to buy some other brass VST for your live performances. If you're not even aware that's it a differentiating feature to look for, you can easily make the wrong purchase choice, if there's some other library that would have worked sufficiently well for you for either application. Of course, it's not an issue for everyone, as some people may only care about one application or the other.

[Ashville.Guru]

there are indeed VSTs designed for compositional/tracking use only, that go beyond merely being optimized for those purposes, but actually are designed exclusively for those purposes.

 

In their intended environment, this makes complete sense. A top shelf string library like Berlin Strings or VSL's new Synchron strings has half a dozen CC messages that control very sophisticated scripting within the sampler. The Sample Modeling Brass instruments are capable of shocking realism in certain contexts, but you need more than even a breath controller to get everything they have on tap - their are another handful of CC controls that drive the final bits of inflection and realism.

Yes, it makes sense that this is how these instruments are - out of the box. Can someone confirm that there is no means by which volumen can be assigned to velocity by 'opening up the hood', so to speak?

 

It's many years since I dabbled with Kontakt scripting. I've since moved on to SFZ and the Aria engine. My impression yet is that Kontakt was far more flexible and was weighing switching back, so this is of particular interest to me.

 

- Guru

[Reezekeys]

Yes, it makes sense that this is how these instruments are - out of the box. Can someone confirm that there is no means by which volumen can be assigned to velocity by 'opening up the hood', so to speak?

 

It's many years since I dabbled with Kontakt scripting. I've since moved on to SFZ and the Aria engine. My impression yet is that Kontakt was far more flexible and was weighing switching back, so this is of particular interest to me.

Am I missing something? I've always thought that velocity control of volume was a default in any Kontakt instrument. Do the custom sample library developers disable this? You don't need to get into any of the scripting stuff, hell, you're barely cracking the hood!:

 

 

I can see where a sample library developer might initially set things so velocity won't control volume, but the control should be there and available for one to edit, no?

 

This is why the basic premise of this thread is baffling to me. If the OP wanted to assign velocity to volume in these mondo-expensive sample libraries, it's only a few mouse clicks away. Same with a low-pass filter. Instant "cheap synth" dynamic control!

[hardware]

Latest amount of scripting improved further by new AVX instructions.

Im set up just fine so wont upgrade until another down time period.

But for live work Kontakt is tough to beat, especially with a Custom host like Bidule. Further capabilities from the Physis K4 and believe it or not the SE-02 dynamic sensitivity and aftertouch are just as versatile.

Im on the verge of eliminating hardware Solaris and just using a single 8 zone controller.

Last few years for me have really made live work a very rewarding challenge.

[AnotherScott]

Yes, it makes sense that this is how these instruments are - out of the box. Can someone confirm that there is no means by which volumen can be assigned to velocity by 'opening up the hood', so to speak?

Again, this is what we've been discussing in this and the other related thread. I haven't worked with these things personally, but numerous people are clearly saying that there are VSTs that are not designed to work this way, and that trying to get around it provides undesirable results.

 

Earlier in this thread, Willem talked about not being able to properly address the problem with Bidule or Mainstage, I assume the same would be true of Kontakt.

 

Also, in the other thread, I referenced a conversation at https://vi-control.net/community/threads/string-libraries-that-control-dynamics-with-key-velocity-instead-of-cc.65480/ which descrbed such libraries that are and are not adaptable to velocity control.

[Ashville.Guru]

Am I missing something? I've always thought that velocity control of volume was a default in any Kontakt instrument. Do the custom sample library developers disable this? You don't need to get into any of the scripting stuff, hell, you're barely cracking the hood!:

 

 

I can see where a sample library developer might initially set things so velocity won't control volume, but the control should be there and available for one to edit, no?

 

This is why the basic premise of this thread is baffling to me. If the OP wanted to assign velocity to volume in these mondo-expensive sample libraries, it's only a few mouse clicks away. Same with a low-pass filter. Instant "cheap synth" dynamic control!

Oh man, thanks! This precisely articulates what's leaving me baffled. Especially that screenshot. I haven't seen Kontakt in years, and the screenshot brought a vague memory at the back of my mind to life.

 

 

...but numerous people are clearly saying that there are VSTs that are not designed to work this way, and that trying to get around it provides undesirable results.

...

Also, in the other thread, I referenced a conversation at https://vi-control.net/community/threads/string-libraries-that-control-dynamics-with-key-velocity-instead-of-cc.65480/ which descrbed such libraries that are and are not adaptable to velocity control.

You've probably heard that 80% of users use 20% of any software's features. What @RK is pointing out above is a power-user feature. So I'd remain sceptical until a Kontakt expert confirms that this feature is irreversibly turned off.

 

None of the reports I've seen address how the developers have irreversibly removed the velocity setting in RK's screenshot.

 

And more importantly, why would they would go to the great lengths required.

 

- Guru

 

 

[burningbusch]

Yes, a developer can effectively turn off velocity within Kontakt. Typically, you map samples to velocity in the mapping editor and then use velocity as a modulation source. But you don't have to use that approach. You can effectively turn off velocity. And because the script takes precedence, and the script is locked down (password protected) good luck trying to override that. Plus, if you look at the group editor (groups of samples) for any of these sophisticated instruments, you will likely see 100+ groups with nebulous names and again, good luck trying to reverse engineer this stuff.

 

Question. Why aren't people bitching that Hammond clones/emulations don't include velocity sense versions? It's the SAME thing. As JerryA pointed out above, organs have traditionally used pedals (occasionally knee levers) to provide expression as velocity triggering from the keys was not available, nor actually all that desirable. The notion that the only dynamic control one needs is the initial strike is unique to percussion instruments, of which the piano is of course one. So viewing a digital synth/VI as more closely related to an organ than a piano makes sense in a whole lot of ways. For example, the timbres of a pipe organ mimic the orchestra and there is a need to control the envelope or expressiveness of indefinitely sustained tones.

 

But, you actually have the best of both worlds. As I pointed out above, these libraries DO respond to velocity with the short articulations. They just require the additional controller(s) for the longs.

 

Busch.

[Ashville.Guru]

Thanks for addressing how velocity can be irreversibly turned off. But the why of it is still unclear.

 

What does the developer gain by locking down velocity in the protected script? Granted the optimal way is to use the modwheel, but why go to lengths to exclude customers with oddball requests (who're also usually the first to take to the internet to "bitch" about it)?

 

And I could be mistaken, but it does seem like the dev has to go the extra mile to override the velocity thing. I'm more familiar with SFZ, SF2 and GIG scripting, and in all the default is to have amplitude respond to velocity.

 

I'm still quite intrigued.

 

- Guru

[AnotherScott]

So I'd remain sceptical until a Kontakt expert confirms that this feature is irreversibly turned off.

Although Busch explained that it is possible, I think the bigger point may be that it doesn't matter, again because "numerous people are clearly saying that there are VSTs that are not designed to work this way, and that trying to get around it provides undesirable results. " What difference does it make if Konakt gives you a way around it, and it plays like sh*t? And that might be why the programmer doesn't want you to be able to get around it.

[Willem]

I just discovered the new Chris Hein string ensembles library which supports controlling dynamics using both velocity and controller. Seems my wish has been granted