Feature Request: Proper manual strumming in Evolution libraries

Official support for: orangetreesamples.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Hi Greg and everyone

I own both Strawberry and EAG (as well as Slide). I love the sound and the excellent scripting in normal playing mode. :love:

I also think that the strum sequencer is capable and has its uses, but honestly I don’t like it. It’s a matter of personal style, of course. For me, having to program each strum with tons of mouse-drag operations, a tight window, and a limitation of only 6 patterns per instance is a tedious and limiting process. I just want to strum away freely (and linearly), not limited to patterns, and being able to edit the strums more easily with the DAW’s better editing tools.

Unfortunately, manual strumming in Evolution is crippled almost to the point of being unusable, except for the occasional strumming/repeating of notes using the two strum keys while playing “normally”.

I hope this doesn’t come as a harsh bash. To make this criticism constructive, I’ve compiled several suggestions on what’s missing and how it can be implemented with minimum dev effort and maximum integration with the current functionality. Here goes:

Strum Speed: In addition (and instead of) the velocity modulation, please add a host/CC-automatable parameter.

Included Strings: Again, velocity control is convenient but not always what you want. Here I can think of several solutions: 1) Add two host/CC-automatable parameters for top and bottom strings, respectively; 2) Add a single host/CC-automatable parameter for number of hit strings, plus another parameter that provides string priority modes: Prefer low strings / prefer high strings / prefer first strings in strum direction (as is currently done with velocity in Evolution); 3) Variation: A parameter for number of hit strings plus another parameter for vertical picking hand position, to smoothly control priority between low, mid, or high strings.

Muted up/down stroke keys (optional): Since muted strums are probably the most useful and common articulations in rhythm guitar parts, it may be useful to dedicate another pair of strumming keys for muted strums. You can go a long way just using the four strumming keys.

Global dynamics modulation (optional): To enable effective copying/duplicating/looping of the strum key notes (as well as normal picked notes) while still allowing changing dynamics through the song non-destructively, add a host/CC-automatable parameter that scales the velocities of all input notes. Some DAWs and MIDI processing plug-ins can do this, but not all.

If I had to choose what’s the most urgent thing to add, it would be 1) The high/low-string priority control; 2) Strum speed control; 3) The rest of the stuff.

I hope you find this post valuable, and really hope to see these things implemented in a future version. :hyper:

Thanks for reading!

Noam

Post

Thanks for the suggestions--and thanks for taking the time to explain everything so clearly, too. :)

It's definitely something we considered when designing the latest version of the Evolution engine. There's so much territory to cover in a guitar library, from being able to play leads, finger picking, strumming, etc. that the amount of controls can easily skyrocket. So balancing everything as between customizability and approachability is definitely a challenge!

One solution to give you more control would be to add additional settings to control things like the overall strum speed of the strum keys, or to adjust how much velocity affects the strum speed, for example.

Right now the speed of the down/upstroke strum keys are based on velocity. So if you play quieter strums, they'll also be a little slower. Louder strums will be played faster. While that works for most strumming, if you need to access something else, say a very slow strum independent of the dynamic, I would recommend using a strumming pattern containing a single strum. That way you can use the existing strum keys for general strumming, and then repurpose the strum pattern keys for very specific strums.

In terms of adding multiple strum keys for different articulations, that's something that can end up taking a lot of room mapping-wise, since you'd have separate strum keys for sustains, half palm mutes, full palm mutes, fully muted notes, and then maybe even things like natural harmonics. However, for additional strum keys with the articulations built into them, the strum pattern keys can be repurposed for that as well. What you need to do is add a single strum with whatever articulation you want, strings affected, strum speed, etc. Just make sure that the strum pattern is as long as possible so you don't run into the pattern repeating.

Something like this:

Image

Anyway, hope that helps for right now, and we'll look into settings that can be added to give you more control over how the manual strum keys play/operate.
Greg Schlaepfer
Orange Tree Samples
Ultra-realistic sample libraries for Kontakt

Post

Thanks Greg, this is a great tip. I'll try it!

Noam

Post

OK, this workaround doesn't work as good as I hoped, unfortunately.

Two problems:

1. A high-velocity strum quickly followed by a low-velocity strum gets choked immediately, even when holding the keys or the sustain pedal. It seems to be the general behavior rather than a specific issue with pattern triggers, but I guess it didn't bother me as much in normal playing. However, in strumming (e.g. eights with some accented downs and soft ups), it chops the loud strums quite annoyingly and unnaturally. A soft strum following a strong strum shouldn't stop the strings from ringing.
I had to adjust my playing to being less dynamic or skip ghost strums altogether, which is a shame.

2. Unsurprisingly, articulation switches set in the Play page have no effect on triggered patterns, which means I can't use a keyswitch or velocity to switch e.g. between sustained and muted when using these single-shot patterns. I must then program a different single-shot pattern for each desired articulation, which suffers due to the maximum of 6 patterns per instance. For example, I programmed single-shot patterns as follows:
1. sustained down all strings
2. sustained up all strings
3. sustained down 4 high strings
4. sustained up 4 high strings
5. muted down 4 high strings
6. muted up 4 high strings
I was left wanting more slots for sustained on 3 low strings, sustained at a low strum speed, other articulations, and so on.

:( :cry:

thanks

Noam

Post

noamgordon wrote: 1. A high-velocity strum quickly followed by a low-velocity strum gets choked immediately, even when holding the keys or the sustain pedal. It seems to be the general behavior rather than a specific issue with pattern triggers, but I guess it didn't bother me as much in normal playing. However, in strumming (e.g. eights with some accented downs and soft ups), it chops the loud strums quite annoyingly and unnaturally. A soft strum following a strong strum shouldn't stop the strings from ringing.
I had to adjust my playing to being less dynamic or skip ghost strums altogether, which is a shame.
I believe when switching patterns, the next strum mutes all the strings rather than only the strings in the strum. I'll have to double-check, but it might work smoother for the patterns as well if switching doesn't mute all the strings.
noamgordon wrote: 2. Unsurprisingly, articulation switches set in the Play page have no effect on triggered patterns, which means I can't use a keyswitch or velocity to switch e.g. between sustained and muted when using these single-shot patterns.
Correct, since the strumming patterns have the articulations built into the pattern itself, allowing for more complex patterns articulation-wise. But I see your next point, where you would quickly run out of pattern slots:
noamgordon wrote: I must then program a different single-shot pattern for each desired articulation, which suffers due to the maximum of 6 patterns per instance. For example, I programmed single-shot patterns as follows:
1. sustained down all strings
2. sustained up all strings
3. sustained down 4 high strings
4. sustained up 4 high strings
5. muted down 4 high strings
6. muted up 4 high strings
I was left wanting more slots for sustained on 3 low strings, sustained at a low strum speed, other articulations, and so on.
Honestly, you'd need quite a few strumming keyswitches to cover everything--that's just the sustains and mutes, but as you can tell by a some of the factory strum patterns, the half palm mutes and full palm mutes are useful in addition to the muted strums. For somebody loading up the library for the first time, that amount of keyswitches could be pretty overwhelming.

That's why I'm trying to figure out a way to make the existing strum keys more powerful. Maybe some settings that adjust how much the velocity of the strum key affects the strum dynamic, another control for how much it affects the speed, and another for how velocity affects the number of strings that get strummed. That'll at least let you get the playability more in line with what you're after, for example.
Greg Schlaepfer
Orange Tree Samples
Ultra-realistic sample libraries for Kontakt

Post

Gregjazz wrote: I believe when switching patterns, the next strum mutes all the strings rather than only the strings in the strum. I'll have to double-check, but it might work smoother for the patterns as well if switching doesn't mute all the strings.
I think the problem is far more fundamental, and not related specifically to pattern switching. The problem is with how re-triggered notes are handled, i.e., when playing the same note twice quickly, where the first note is still being held (e.g. by overlapping event durations or by using the sustain pedal). The behavior of the first note must be determined appropriately.
Take the simple example of a piano: Hold the sustain pedal, play a note at ff, and quickly play the same note again at pp. Obviously, the note should keep ringing loudly, as the hammers do not damp the strings much when re-hitting them. A strummed guitar behaves like a piano in that regard. Strum a chord strongly, then quickly strum again softly - the chord is not choked completely by the second strum. Sure, some energy may be lost when the pick re-hits the strings, but not all of it, and certainly not instantaneously!

In many sample-based instruments (including Kontakt, I presume), you can decide how quickly a note gets dampened after re-triggering it while keeping it sustained (or having a long release time). I think that re-trigger dampening in Evolution is far too short, at least with regard to strumming - either in patterns or with the strum keys. I strongly suggest (==beg) that you tweak that parameter, make it longer (I guess 1-2sec would be fine). It would improve the product immensely.
(P.S. Of course, I’m referring to sustained articulation only. A mute strum will obviously choke the strings quickly).
(P.P.S. I think that the monstrously customizable plug-in Acou6tics exposes this parameter, BTW.)
Gregjazz wrote: Correct, since the strumming patterns have the articulations built into the pattern itself, allowing for more complex patterns articulation-wise. But I see your next point, where you would quickly run out of pattern slots:
[...]
Honestly, you'd need quite a few strumming keyswitches to cover everything--that's just the sustains and mutes, but as you can tell by a some of the factory strum patterns, the half palm mutes and full palm mutes are useful in addition to the muted strums. For somebody loading up the library for the first time, that amount of keyswitches could be pretty overwhelming.

That's why I'm trying to figure out a way to make the existing strum keys more powerful. Maybe some settings that adjust how much the velocity of the strum key affects the strum dynamic, another control for how much it affects the speed, and another for how velocity affects the number of strings that get strummed. That'll at least let you get the playability more in line with what you're after, for example.
I completely agree. I really really wanted to use these strum keys, but I think the result is bad, due to how velocity is currently hard-wired with strum speed and string inclusion (which strings get strummed).
Velocity control must be optional IMO, and as I said in the original post, speed and string inclusion should be controllable by other means, such as CC controllers, keys, etc.
Regarding string inclusion - if you want to control the number of included strings using velocity (or any single CC), then I think you must provide the user a way to determine what happens at low velocities: 1) only high strings are hit; 2) only low strings are hit; 3) only the first strings are hit (e.g. low strings on down-stroke, high strings on up-stroke). Current behavior in Evolution is “first-string” priority, which I think is the least useful of them all, and certainly doesn't work in many cases.
Regarding strum speed - I think it actually has little to do with how soft or hard you play in straightforward rhythm part strumming. In many cases, it will simply be determined by the strum duration (8th, 16th, etc. and the tempo) as the hand is sweeped up and down from strum to strum, and by the playing style. Also, a slow and loud strum is not uncommon e.g. “on the one” or in a break. That’s why speed must be directly user-controllable and optionally decoupled from velocity.

Many competing products provide means to control these things. For example, Ilya Efimov and Acou6tics offer multiple keyswitches/key-triggers for slow/fast strums and all/high-four/low-four -strings strums. I’ve also seen strum speed as a controllable parameter (don’t remember where), and even a “vertical picking hand position” parameter that determines which strings get hit (maybe in Musiclab RG?).

So, controllers for speed and string inclusion could be cool if not essential.
Now, here's an even cooler alternative: The workaround you suggested in your previous post can actually be developed into an extremely powerful feature:
First, increase the number of user slots from 6 to at least 12 or even 20 (I think this should be done anyway, regardless of this lengthy discussion!!).
Second, let each one of these slots define either a pattern (like today) or a single strum consisting of a set of parameters defining the strum: articulation, direction, speed, included strings, and how the latter two are affected by velocity and CCs. Regarding the articulation, the user can either choose a fixed articulation (e.g. mute) or choose to follow the logic in the Play screen. Effectively, these are user-configurable strum keys that will supersede the current strum keys and will be much more useful and flexible. Very powerful yet still not too complicated, I think. It will not overwhelm beginners because they will not be forced to do this by themselves, and they can be offered a default selection of basic single-strum keys (like they are today). Anyone interested in more elaborate manual strumming would dive in and design their own strums to their heart’s content or make just one or two quick assignments. It’s in the user’s hands.
This implementation would work nicely with all current functionality, and let users decide how much emphasis they put on triggering patterns vs. strumming manually.

I apologize for the lengthy writing, and hope you didn't TL;DR... I hope you find this input useful and will be excited to see what follows next.

BR

Noam

Post

noamgordon wrote: Regarding string inclusion - if you want to control the number of included strings using velocity (or any single CC), then I think you must provide the user a way to determine what happens at low velocities: 1) only high strings are hit; 2) only low strings are hit; 3) only the first strings are hit (e.g. low strings on down-stroke, high strings on up-stroke).
Bear in mind with a lot of these details, a majority of users just want to load the patch and play. I'll look into adding some settings to help customize how the strum keys work, but bear in mind that it's a tricky balance between approachability and customizability.

It's one thing to just add an entire section that lets you create a custom strum key editor where you can define your own strum keys and whatnot. In fact, that's what earlier versions of the Evolution guitar engine had! But a majority of the feedback I received was actually that this was too complex, and people just wanted two strum keys to alternate between.

So like I said, it's tricky to balance them, but I think one positive improvement--still staying within that balance--would be to add some additional settings for making strum velocity / speed / etc., independently adjustable.

I'll also look into the sample muting/overlap thing. It might be a simple solution by adjusting the release envelope on the samples that get muted by re-attacking them--we'll see. ;)
Greg Schlaepfer
Orange Tree Samples
Ultra-realistic sample libraries for Kontakt

Post

I agree with the OP on this.

I think that the very first generation of the Evolution libraries / strum engine had a really good solution for this. If I remember correctly, I believe that it was possible to assign different strums to 12 keys. For each strum you could set the articulation, number of strings played (e.g. three lowest or four highest in a chord), speed of strum and other things. This made it possible to easily and quickly create strumming patters with lots of variation.

Maybe reintroduce some of these features?

Post

Kudos for remembering that older version! It's been years--I think a couple generations of updates ago. :)

The main difference now is that the single strum keys don't dictate any specific articulation--the mapping configuration handles that. So the strum keys follow the same rules for any velocity ranges, keyswitches, etc., that you have set up.

That isn't to say it isn't possible to script, though. I would just have to figure out a way of adding that sort of control without imparting a ton of new default keyswitches. It also might require some new sort of interface view to configure the strum keys, too.
Greg Schlaepfer
Orange Tree Samples
Ultra-realistic sample libraries for Kontakt

Post

i agree with this-the sounds are great, but wanted to dive in w/ strumming-too tedious to program!

Post Reply

Return to “Orange Tree Samples”