What's new

Logic 10.4 Articulation Discussion

@WindcryMusic, you might be able to cut to the chase (and avoid testing anything) by turning off the Data Reduction feature on the Script. Doing so ensures that an articulation-switching message will be set at the start of every musical note -- as opposed to the default setting, where switching messages are only sent on an as-needed basis. The idea behind "as needed" is to stop the Script from "spamming" a patch with normally unnecessary, repetitive switching messages. But in practice I think you'll find that turning it off won't cause any timing issues as a result of all those extra events being sent; at the same time, if a palette is 'misfiring' for some reason, you can be assured that the proper articulation is being selected at the start of every single note.

That sounds like something that should be easy to try ... I'll see if I can do that test later on tonight.

Update: I just tried it. Recorded something where I could reproduce the misbehavior, then turned off Data Reduction. No effect ... the note drop-outs still happen in the same way. Again, the effect I'm seeing is not that certain notes play with the wrong articulation ... rather, certain notes don't sound AT ALL. The key still shows as having been pressed in Kontakt's keyboard pane, but there's nothing audible from that note. In this test, the offending notes were separated by 12 ticks, with the performance legato note played later than the other articulation (a simple long sustain). If I switch things around so that the performance legato note is sounded 12 ticks BEFORE the other articulation, then both articulations play back fine. I duplicated this same behavior in a couple of sections. In each case, if I slide the trailing legato note back to about 40 to 50 ticks after the other articulation, it seems to sound 100% of the time.

This feels to me like it could be an issue with the Spitfire performance legato not handling being switched off and then back on as a result of an intervening note using a different articulation, unless enough time is allowed for something in Spitfire's script to "reset". (I'm assuming it is Spitfire's scripting that is at fault at this point since, if it was an issue with ARTzID, one would expect it to happen regardless of which articulation was selected to play first.)
 
@WindcryMusic, that's curious behavior indeed. But I agree with your conclusion, that it's behavior specific to the patch. Which library are you testing that performance legato with?

@Dewdman42, I'm of the same mind regarding the KH patch you've been working on the Script for -- I think what you're seeing is behavior specific to the programming of the patch.

This kind of behavior isn't entirely unusual, either. Not common, but still, not unusual. For example, I've run any number of polyphonic articulation-switching torture tests with Vienna Instruments, various EastWest and Kontakt-based libraries (including Cinematic Strings 2 & Berlin Strings) and they all trigger articulations flawlessly.

On the flip side, Cinematic Studio Strings has trouble when you try to get certain combinations of articulations to sound simultaneously. Then again, this is somewhat understandable behavior, such as when trying to get legato (monophonic) and staccato (polyphonic) articulations to sound simultaneously.

Furthermore, I've found that some EWQL keyswitching patches which feature "legato" articulations (Q-Leg, Exp-Leg, etc.) require 35 milliseconds of space between the keyswitch note and the musical note intended to sound with those articulations.

So regardless of whether someone's trying to roll their own articulation sets or they're using my system, I think it's fair to say that there will always be some exceptions to how well a particular patch/palette will respond. Fortunately, the exceptions are few.

One of the ways to work around these problem children is to address those sounds by not using articulation-switching at all: load the individual articulations and set them up to respond on a different MIDI channel from the palette/keyswitching patch.
 
Last edited:
@WindcryMusic, that's curious behavior indeed. But I agree with your conclusion, that it's behavior specific to the patch. Which library are you testing that performance legato with?

Spitfire Symphonic Strings, Violins 1 Performance Legato. But I'm guessing it is likely to be common to all of the performance legato patches from the Symphonic line.

For my part, I've decided for the moment to just go ahead and combine the performance legatos with the other articulations, regardless of this issue. If I don't do so, it adds around 30 Kontakt instances to my template and increases the template's RAM footprint (even completely purged of samples) by around 2 GB, and memory space is at a premium for me right now because I don't have $9000 for an iMac Pro (tear runs down cheek) and my current iMac is maxed out at 32 GB.

I'm choosing to look at it as follows: in almost all cases with any given orchestral section, I'll only be using a single legato articulation for a stretch by itself and then switching to other articulations, rather than doubling the two up like this. In any rare cases where I really do have to overlap legato and other articulations, at that point I'll just duplicate the track and move the legato regions to a track of their own, rather than waste all of that memory (and screen space!) to always separate the legatos for every section just to protect against a problem that might only come up for a single section in one cue out of ten.
 
Maybe I've found a solution to Logic's Articulation 'jump-back'. To summarize the problem again: after a note selects the assigned articulation, Logic immediately and automatically selects articulation ID1. It doesn't remain on the selected articulation up to the end of the playing note, as expected.

I own two types of libraries. The first one (like VSL) seems to be able to work even with this issue. A note selects a slot/articulation, and VSL's player continues to play that articulation even if ID1's slot has been automatically selected in the meantime. (I've yet, however, to check what happens when switching or crossfading slots inside the intended slot.)

The other one (like Tarilonte's Mystica or Soundiron Olymputs choir) can't work with this bug. Mystica (and other Tarilonte's libraries) can change sound even while a note is playing. Let the note select the vowel 'Eeh', and Logic with suddently switch it to 'Aah'. Soundiron's libraries would let you select the ending phonem of a syllable, but with Logic automatically choosing ID1 you will always end up with only the choices available for the 'Aah' syllable.

What I've tried with Mystica is this: Create a full list of articulations in Logic. The last one will be a 'Blank' articulation, without no event assigned. Until Apple solves the bug, you will assign ID100 to the 'Aah' vowel (the first articulation in the list), and ID1 to the 'Blank' dummy articulation. Replacing articulations is very easy in Logic (just select them with Edit > Select > Similar Articulations, and assign them a different articulation in the Info box), so swapping them is not a major issue.

When Logic automatically selects ID1, it select the 'Blank' dummy articulation, and nothing will change in Mystica. The ladies will continue singing their phonem as intended.

Paolo
 
Yes, but what I would do is use id=254 on the first line of the articulation set. That is the largest id allowed. Just make it a habit to always put a dummy articulation on the first line with id=254. Then you can number the rest of them starting at id=1 on the second line. Make sure dummy articulation 254 doesn't have any output switches. Unless and until Apple fixes this problem then that is the working model on ALL of my articulation sets.
 
As far as I've seen, Logic is not going back to the first articulation in the list, but to articulation ID1. So you can have ID254 in the first line, and Logic will continue to look for ID1, wherever it is.

I prefer to have the most basic articulation as my first choice (Sustain, or Aah). When the bug is solved, I want it as the default articulation, the one that will be used the most.

Paolo
 
No, sorry that's not correct. The first one on the list is the one that is defaulted, regardless of what ID it is.

This defaulting behavior happens both coming in and going out. So for example, if you play in some parts and don't use any input keyswitches, then all the incoming events will get encoded to the region with the articulation id of the first one on the list. There is no way, to record incoming midi to a region without assigning one of the articulations from the set. So if you don't choose one, then the first one will be used...first on the list...regardless of what ID# it is.

Also, there is a control on the top of the plugin window..and basically by default it will be showing the first articulation on the list (regardless of the actual ID#). Changing that field is supposed to be the same as if you had used an input keyswitch. Then subsequent incoming notes will be recorded to the region with that artid number. If you use input keyswitches you can see they are updating that GUI control also. That field is kind of linked to the the input switch mechanism.

On output, something similar happens for events in the region that don't have any artid assigned to them, they will also attempt to send the output keyswitch for the first articulation on the list just as if they had been encoded with it. Again, regardless of what the actual ID# is.
 
Last edited:
IMHO, what LPX should do that would be better:

First, events in the region without an artid assigned to them should not ever send a keyswitch out by default. If the user wants keyswitches sent, they should assign articulation id's to events to cause that to happen. Unassigned events should send nothing extra.

In essence that means that events in the region without any artid assigned to them will just continue to play whatever sound is currently in the instrument, no switching would occur.

(note the only way to currently avoid the above problem is to make sure the first articulation on the list is a dummy articulation with absolutely no output switches.).

Secondly, while recording to a region, by default events should be encoded without any articulation id, unless the user selects one via input keyswitch or the plugin window control. The input switch feature has several modes that can determine whether a selected articulation will last permanently, or one-time momentary switch, or a toggle, etc. This is all fancy behavior that can be programmed so that you can use input switches to determine how incoming midi events will be encoded as they are recorded to the region. That's all fine, but the user should be able to also record events without any id and that should be the default.

It can become particularly problematic when notes and CC's are recorded at the same time..and then later you go back to change the articulation id's of the notes.. Then during playback you end up with keyswitches flipping the instrument rapidly back and forth between the articulations you want for the notes, and the articulations that were automatically encoded to the CC events earlier when you recorded them to the region. You really want the notes and the CC's in the same space of time, to have the same matching artid... or if you can record stuff without an id assigned initially...then those unassigned CC's should not send any conflicting keyswitches. This is all "should" behavior..right now the behavior is totally wonky.

One work around is to always record your midi to the region with the articulation set turned off. Then by default they will be recoreded without a default artid (YAY!) and then you can go set the notes you want keyswitches for to have the artid... and it will all be fine..but only if you put a dummy articulation on the first line so that the default output behavior for all the unassigned events will be to not send any keyswitches out.
 
Deawdman42, it works in a different way, here, and I don't know why it is different.

In the first video, you can see the 'Aah' articulation, the first in the list, being ID1. It is the one automatically selected by Logic:

https://www.studio-magazine.com/video/sw/logic/Logic_Articulation_jump_back.mov

In this other video the 'Aah' articulation has been moved to ID100, while still being the first in the list. Logic seems to still automatically select ID1, that I assigned to the empty 'Blank' articulation. As a result, the articulation that was playing is not interrupted by the one associated to ID1:

https://www.studio-magazine.com/video/sw/logic/Logic_Blank_ArtID.mov

What's happening?

Paolo
 
I would need to see your articulation set completely and also your complete event list (not just notes), to see fully what is going on in your case. You must have some stuff with id1 saved in the region somewhere, its not using it by default unless that is the first articulation on the list
 
I removed everything, but the segment of track where I experimented with articulation change. Do you mind to give it a look?

Paolo
 

Attachments

  • Logic ArtID fake.logicx.zip
    1.1 MB · Views: 2
I removed everything, but the segment of track where I experimented with articulation change. Do you mind to give it a look?

Paolo
All of your modulation/expression data is set to articulation 1 (Blank) so every time a new modulation/expression value happens, it sends the key switch for articulation 1. That would explain why it keeps jumping back to the "Ahh" articulation when you had that set to articulation 1.
 
So take a look at the event list:

prob.jpg

Notice how all your recorded CC events have articulation id set to "Blank"?

(You have to use the event list "view" menu to show the articulation column.)

That is not playback "defaulting", that is because when you actually recorded the track to begin with with both notes and CC's you somehow had id1 articulation enabled, whether that was originally the first one on the list at the time you made the region or you had it selected via keyswitch or the plugin window menu...that is what you had enabled when you recorded the track and its burned into those CC events.

So now during that section of music, for example, you have an "ahh" note with the "Ahh" articulation, but its surrounded by CC events with the "blank" articulation. In this case its not so terrible, because you actually want the blank articulation attached to the CC's to avoid the scenario I mentioned earlier, but it has nothing to do with the fact that its id1... it does have to do with the fact that when you recorded the track you had id1 selected at the time you recorded it.

If you want to try a test to start over....
  1. delete the region
  2. create a new empty region
  3. make sure the plugin window shows "Ahh" for the articulation control at the top
  4. with your current articulation set (where the first item is id100) enabled, record some notes and CC events.
  5. Look at the event list and you will see they are all encoded with the "Ahh" articulation id100.
And now change some of the notes to say articulation 5 and watch what happens... wonky stuff...
 
Last edited:
but in the above, if you ever have any events with "-" undefined artid, then with the articulation set you provided here, those events will playback the "Ahh" articulation, including the output keyswitch for it. that includes both notes and CC's that might end up in your region without any artid assigned.
 
I see. Thank you both for pointing me to the right direction. I had the Articulation column hidden in the List pane, and could not even think that events other than notes could have an ArtID attached.

And I can confirm that the first ArtID in the list is selected. Even if the '--' empty articulation is assigned to the events.

Is there some reasons to have ArtID attached to Control Changes, and is there any creative way to use them?

Paolo
 
I am not sure how you are programming your Sets, but in my tests (so far) whatever "rogue" cc data is recorded with Art IDs does not affect playback. Sure agreed the GUI jumps around, but the sounds are what I recorded.

I have tried three ways:

1. Record notes, art id changes and modwheel moves "live" (not easy to do though)
Result: Notes and CC share the same articulation and whenever notes change articulation the CC data at that point when recorded together assumes the same articulation ID. Playback unaffected.

2. Record notes, art id changes and then modwheel moves on separate pass
Result: CC assumes ID of whatever is preselected (for example by dropdown in Kontakt window) and stays at that throughout unless you change the articulation in this menu or via a remote, while recording cc. Playback unaffected.

3. Record notes, art id changes and then draw in cc data
Result: CC has no ID attached just shows –. Playback unaffected.

In my case it has no bearing as I am using automation to control cc data via a Midi FX script so I dont record midi CC I record automation which is converted before it hits the VI into CC data.

But so far I have not heard anything play back incorrectly. I tested the above with Emotional Cello which uses note based keyswitches and Sable/SCS which uses UACC. Both playback fine here.
 
Is there some reasons to have ArtID attached to Control Changes, and is there any creative way to use them?
Paolo

sure there might be, but generally most people do NOT need them and they cause more headaches to deal with it. Its probably something else Apple should change in the feature or at least make it configurable somehow so that while recording only notes will be encoded with articulation id. But I think their thinking was that most people would record a given section of music, providing both notes and input switches in real time and recorded to the track, so if you are capable of playing like that, then you would end up with a given section of music having the desired artid's encoded into both notes and CC's in a way that would make sense and not require any further editing. Their input switch features are much more sophisticated then output switches, and to me it appears that is their thinking was more oriented towards a lot of flexbility in the way you input keyswithes as you play and burn the result into midi events as a final performed result.

Personally I think most people play their parts in using input keyswitches more minimally...and then do a lot of editing after the fact to setup all the notes up exactly how they want them played back with various articulations.

So as I was saying before, if you disable the articulation set entirely while recording, then your CC's and notes will not be encoded with anything and only the notes you want to have a specific articulation, you can assign manually in the piano roll after enabling the articulation set. Make sure the first articulation is the blank one, so that all the unassigned notes and CC's will not send any keyswitches out, then you should be golden.

Or....

If you like to use some minimal input switching as you play...then just be aware that CC's are going to be encoded too....and you'll have to either clean them up by removing their articulation ID, or by making sure they are the same as the notes around them, or using a custom script to do your output switches and ignore CC's with artid.
 
I am just not sure what the issue is here. Maybe you have a different set up to me, but I have had no playback issues so far. The CCs might have IDs attached, but only the notes with IDs actually trigger anything.

The CCs only record IDs if they are recorded with a hardware input, if they are drawn in no ID is attached.

CCs have IDs attached with hardware moves eg modwheel. But the ID that is attached is either the last one selected in the Kontakt window or remote OR if you are changing IDs live while playing notes/moving the modwheel they follow the ID of the notes.

The only time CCs have ID1 is either if you selected ID 1 before moving the modwheel OR if you had nothing selected as nothing = ID1 [or whatever the first slot ID is numbered to].

Its possible there are libraries that go bananas with this, but I have tried Note Based, UACC and Midi Channel types and so far none have played back with incorrect articulations.
 
I am just not sure what the issue is here. Maybe you have a different set up to me, but I have had no playback issues so far. The CCs might have IDs attached, but only the notes with IDs actually trigger anything.

well that can be the case with custom Scripting such as artzid or roll your own, but not so with the articulation set output switches..that sends switches on cc events too.

The CCs only record IDs if they are recorded with a hardware input, if they are drawn in no ID is attached.
correct. Which is another reason to have a "blank" articulation at the top of the list.

CCs have IDs attached with hardware moves eg modwheel. But the ID that is attached is either the last one selected in the Kontakt window or remote OR if you are changing IDs live while playing notes/moving the modwheel they follow the ID of the notes.

correct, UNLESS you opt to turn off the articulation set while recording mod wheel moves.
 
well that can be the case with custom Scripting such as artzid or roll your own, but not so with the articulation set output switches..that sends switches on cc events too.

Well my comments above are not using ArtzID, they are using the stock Articulation Sets. While the GUI indicates switching visually I am not finding notes changing articulation as a result.

correct, UNLESS you opt to turn off the articulation set while recording mod wheel moves.

Well IF this were an issue (cannot comment as not had one yet), maybe the solution other than your suggestion which is certainly an option, would be if Apple made an optional key command to toggle Articulation Sets on/off or made an option to bypass CCs?

Another workaround is to record everything, then deselect Notes in the Event Editor and select all CC events with cmd A and change their ID to -

But I have just tried again using Symphony Series Strings and also plays back fine.
 
Top Bottom