Hi, I was wondering if there is something unusual or internally hardcoded about the factory default “Flutter-tongue” playback technique: It seems to be immune to change/interruption by any mutually exclusive playback technique I put against it?
Is it mandatory to use “ord” or “nat” (or the ‘circular handles’ feature) to constrain/stop this particular factory playback technique, despite the rule, “TheArticulation Type ‘Direction’ will force an interrupt if in the same mutual exclusion group”?
As an experiment, I set up the Expression Map to correctly trigger the desired key-switches (the sounds do audition correctly). l also put both playback techniques into the mutual exclusion list together, and made sure each playback technique was of Articulation Type “Direction”. But no matter what, the flutter-tongue playback technique prevailed regardless of any subsequent requested technique changes in the score.
The workaround was to make an explicit, custom playback technique from scratch for every articulation I wanted to trigger, but it bothers me that the program did not work as expected in this situation. I’m hoping someone can demystify why I couldn’t get an articulation switch to happen with the flutter-tongue technique in the implicit, normal fashion (i.e. I expected a Direction to stop another Direction, if in the same exclusion group, and if both are simple Base Switches), without needing to resort to ‘ord’ or ‘nat’ or the ‘circular handles’ explicitly.
The above “Direction, Base Switches, Mutually Exclusive” procedure seems to work fine with my custom techniques so far, so I was wondering if there was something internally hardcoded with flutter-tongue (and perhaps other factory techniques in the software.) If anyone has any insight on this, I’d appreciate it. Thanks!
Can you share an example? Which subsequent PT are you using?
Generally you should specify to the player how long a technique lasts. And visually indicating this (giving the PT a specific length and for example activating the line to show it clearly) makes sure that also the playback is as expected (especially with direction PT):
Thanks Christian_R, readability by a real player is less of a concern right now for me; I’m mostly concerned with deeply understanding the mechanics of predictable playback right now. The flutter-tongue was more of an arbitrary choice to learn how playback worked.
I tried a few methodical iterations to deduce the inner workings, but the only reliable fix was to use the line as a constraint, as you described (this is basically what I call the ‘circular handles’ method, but with the ‘continuation type’ set to “line” in the Properties panel as shown in your screenshot.)
Given how much I imagine I’ll want to use Directional type articulations frequently with various sample libraries, it’s a bit concerning that I might have to mark some of those changes with that Line to be 100% certain the base switches will trigger on/off reliably (or not trigger simultaneously if only briefly, as sometimes also occurs.) Usually, the mutually exclusive ‘Directionals’ force each other off/on as desired, but not always 100%.
As much as I’d like to put examples here, there’s a lot of seemingly inconsistent things happening that are just too complicated to describe without making and posting a ridiculous glut of images and videos of Playback Technique UI, Playing Technique UI, Mutual Exclusion Group UI, and Kontakt keyboard-keyswitch observation videos.
If I can arrive at a more coherent thesis down the road and manage to keep it brief, I’ll post more on this again. Until then, I’ll keep plugging away with other libraries, instruments and articulations and perhaps a clearer pattern will surface.
your post set some bells ringing as I seemed to remember occasionally I had flutter-tongue still in my score when not expecting it. And indeed the reason seemed to be that I had switched to a different technique without first going via “ord”. However, I can’t myself see any evidence that explicit (as opposed to relying on Dorico’s auto feature) mutual exclusions don’t work, including with f.t. If you have specific examples, I’d be happy to try them out.
Brief update/closure: I gave up on using key switches (this is Spitfire Symphony Orchestra 2024) and used the library’s UACC functionality via CC#32, which made all the various articulation changes work as expected (and implicitly) on base switch changes.
It seemed like this library responded much more reliably in Dorico using the UACC method. At some point I’ll see what happens in other libraries that only have key switches (fingers crossed…)
UACC with CC32 is one method. Other option is UACC KS. That uses a single keyswitch where the velocity controls the articulation choice. The velocity values match the CC32 values with UACC KS.
I’m not entirely sure, but the BabylonWaves Art Conductor maps use UACC KS for whatever reason instead of CC32.
In general, the advantage of keyswitches of any kind over CC’s for articulation switching is that it is possible (if the DAW supports it) to play multiple simultaneous notes with different articulations on the same channel. This is accomplished by sending the keyswitch and playback notes in the same tick in the correct order. I don’t believe Dorico or Cubase currently support this though.
For exporting MIDI from Dorico to Cubase it can be easier to clean up the keyswitches rather than the CC data.
Simple - the way the Spitfire libraries are designed, to get all the articulations for a given instrument you have to put two or three different NKI patches on the same MIDI port and channel (each of which has a subset of techniques, with no overlap between them). The problem is that when using standard keyswitches, there’s no good way to stop the other two patches (which don’t have the articulation you want at a given moment) from playing whatever articulation they last had. This causes you to hear notes doubled up across the three patches, simultaneously hearing the articulation you want along with two other patches playing whatever the last articulation was that they could play.
But with either UACC option (CC32 or KS) if the patch is asked to activate an articulation it doesn’t have, it will mute itself. So only the one patch of the three that has the articulation you are asking for will play and the other two will mute themselves.
