Jump to content

On using Articulation Sets to drive third party instrument plugins


MikeShapiro

Recommended Posts

I've found Logic's articulation system to be unreliable when driving third party plugins if MIDI CC or key switches are used as the mechanism for articulation switching. Articulations often fail to trigger, defaulting back to articulation ID 1. The behavior is unpredictable, in that the same passage played twice in a row will yield different results.

 

On the other hand, if MIDI channel is used as the mechanism for switching - e.g. MIDI channel 1 means staccato, MIDI channel 2 means legato, etc. - then Logic's articulation system seems to be rock solid.

 

I'm pretty sure the difference lies in the fact that MIDI channel is a parameter of the original note event. Thus, if the third party plugin receives the note, it's guaranteed to receive the MIDI channel at the exact same time. Whereas MIDI CC data or key switches are *other events* which comment upon the original note event and need to be processed with split-second timing in order to work. For whatever reason, Logic doesn't seem to be able to handle this kind of processing reliably, at least in my experience.

 

The problem with using MIDI channels as the articulation trigger mechanism is that normal MIDI controller data is likely to be on channel 1, and thus won't impact all the articulations you assign to different MIDI channels. So if you have track-wide CC1 controlling dynamics, it'll only affect whatever articulation is assigned to MIDI channel 1.

 

Right now I'm using a kludge solution, a MIDI script that literally copies every MIDI CC event to other channels. I'm hoping to find a better approach, or that the Logic team fixes the original issue.

 

I'm curious if anyone has experienced similar behavior, and/or has a better solution.

Link to comment
Share on other sites

Mike can you possibly share a simple lpx project that is exhibiting the bad behavior you speak of?

 

I have since moved on to writing my own scripter script to send out keyswitching, mainly because I want to be able to handle momentary keyswitches and toggles and multiple switches per artid. But whenever I have used the articulation set by itself it seemed to work fine.??

 

I think most of the issues people are having with the built in functionally stem from the way LPX will force the keyswitches for the first articulation to be sent out for events that don’t have an artid assigned. I consider this a bug that can cause some strange things to happen. There is a workaround though, just make sure you have a dummy articulation st the top of the set with no output keyswitches assigned to it.

 

Anyway, would like to understand better the dropped or mis timed keyswitches you mentioned above so if you have a working example to replicate and look at id love to take a look.

Link to comment
Share on other sites

Submit feedback to Apple. I agree with you, there should not be any keyswitches at all unless the articulation has changed. An undefined articulation should assume no change. Anyway put a dummy articulation on the first line. I use id 254 for this. Assign it no output keyswitches. Then unassigned events will essentially send the keyswitches for that one, which there are none, so none will be sent. Edited by Dewdman42
Link to comment
Share on other sites

But doesn't that control just reflect the most recent articulation triggered? In which case it seems that non-ID events will indeed have the last articulation that was triggered on input. This would create very different behavior depending on whether you input articulations in real time, or after the fact in editing.
Link to comment
Share on other sites

Yeah this is a mess.

 

If you record CC1 in real time along with your articulations, you'll get reasonable behavior.

 

If you record your articulations (or input them not in real time) and then add CC1 via drawing or other means, the CC1 will be assigned an articulation that's effectively random: the last one you happened to trigger. This means painstakingly editing the articulation ID for *all* CC1 data.

Link to comment
Share on other sites

I do not know that the plugin window control reflects the last articulation id. I do know for sure that whatever is selected there is considered the current default for unassigned events and what you’re describing does not match the experience of myself and others. It is not meant to display what is on your piano roll in the last played note it is meant for you to change what you want the next articulation to be via the GUI. Edited by Dewdman42
Link to comment
Share on other sites

>UNLESS you were using input keyswitches in which case for non momentary keyswitches it will assign the >artid matchng the input keyswitch you used. To everything including CC

 

That's what I meant by random. If you input some articulations, then draw in some CC, the CC will be interpreted as whatever articulation you last happened to trigger on input. (If I understand you correctly.)

Link to comment
Share on other sites

and actually I just ran a quick test and although I read in Edgar Rothermich's book on 10.4, that the articulation control would determine the articulation to play for events with unassigned articulation id, It doesn't seem to work that way for me right now.. Maybe it does on Apple instruments, not sure. But it didn't work for kontakt just now. So its back to previous statement...the first articulation in the set will have its keyswitch sent out, if one exists, for any events with unassigned artid.
Link to comment
Share on other sites

another thing to consider doing is to turn off the articulation set while you are playing in your parts, so that nothing gets encoded at all other then what you specify on a note by note basis. Leave everything else unassigned and use the trick above to make sure those unassigned events don't send any keyswitches at all.
Link to comment
Share on other sites

I ran some tests today, setting ArtID #1 to be a stub with no Output function. I then drew CC1 (with no ArtID) on top of a busy region (notes with defined articulations).

 

Although this solved the problem of articulations unexpectedly switching, I found a new problem: skipped notes whenever there was a CC1 in close proximity to a note. I got almost identical results with CineSamples and Spitfire Strings.

 

Although this may be an issue with Kontakt, I suspect Logic's system is buggy.

Link to comment
Share on other sites

Yes that is true about spitfire reccomending the keyswitch version. I’m on my iPhone now but if you google, spitfire has a whole support page about it.

 

Myself I have run into some timing issues using CC automation in conjunction with KH Spotlight Solo Strings to drive certain articulation changes where automation has to be used instead of an actual keyswitch. My opinion at the moment is that either kontakt is handling cc automation in a separate queue from the queue handling incoming midi events for the instrument; or else logic is. In my case I think it’s kontakt. Thus kontakt can’t garantee the order of the cc events and note events will be consistent when they are close together.

 

I don’t know how spitfire works internally but it’s possible that something similar is at play there. But if you use UACC KS then you won’t have an issue

Link to comment
Share on other sites

I’m on my iPhone now but if you google, spitfire has a whole support page about it.

I don’t know how spitfire works internally but it’s possible that something similar is at play there. But if you use UACC KS then you won’t have an issue

I'm on this page just know, beside LPX open with Chamber Strings, and I'm gonna test.

I wonder how it works with preset that uses velocity to switch between 2 or 3 layers, since UACC KS use velocity.

It's ok with basic patches but I wonder about legatos patches.

Anyway, let's try .

Link to comment
Share on other sites

Update: when I switched to key switching, I found that the dropped-note problems disappeared. So I'm going to agree with deadman's assessment of CC timing as problematic, either in Logic or Kontakt or both. (I suspect this is also why Spitfire recommends UACC KS rather than the CC32 approach.)

 

Keyswitches make it tricky to combine more than one instance in a Kontakt multi. We normally want articulations to be mutually exclusive, and Kontakt instances don't to my knowledge have any way of communicating with one another. So if you want to have access to (say) both Spitfire Violins - Core Techniques and Violins - Decorative Techniques from the same track/articulation set, what to do?

 

As hinted at earlier, my clumsy solution is to use multiple MIDI channels, and include a script that copies CC1 data to all channels, so that each instance gets the same dynamics. It's a kludge but it seems to work, and avoids all the problems I described in the original post.

Link to comment
Share on other sites

Anyway put a dummy articulation on the first line. I use id 254 for this. Assign it no output keyswitches. Then unassigned events will essentially send the keyswitches for that one, which there are none, so none will be sent.

 

Okay, this seems to work ( Although it's seems that Spitfire Kontakt Interface is slow to redraw the exact KS witch is playing :/ )

What should be the best mode ? See the pic. Permanent? Momentary? Retrigger ? I'm a bit lost for this setting ?

 

1872533431_Capturedcran2018-04-0617_09_44.jpg.b5599910979de11d6f8c6c91aea44832.jpg

Link to comment
Share on other sites

Update: when I switched to key switching, I found that the dropped-note problems disappeared. So I'm going to agree with deadman's assessment of CC timing as problematic, either in Logic or Kontakt or both. (I suspect this is also why Spitfire recommends UACC KS rather than the CC32 approach.)

 

Keyswitches make it tricky to combine more than one instance in a Kontakt multi. We normally want articulations to be mutually exclusive, and Kontakt instances don't to my knowledge have any way of communicating with one another. So if you want to have access to (say) both Spitfire Violins - Core Techniques and Violins - Decorative Techniques from the same track/articulation set, what to do?

 

As hinted at earlier, my clumsy solution is to use multiple MIDI channels, and include a script that copies CC1 data to all channels, so that each instance gets the same dynamics. It's a kludge but it seems to work, and avoids all the problems I described in the original post.

 

I think the only way will be to use different midi channels for each instrument in the multi and use a script to duplicate cc events across the needed channels.

 

I wish Kirk hunter would offer alternate keyswitch mode for some of his instruments that require automation. (Sigh)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...