What's new

Logic script, that filter Articulation ID's from CC's messages

stigc56

Senior Member
Hi
I think I have read something about this issue, but nevertheless here it is:
In a VSL Timpani Preset (Synchron Percussion) I select a RollsXF Patch and use the CC1 as control for Velocity XFade.
Now I can see in The Event List, that the CC1 also have an Articulation ID's attached to it, meaning that the Preset will switch back to Articulation 1, the moment there is CC1 in the part.
Is there a script that filter out the Articulations ID from CC's?
 
Looks like the current articulation is attached to CC while recording with faders. If you write it in with a pencil, the articulation is not attached. You can set all the CC's articulation value to "-", that should get rid of the problem.
 
Last edited:
The only workaround is two options:

1. Make ID1 do nothing, eg put your first articulation on ID2, just put a dash for the name and nothing else.
2. Get ArtzID, which uses a MidiFX script and due to it only processing IDs on notes gets round this.*

* This requires a little bit more work, but not too much as the naming is in the Logic Sets now.
 
UPDATE: Never mind the previously provided script is pointless and doesn't solve anything. The problem is that the articulation set is sending out keyswitches before it even hits the script.
 
Last edited:
Thank you for the script. Is it possible for it to work when recording live CC's from the fader controller (because the articulations are still glued to the cc's when i tried it ) or it's supposed to filter the data just before sending it to vepro/kontakt?

That seems like a bug in the articulation Set feature, so please submit feedback to apple. If you don't use ArtziD, you can easily write a simple scripter script yourself to strip articulationID from all CC's, that looks like this:
 
The script can only block it from kontakt. Which now that I think about it may not solve your problem. I want to try to replicate this later and if I figure something out as a work around I will let you know. You said the cc’s are always encoded with articulation id =1? Are you using any input keyswitches and if so do they effect the way cc’s get encoded?
 
Last edited:
The script can only block it from kontakt. Which now that I think about it may not solve your problem. Please make sure to report this to Apple I don’t think the articulation set input keyswitches should be assigning articulation id to anything other then notes. I want to try to replicate this later and if I figure something out as a work around I will let you know. You said the cc’s are always encoded with articulation id =1? Are you using any input keyswitches and if so do they effect the way cc’s get encoded?

I don't think your script works. I can still see GUI jumps to ID1.

From my tests so far, CCs recorded via hardware are fader events, they seem to automatically attach ID1 events to them no matter what CC you are recording.

With most libraries, it does not affect playback but does drive the GUIs demented.

If you draw in CC data it does not have ID info on it.
 
Forgive me if I'm talking rubbish, but it's not the ID's you want to block from reaching Kontakt; it's the midi events triggered by the map "output" tab (as part of the CC control payload) that are causing the mischief.

Block these, you block the keyswitches and the entire premise falls on it's head. Catch 22?
 
Last edited:
no exactly... it was stupid on my part in terms of the script, that's what I meant by this "may not solve your problem" above. You got me back to my computer, can you post the articulation set you're trying to use so I can replicate it? This seems like a bug in LPX, but I want to fully understand it. Also as someone else suggested, if its always encoding an articulation id of 1 into the CC events, then just make sure that there are no outgoing keyswitch assigned to articulation id 1, then it doesn't matter. If you buy Artzid, then basically you will be bypassing the articulation set keyswitching behavior and avoid this "bug".
 
Yea I just ran a quick test and basically, articulation Set input keyswitches are assigning articulation id to all incoming events, including notes, CC's or any other kind of incoming event.

It is NOT limited only to articulation id #1, so the suggestion earlier of just ignoring articulation 1 will not solve the problem. The problem is the input keyswitches get assigned to all incoming midi events.
 
Last edited:
no exactly... it was stupid on my part in terms of the script, that's what I meant by this "may not solve your problem" above. You got me back to my computer, can you post the articulation set you're trying to use so I can replicate it? This seems like a bug in LPX, but I want to fully understand it. Also as someone else suggested, if its always encoding an articulation id of 1 into the CC events, then just make sure that there are no outgoing keyswitch assigned to articulation id 1, then it doesn't matter. If you buy Artzid, then basically you will be bypassing the articulation set keyswitching behavior and avoid this "bug".
Haha, it's a rabbit hole for sure.
In my tests, the articulation ID (and therefore midi keyswitch data) attached to CC events was basically the same as the active articulation when recording. Leads me to believe it might be a design feature as it routes CC data to "where it needs to be" in certain setups.
Basically, we need a way to turn it off!
Best of luck with the scripts!
 
I guess you're saying if the CC's have articulation id assigned, then you can channelize CC's and everthing based on te articulation id...so in that case where channelizing, such as to a multi..that is actually I guess what you'd want, though its missing chasing, but I digress... So maybe articulation set needs to just be smarter in terms of not sending the outgoing keyswitches ahead of non-note events....but channelizing based on articulation id, yes
 
I guess you're saying if the CC's have articulation id assigned, then you can channelize CC's and everthing based on te articulation id...so in that case where channelizing, such as to a multi..that is actually I guess what you'd want, though its missing chasing, but I digress... So maybe articulation set needs to just be smarter in terms of not sending the outgoing keyswitches ahead of non-note events....but channelizing based on articulation id, yes
Yep, pretty much this.

That said, if you create a multi in Kontakt and simply split your single articulation patches across multiple midi channels, then you can bypass the map output tab entirely, as a midi channel can be assigned to an articulation directly..

<head blows off.>

What we basically need is a 4th page on the map - "filter" with options to define certain CC numbers as "non articulation events." Or the same as a global option for the project.
 
Last edited:
Alright my conclusion for feedback to Apple is:
  1. I think LPX should provide a way to play in parts without forcing artid assignments (while an articulation set is active), allow "-" events in. Right now it forces unswitched input events to be assigned to the first articulation in the list, regardless of what the actual id# is.
  2. Notes and events in the piano roll with undefined articulation id “-“ are having the keyswitch for the first articulation in the list sent out. Events without articulation assignment should not be sending out keyswitches, that is the OP’s main problem.
  3. I think LPX also needs to chase CC's, PB, aftertouch, when channelizing events via the articulation set.
  4. I think LPX needs to support sending multiple keyswitches per articulation.
And actually the more I think about it, if a user has played in a keyswitch ahead of some CC events, and if there are keyswitches associated with that articulation, then you absolutely DO want the keyswitches to happen for non-note events, because the CC's might be relevant.

Now back to the original question, upon reading it a little closer, it might be different entirely then the direction we have been going with this. I think the real problem the OP is having is related to a conflict over CC1:

Now I can see in The Event List, that the CC1 also have an Articulation ID's attached to it, meaning that the Preset will switch back to Articulation 1, the moment there is CC1 in the part.

I need to see the articulation set he is trying to use and understand better the way he has his channel setup, it doesn't entirely make sense what he's saying.

So basically the way LPX works, while recording in a part, or playing from a keyboard...incoming keyswitches will change what the "current" articulation id is. Any notes or events happening after that keyswitch will get tagged with that id. At the same time this is happening, or during playback of a region, then articulation id is read from every event. Every time the "current" articulation id changes from that, then a keyswitch will be sent to the instrument. If its the same id being repeated, then no keyswitches are sent to the instrument. Only when the next event has a different articulation id then the previous, then the "current" articulation id is changed to that one and the keyswitch is sent...regardless of the event type.

I don't see any reason why this should cause VSL to change patches other then there is some kind of conflict with the way CC1 is being used in both VSL and the articulation set, or something like that.
 
Last edited:
I think the reason it does not work is because the Midi FX scripts come after the Articulation Set. From what I can see the Articulation ID hits the Articulation Set and generates whatever is set in the Output tab of it.

So altering the ID in a script fixes that, but its already too late because for example if the output are Keyswitch notes, these are already created.

The only workaround is to reserve ID 1 for a blank articulation. Or use ArtzID...
 
yes we already figured that out and went through all that above, did you read it?. thanks though. I think the original poster has a different problem anyway.

And no reserving id1 won't solve the problem because the input keyswitches will set many different articulation id's into CC events as they are keyed in by the user. Its not just art 1 that is effected.

As mentioned earlier, you actually WANT the CC's to have articulation Id anyway, that was the wrong rabbit hole to go down. The OP must have some other kind of user error in terms of the way he's using CC1 in his articulation Set and in VSL that conflicts...we need more information about his logic project to dive any deeper into that.

Its not clear to me that artzid would react any differently, it might have the same issue.
 
yes we already figured that out and went through all that above, did you read it?. thanks though. I think the original poster has a different problem anyway.

And no reserving id1 won't solve the problem because the input keyswitches will set many different articulation id's into CC events as they are keyed in by the user. Its not just art 1 that is effected.

As mentioned earlier, you actually WANT the CC's to have articulation Id anyway, that was the wrong rabbit hole to go down. The OP must have some other kind of user error in terms of the way he's using CC1 in his articulation Set and in VSL that conflicts...we need more information about his logic project to dive any deeper into that.

Its not clear to me that artzid would react any differently, it might have the same issue.

ArtzID does not have this issue at all as it intercepts the output keyswitches in Articulation Sets, additionally it only attaches IDs to notes, nothing else. When you use it with Articulation Sets ArtzID takes care of where to send the IDs and the Logic side has nothing in the Output tab.

In my simple tests, creating ID1 as a dummy with no output did indeed prevent any rogue data sending from CCs. Sure the data is still attached to CCs, but it has nowhere to go as the ID has no output set.

From all the tests I have done, CCs always seem to have ID1 attached.

However none of the VIs I have seem to suffer incorrect switching of actual articulations as all the data sent from CCs wont get embedded with note events.
 
I might also add I have a MidiFX script to automate CCs and because it records automation which gets passed to the CC controls in a VI never generates IDs as this "bug" only seems to affect Midi CC that has been recorded via hardware.
 
Hi
Here in Denmark it`s about bed time, but tomorrow I`ll be back, and join in on this thread.
 
Top Bottom