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



## stigc56 (Mar 8, 2018)

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?


----------



## resonate (Mar 8, 2018)

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.


----------



## procreative (Mar 9, 2018)

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.


----------



## Dewdman42 (Mar 9, 2018)

_*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.*_


----------



## resonate (Mar 10, 2018)

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?



Dewdman42 said:


> 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:


----------



## Dewdman42 (Mar 10, 2018)

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?


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> 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.


----------



## Alex Fraser (Mar 10, 2018)

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?


----------



## Dewdman42 (Mar 10, 2018)

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".


----------



## Dewdman42 (Mar 10, 2018)

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.


----------



## Alex Fraser (Mar 10, 2018)

Dewdman42 said:


> 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!


----------



## Dewdman42 (Mar 10, 2018)

Alex Fraser said:


> Leads me to believe it might be a design feature as it routes CC data to "where it needs to be" in certain setups.



Oh wait, can you please explain your thought here a little bit more?


----------



## Dewdman42 (Mar 10, 2018)

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


----------



## Alex Fraser (Mar 10, 2018)

Dewdman42 said:


> 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.


----------



## Dewdman42 (Mar 10, 2018)

Alright my conclusion for feedback to Apple is:

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.
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.
I think LPX also needs to chase CC's, PB, aftertouch, when channelizing events via the articulation set.
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.


----------



## procreative (Mar 10, 2018)

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...


----------



## Dewdman42 (Mar 10, 2018)

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.


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> 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.
> 
> ...



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.


----------



## procreative (Mar 10, 2018)

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.


----------



## stigc56 (Mar 10, 2018)

Hi
Here in Denmark it`s about bed time, but tomorrow I`ll be back, and join in on this thread.


----------



## Dewdman42 (Mar 10, 2018)

procreative said:


> 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.



The problem is not related to the articulation Set output keyswitch. The problem is most likely related to the way the OP is using Articulation Sets. There is either a conflict with CC1 between the VSL instrument and the artset, or he could have some kind of midi loop that is bringing the keyswitch back around into logic again or something of this nature. Please read more carefully the thread until now.

secondly, you actually WANT CC's to have articulation id set. Apple is right to do it that way and Peter should consider doing it also in artzid if he's not already. The reason is because, take an example where you have a keyswitch that switches something in the instrument and now the instrument needs to receive a couple of CC's before it receives any notes with that articulation, for whatever the reason. So actually you DO want CC's, PitchBend, aftertouch, etc to have articulation id embedded so the instrument-change will happen before those events come into it. 



> 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.



It won't always be ID1, see below. Yes of course if you have CC's with id1 already on your region and you don't want them to send keyswitches then you can ignore ID1, but how did they get there to begin with? They got there because someone hit the input keyswitch, which means they wanted it and need it, or if they hit a different keyswitch then the ID will be something else, also wanted and needed.



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



Try again, I did a test with 3 articulation id's defined and if you hit the input keyswitches while while also sending some CC's into LPX...then each CC will have the latest articulation you switches embedded. Not just #1.

what I didn't try is to see what happens if NO input keyswitches are defined, does LPX default to id#1 in that case? If so that would be a legit bug.


----------



## Dewdman42 (Mar 10, 2018)

procreative said:


> 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.



I don't entirely understand what you're saying you do, but I can replicate the ID's in CC's very simply without any hardware...just create an articulation set, add some input keyswitches for each one and start playing the Musical Typing keyboard. Send an input keyswitch from there. then send some CC's, they will all have that articulation id embedded. Hit a different input keyswitch and the following CC's will have the different art id.

I don't think this is a bug, this is by design. 

Back to the OP, please let us see some info about your articulation set, project and VSL details and we might be able to figure out what is getting confused.


----------



## Dewdman42 (Mar 10, 2018)

Ok, I think this is a legimate bug, I just confirmed it...

Basically if you have an articulation set WITHOUT any input keyswitches, then its assigning artid=1 to everything coming in. This DEFINITELY needs to be reported to Apple as a bug.

And in this case, i agree, if you aren't using any input keyswitches to trigger articulations, then just don't use artid=1 for any of the actual articulations to avoid it being relevant. 

It brings up another interesting question, I can't see any way at all with articulation set's to play in notes without some kind of articulation id always needing to be assigned. there is no way to clear it to zero. Once you have an articulation set active, then every event must have an articulation id assigned and if you don't add them as input keyswitches, they will all be art=1. And while you're playing, every single note has to be assigned to an artid, none can be zero.

So yea, ignore art=1 and treat that one like zero. Personally I think this is a bug or design oversight by Apple...


----------



## babylonwaves (Mar 10, 2018)

Dewdman42 said:


> I don't think this is a bug, this is by design.


it is by design.


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> The problem is not related to the articulation Set output keyswitch. The problem is most likely related to the way the OP is using Articulation Sets. There is either a conflict with CC1 between the VSL instrument and the artset, or he could have some kind of midi loop that is bringing the keyswitch back around into logic again or something of this nature. Please read more carefully the thread until now.
> 
> secondly, you actually WANT CC's to have articulation id set. Apple is right to do it that way and Peter should consider doing it also in artzid if he's not already. The reason is because, take an example where you have a keyswitch that switches something in the instrument and now the instrument needs to receive a couple of CC's before it receives any notes with that articulation, for whatever the reason. So actually you DO want CC's, PitchBend, aftertouch, etc to have articulation id embedded so the instrument-change will happen before those events come into it.
> 
> ...



Yes seems you are right, I seldom record my CC while playing the notes in I usually do it on a second pass.

Regarding CC data with IDs, in my tests the IDs do nothing to notes as the notes only play using the ID attached to them. Also if needed you can change all the IDs attached to CCs in the Event Editor after, just select them all and change them.

I cannot see a problem with the VSL instrument. If you record the appropriate articulation and move the modwheel at the same time then both would have the same ID. But if you do it as a second pass that might be why? But as I said you can easily fix it in the Event Editor, or get Artz ID as it has scripts for VSL.


----------



## Dewdman42 (Mar 10, 2018)

So basically imagine an example where you are you playing some stuff with mod wheel and notes... along you go, moving the mod wheel and playing the notes. At some point you hit the input keyswitch for a different articulation. You do this right before you move the mod wheel where you want it before hitting the note, and then you hit the note. So both the modwheel value and the note are part of this new articulation you want to sound off.

Now imagine that the actual instrument you're using is requiring a program change as the actual keyswitch, and that its actually changing a preset...such that you need this new preset to receive both the modwheel value followed by the note after that. This is the case where having artid attached to the CC is critical so that it will be the CC that fires off the preset change in the instrument before sending the CC and then the note in that order.

Just one example. I think its by design that CC's and everything else have articulation ID set and there should not be any harm by it either.

I'm thinking right now that Artzid will also be plagued a bit by this fact that articulationSets always force all events to artid=1 even when no input keyswitches are defined. Artzid is using the articulationSet instead of the macro it had before. So it will have the same issue. The only difference may be that artzid is not even looking at CC's with artid's and sending any keyswitches..its waiting for the notes...but see above...artzid might want to consider sending keyswitches for all events with artid's.

Its possible the OP is running into something related to artid1, but I still suspect they have some kind of conflict related to CC1 that can be resolved by looking carefully at the articulationset and midi routing in LPX.


----------



## procreative (Mar 10, 2018)

I just did a quick test. I recorded a Marcato line and CC1 at the same time. Both notes and CCs had the ID for Marcato embedded. I did this by selecting the ID using the menu in the Piano Roll window.

I then went back and changed the IDs for the notes to Con Sordino for half and Temolo for the rest and on playback the CC data still controlled the dynamic levels for both even though they say Marcato in the Event List.

Not sure about your other scenario as not using my main machine. I use a Lemur app and CC32 sending the ID and not note based keyswitches to trigger my IDs.


----------



## Dewdman42 (Mar 10, 2018)

Using CC32 or keyswitch for the input trigger makes no difference. Either way, ArticulationSet feature is designed currently that ALL events played in will have some kind of articulation id. They will have artid=1 if you don't switch to something else. And its desirable for all events to have articulation id for the reasons I explained above. The example you tried is not quite the same situation. There are any number of possible reasons why some instrument out there might need to change setups in some way and need to get some CC values updated to it after the change, before sounding any notes.


----------



## Dewdman42 (Mar 10, 2018)

so anyway to summarize, I think in general its probably a good practice to treat artid=1 as the default articulation which you either want to mean NOTHING or else to refer to some basic sound always. 

If you want it to behave like artid=0 (aka, nothing), then you create an articulation=1 that never has an outgoing keyswitch, yet still provide an input keyswitch in order to put LPX into the mode of encoding events with artid=1. 

I think it would be better if LPX were treating artid=0 that way rather then artid=1, artid=0 should be the "nothing" articulation. Well id=0 is the nothing articulation, but there is no way to put the articulationset into the mode of encoding incoming events with id=0. so that's the workaround I guess.

This might solve the OP's problem, but I'm still suspicious there is something in his articulation set or midi routing that is conflating the use of CC1


----------



## babylonwaves (Mar 10, 2018)

my best practise is to record with the intended articulation. and if i change the ID on notes later, controllers will make the display "jump" but it won't do anything bad - UI based load aside, depending on the instrument. IMO it would be better if logic would give you an option on which type of MIDI data carries an ID but for now, my personal setup works just fine. @Dewdman42: ID0 is undefined (not sure if you mean that by calling it "nothing"). and "undefined" will always be treated like the first available ID available in logic.


----------



## Peter Schwartz (Mar 10, 2018)

Dewdman42 said:


> I'm thinking right now that Artzid will also be plagued a bit by this fact that articulationSets always force all events to artid=1 even when no input keyswitches are defined. Artzid is using the articulationSet instead of the macro it had before. So it will have the same issue. The only difference may be that artzid is not even looking at CC's with artid's and sending any keyswitches..its waiting for the notes...but see above...artzid might want to consider sending keyswitches for all events with artid's.



No such issues exist with ARTz•ID. Not in version 1, not in version 2.


----------



## Peter Schwartz (Mar 10, 2018)

...and not with SkiSwitcher either, running my Retrofit files.


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> so anyway to summarize, I think in general its probably a good practice to treat artid=1 as the default articulation which you either want to mean NOTHING or else to refer to some basic sound always.
> 
> If you want it to behave like artid=0 (aka, nothing), then you create an articulation=1 that never has an outgoing keyswitch, yet still provide an input keyswitch in order to put LPX into the mode of encoding events with artid=1.
> 
> ...



I dont know if I am misunderstanding you, but I did some experiments with CSS with the output of Art Sets going to CC58. Even though the GUI flickered around, it always played notes with the correct articulation and any ID data on CC seemed only to affect the notes. 

So if I used CC1 (Dynamics) on a Sustain, it conrolled the Dynamics. If I then changed the IDs of the notes to another articulation and it was one using Dynamics eg a Tremolo, the CCs still correctly controlled this.

This is in spite of either the GUIor the data in the Event list indicating otherwise.

Maybe there might be scenarios where this might be an issue, I just haven't found them...

But for matrix VSL stuff or other VIs that use CC for other things (CSS note keyswitches use CC1 to switch between shorts), maybe there might be issues. The solution is ArtzID for these.


----------



## Dewdman42 (Mar 10, 2018)

Peter Schwartz said:


> No such issues exist with ARTz•ID. Not in version 1, not in version 2.



Does artzid send keyswitches for CC's that have an articulation id? People have been saying it doesn't. If it doesn't, then there could be an issue. If it does, then there could be the other issue with artid=1. There is so much confusion on these articulation id threads.... I'm not even sure if you know what you're responding to.

Anyways at this moment I'm more interested in figuring out the ins and outs of using LPX without any addons.


----------



## Dewdman42 (Mar 10, 2018)

babylonwaves said:


> my best practise is to record with the intended articulation. and if i change the ID on notes later, controllers will make the display "jump" but it won't do anything bad - UI based load aside, depending on the instrument. IMO it would be better if logic would give you an option on which type of MIDI data carries an ID but for now, my personal setup works just fine. @Dewdman42: ID0 is undefined (not sure if you mean that by calling it "nothing"). and "undefined" will always be treated like the first available ID available in logic.



what I was trying to explain, but apparently did poorly is that there is no way with the existing articulation set feature to play in notes and events and have them assigned to artid=0 (aka nothing). All midi events you perform into LPX while an articulation set is active must have an articulation id >0, so getting that "nothing" behavior is not possible while you're playing it in. Unless you assign art=1 to that role. Of course you can change them to zero after the fact if you want. By nothing, I mean notes and events that basically don't have an articulation id assigned them at all and would hence by ignored by any outgoing keyswitch engines. In LPX you assign artid=0 to essentially unassign any articulation id's to it.


----------



## Dewdman42 (Mar 10, 2018)

procreative said:


> I dont know if I am misunderstanding you, but I did some experiments with CSS with the output of Art Sets going to CC58. Even though the GUI flickered around, it always played notes with the correct articulation and any ID data on CC seemed only to affect the notes.
> 
> So if I used CC1 (Dynamics) on a Sustain, it conrolled the Dynamics. If I then changed the IDs of the notes to another articulation and it was one using Dynamics eg a Tremolo, the CCs still correctly controlled this.
> 
> ...




Yes you are misunderstanding me.

That situation is not the scenario I described.

I agree with you that some gui flickering is minimal impact, but its still important to figure out exactly what is happening to make sure its not too much of that. I think the OP of this thread is having a different problem anyway.

I think this thread is just going around in circle now from lack of understanding each other, and then its starting to be another sales pitch which I dislike very much here. When the OP comes back with his project details we might be able to help him.


----------



## Alex Fraser (Mar 10, 2018)

procreative said:


> I dont know if I am misunderstanding you, but I did some experiments with CSS with the output of Art Sets going to CC58. Even though the GUI flickered around, it always played notes with the correct articulation and any ID data on CC seemed only to affect the notes.
> 
> So if I used CC1 (Dynamics) on a Sustain, it conrolled the Dynamics. If I then changed the IDs of the notes to another articulation and it was one using Dynamics eg a Tremolo, the CCs still correctly controlled this.
> 
> ...


I think that would be the expected behaviour. It’s the same with Spitfire. A Kontakt patch that’s multi-articulation won’t distinguish cc dynamic events from different articualtions. It’s all treated as one and the same. 
(This is really hard to articulate into words!)


----------



## babylonwaves (Mar 10, 2018)

Dewdman42 said:


> what I was trying to explain, but apparently did poorly is that there is no way with the existing articulation set feature to play in notes and events and have them assigned to artid=0 (aka nothing). All midi events you perform into LPX while an articulation set is active must have an articulation id >0, so getting that "nothing" behavior is not possible while you're playing it in. Unless you assign art=1 to that role. Of course you can change them to zero after the fact if you want. By nothing, I mean notes and events that basically don't have an articulation id assigned them at all and would hence by ignored by any outgoing keyswitch engines. In LPX you assign artid=0 to essentially unassign any articulation id's to it.


exactly. that's the way it is. my point is simply that there is a conceptional difference in between "nothing" and "undefined".


----------



## procreative (Mar 10, 2018)

Alex Fraser said:


> I think that would be the expected behaviour. It’s the same with Spitfire. A Kontakt patch that’s multi-articulation won’t distinguish cc dynamic events from different articualtions. It’s all treated as one and the same.
> (This is really hard to articulate into words!)



Yes I get that, but the IDs attached to the CCs would indicate otherwise.

As it stands (so far) I cannot see any detrimental effect playback wise. Kontakt multis use midi channels to separate each patch rather than keyswitches and these set up right wont suffer from incorrect IDs on CCs either (Ive tried).

I just cannot get the scenario Dewdman42 is referring to as I have not encountered these issues whether using switching based on Midi Note, CC or Midi Channel.

To me it seems like IDs on CC dont have much effect on note playback, they just drive GUIs made. But unless you have them open its probably an irrelevance.


----------



## Dewdman42 (Mar 10, 2018)

that is definitely how people should expect their experience to be, and when you have a single multi-keyswitch instrument that is typically what happens. But all I'm saying is there are situations where the instrument setup might not be that conveniently setup and so hence you might need to have some articulated CC's make the switch ahead of the notes. This might include a rechanelized multi setup for example, or perhaps some other setup that most people using all the current orch libs don't deal with (this feature isn't just for you), where you need the articulation id to actually change an instrument preset or something, not just change the articulation within a single preset. So anyway, these kinds of situations might need CC's to have the articulation id in them for that reason. It makes perfect sense and this is what LPX currently does!


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> All midi events you perform into LPX while an articulation set is active must have an articulation id >0, so getting that "nothing" behavior is not possible while you're playing it in. Unless you assign art=1 to that role. Of course you can change them to zero after the fact if you want.



Not possible, changing the notes to "nothing" still makes them play back using the articulation set on ID1. From what I can see there just is not an ID0.


----------



## Dewdman42 (Mar 10, 2018)

if you change the articulation to "-" in the piano roll what happens? It becomes "undefined", can we agree that's the right term people can accept for zero? In a script you set it to that by using zero. In the piano roll or event list you can set it to "-", which is the same thing. 

Now what happens is that if another previous articulation id was in effect, then undefined "-" events don't change a thing and the sound continues with whatever was loaded in the instrument. That doesn't mean it will be id=1. Its just an undefined, do nothing assignment. no keyswitches will ever be sent out for events with "-" (or zero) for the articulation id.


----------



## Peter Schwartz (Mar 10, 2018)

Dewdman42 said:


> Does artzid send keyswitches for CC's that have an articulation id?



No.



> People have been saying it doesn't.



I don't know who these people are, but they are correct. 



> If it doesn't, then there could be an issue.



Like I said, there are no issues.



> I'm not even sure if you know what you're responding to.



I'm only responding to your supposition from a few posts up where you wrote, "I'm thinking right now that Artzid will also be plagued a bit by this fact that articulationSets always force all events to artid=1". I'm saying that there is no such issue.


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> But all I'm saying is there are situations where the instrument setup might not be that conveniently setup and so hence you might need to have some articulated CC's make the switch ahead of the notes.



But thats supposed to be the advantage of using IDs in the first place. They dont need to be in advance of notes, thats why the play back more reliably than either automation or note based systems.

I am sure there might be some setups that "might" prove tricky. Find an example though as I have tried them on:

1. Keyswitch based single patches
2. CC based single patches
3. Midi Channel based multis of single patches
4. Keyswitch based multiple patches separated by Midi Channel (example use Adagio/Anthology made up of 4-5 patches, some Keyswitch some single patches)


----------



## Dewdman42 (Mar 10, 2018)

well what I'm saying Peter, is you should consider sending keyswitches for CC's and other events that have artid assigned. That is the behavior of Logic and I have laid out several times now the reason why this could be useful, and no harm caused by it either.

Further to that, you should consider that if someone doesn't wish to use input keyswitches, then they may not realize they are recording a long series of many events that are actually encoded with artid=1, whether they intended it or not. In many ways it would be good if your stuff also treated id1 as reserved.


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> if you change the articulation to "-" in the piano roll what happens? It becomes "undefined", can we agree that's the right term people can accept for zero? In a script you set it to that by using zero. In the piano roll or event list you can set it to "-", which is the same thing.
> 
> Now what happens is that if another previous articulation id was in effect, then undefined "-" events don't change a thing and the sound continues with whatever was loaded in the instrument. That doesn't mean it will be id=1. Its just an undefined, do nothing assignment. no keyswitches will ever be sent out for events with "-" (or zero) for the articulation id.



Have you tried this? Because I did and no matter what articulation was the starting point, the system directed the notes to whatever ID1 was set to even if they were set as - or 0 in the event editor.

There is no 0 in the Logic system, it might say so, but its not what it triggers.

Perhaps you should clarify your statements as to me it sounds like some of it is hypothesising rather than based on actually trying them?

I have experimented a fair bit with this system and can categorically say that setting it to ID - (or 0/undefined whatever) triggers whatever is on ID1.


----------



## Dewdman42 (Mar 10, 2018)

procreative said:


> But thats supposed to be the advantage of using IDs in the first place. They dont need to be in advance of notes, thats why the play back more reliably than either automation or note based systems.
> 
> I am sure there might be some setups that "might" prove tricky. Find an example though as I have tried them on:
> 
> ...



Well that is one use for it, its not the only use for it. Its certainly nice that in many cases you can move notes around and the articulation id has everything it needs and that is still the case when CC's are encoded with artid also. But if you have some kind of CC automation that needs to continue through the articulation change, this just makes sure that it happens. I'm sorry you don't understand me but you've tired me out now I'm tired of trying to explain it. LPX works this way and its a good thing.


----------



## Dewdman42 (Mar 10, 2018)

procreative said:


> Have you tried this? Because I did and no matter what articulation was the starting point, the system directed the notes to whatever ID1 was set to even if they were set as - or 0 in the event editor.
> 
> There is no 0 in the Logic system, it might say so, but its not what it triggers.



procreative I think you just want to argue. Good luck


----------



## Dewdman42 (Mar 10, 2018)

honestly this thread has become entirely annoying while people are arguing about definitions of words and philosophical ideals. I'm out of here, but if the op Responds I will help him try to figure out why his CC1 is going crazy. As usual the articulation vendors have shown up to pitch their stuff......(sigh)


----------



## babylonwaves (Mar 10, 2018)

Dewdman42 said:


> Now what happens is that if another previous articulation id was in effect, then undefined "-" events don't change a thing and the sound continues with whatever was loaded in the instrument.


no, an "-" (undefined) ID will be interpreted as the first possible ID. what you want is possible in cubase as a "direction" but is not available in logic. i'm not trying to argue at all, if it comes across like that.


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> procreative I think you just want to argue. Good luck



I think you obviously have an ego problem. Its not about definitions, ID0 or - does not work, simple. Does not matter what you define it as. Its nothing to do with philosophy or disagreeing with hypotheses, its real world use.


----------



## Dewdman42 (Mar 10, 2018)

babylonwaves said:


> no, an "-" (undefined) ID will be interpreted as the first possible ID. what you want is possible in cubase as a "direction" but is not available in logic. i'm not trying to argue at all, if it comes across like that.



Interpreted by who? If you assign "-" to a note in piano roll or event list, then play the note, with loggin in scripter you can see articulationid=0. it will not be handled as the first articulation id, it will simply not have any articulation effect whatsoever...whatever sound is currently set to play in the instrument will keep playing.


----------



## Dewdman42 (Mar 10, 2018)

procreative you have not understood me and I'm tired of explaining it. Read above again when you are willing to try to understand.


----------



## Peter Schwartz (Mar 10, 2018)

Dewdman42 said:


> well what I'm saying Peter, is you should consider sending keyswitches for CC's and other events that have artid assigned. That is the behavior of Logic and I have laid out several times now the reason why this could be useful, and no harm caused by it either.



I don't see any point in doing that.

I think the missing piece of the puzzle here is (and I say this with all due respect) that you don't know the ins and outs of how my system is configured. You're making assumptions about how it works, what it does and doesn't do, and what it should and shouldn't do. That's not to say that I don't appreciate suggestions on how I could make the system better. But in the meantime, everything works just fine. There are, simply put, no issues like the kinds you guys have been talking about.



> Further to that, you should consider that if someone doesn't wish to use input keyswitches, then they may not realize they are recording a long series of many events that are actually encoded with artid=1, whether they intended it or not. In many ways it would be good if your stuff also treated id1 as reserved.



These things don't happen, so they're not a consideration for the design of my system. There's no reason to treat ID#1 as reserved. In fact, in artzid, ID#1 represents the first articulation in any patch, regardless of the patch type.


----------



## Dewdman42 (Mar 10, 2018)

I don't really care to understand the ins and outs of your system Peter, you have another thread for that. This thread is about solving a problem outside of your system and several people keep trying to pitch your stuff like its the solution to everything, and I'm not meaning to dog your system as a matter of fact I have reccomended in numerous times, but what I have said is true and accurate and you can choose to ignore my suggestions or be argumentative about it..but what I have said is accurate. cheers


----------



## babylonwaves (Mar 10, 2018)

Dewdman42 said:


> interpreted by who? If you assign "-" to a note in piano roll or event list, then play the note, with loggin in scripter you can see articulationid=0. it will not be handled as the first articulation id, it will simply not have any articulation effect whatsoever...whatever sound is currently set to play in the instrument will keep playing.


make a region, assign the first note some articulation which is greater thank ID 1 and the following notes to "-". you'll see, the following notes are not playing the articulation of of the first note. does that make sense?


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> Interpreted by who? If you assign "-" to a note in piano roll or event list, then play the note, with loggin in scripter you can see articulationid=0. it will not be handled as the first articulation id, it will simply not have any articulation effect whatsoever...whatever sound is currently set to play in the instrument will keep playing.



What point are you trying to make, what has the scripter got to do with it? Its irrelevant.

We are talking about the Articulation Sets, they do not recognise ID=0. Changing a note to that makes no difference as it defaults to ID1. I know, I have tried it - have you?


----------



## Peter Schwartz (Mar 10, 2018)

BTW (and this is the very last time I'll say anything like this) I'm absolutely NOT posting here to pitch my products. I find the practice reprehensible. It's the very reason I suggested (twice) in another thread that discussion about my system should be posted in my own thread. 

Any developer should be able to participate in a thread when misinformation about their products is being promulgated. Even if that misinformation is based on completely innocent assumptions, that doesn't preclude the developer from saying, "um, well, no, that's not quite the case".


----------



## Dewdman42 (Mar 10, 2018)

Procreative, you are again just arguing to argue, I'm convinced....

Yes I have tried it. Here is the logging output i see in scripter after having three nots, first one is id=1, the next two are id="-"

this is the output in scripter logging:


```
Evaluating MIDI-processing script...
Script evaluated successfully!
[  1.0  ] NoteOn           [C4]   vel:80    ch:01 art:1  
[  2.0  ] NoteOn           [C4]   vel:80    ch:01 art:0  
[  3.0  ] NoteOn           [C4]   vel:80    ch:01 art:0
```

scripter detects them as undefined. If they are undefined then no keyswitches are sent. The instrument will play whatever is currently loaded.


----------



## Peter Schwartz (Mar 10, 2018)

Dewdman42 said:


> I don't really care to understand the ins and outs of your system Peter



You should if you're going to talk about what problems it might or might not have. That would only be fair, yes?



> This thread is about solving a problem outside of your system and several people keep trying to pitch your stuff like its the solution to everything, and I'm not meaning to dog your system as a matter of fact I have reccomended in numerous times, but what I have said is true and accurate and you can choose to ignore my suggestions or be argumentative about it..but what I have said is accurate. cheers



I know you've been supportive of my system, and that you've recommended it. That's not lost on me. And I'm not trying to be argumentative. I'm not even _being_ argumentative. But if I can't state that what you've said is inaccurate, and that your suggestions -- thought appreciated -- are not applicable, then what am I supposed to say?


----------



## Dewdman42 (Mar 10, 2018)

Peter Schwartz said:


> BTW (and this is the very last time I'll say anything like this) I'm absolutely NOT posting here to pitch my products. I find the practice reprehensible. It's the very reason I suggested (twice) in another thread that discussion about my system should be posted in my own thread.
> 
> Any developer should be able to participate in a thread when misinformation about their products is being promulgated. Even if that misinformation is based on completely innocent assumptions, that doesn't preclude the developer from saying, "um, well, no, that's not quite the case".



There has been no misinformation. Your system does not detect and handle CC's with articulation id's. You want to argue about whether that is a problem or not. i say it is. Also your system will be plagued with the same confusion surrounding the fact that unswitched incoming events will be tagged as id=1 by default. Its not a slam against your system, its a slam against LPX in that case, but your system doesn't do anything to aleviate that issue. These are true facts. You are just arguing dude.


----------



## Peter Schwartz (Mar 10, 2018)

Dewd, Dude!

We can slam the current system (sans artzid or any third party solution) all day long. There's lots to slam. There's also lots to love. The current implementation is not what it should be/could be.

But man, when you say, "your system will be plagued with the same confusion surrounding..." I have to say, "no, my system will not be plagued" cuz it izn't.

It just isn't.

That's it. End of story. No argument, no adrenaline rush, no rise in blood pressure. Just a neutral statement of fact.


----------



## Dewdman42 (Mar 10, 2018)

what I mean is that your system doesn't provide a solution around that dilema, and it doesn't. You are now using the articulation set mechanicms instead of the macro, which means it is plagued by the same issue. Maybe you don't understand the issue that was being discussed. Procreative doesn't either.


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> Procreative, you are again just arguing to argue, I'm convinced....
> 
> Yes I have tried it. Here is the logging output i see in scripter after having three nots, first one is id=1, the next two are id="-"
> 
> ...



Actually you are the one arguing. It does not matter what the scripter processing is saying because thats not how the Logic system is processing it.



Dewdman42 said:


> Now what happens is that if another previous articulation id was in effect, then undefined "-" events don't change a thing and the sound continues with whatever was loaded in the instrument.



You said the above and this is incorrect. The Articulation Sets do not process ID0. Does not matter what the scripter is telling you.


----------



## Dewdman42 (Mar 10, 2018)

EXACTLY procreative...the articulation set does not process the "-" events, which is why they will play whatever sound is currently loaded....NOT the sound for id1 as you suggested.


----------



## Alex Fraser (Mar 10, 2018)

I think I know where is argument is going to go, so I’ll try to mediate by suggesting that..

Peter’s system (as I understand it) is designed around a typical use case for most Kontakt setups and users. Probably 95% of users don’t require cc dynamic data to carry an articulation payload and therefore Peters system works great and as advertised. 

Logics in-house approach considers that cc dynamics data might want articulation ID payloads. For example, multiple ESX24 instances in a track stack would benefit from this. 

Both systems have merit, pros and cons. I do think that Peters system is more reflective on how most folks use articulation switching though.


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> EXACTLY procreative...the articulation set does not process the "-" events, which is why they will play whatever sound is currently loaded....NOT the sound for id1 as you suggested.



And I am telling you that is not what I am seeing. I have tested it and it does not do that.

I selected an articulation other than the first slot in my Kontakt instrument, changed the recorded notes to Articulation "–" in the Event Editor and on playback these still played the articulation assigned to ID1.

Maybe you are using an EXS patch or something else, but Kontakt, Play etc do not behave like this.

Anyway Im in the UK so its way past bedtime and my teddy's getting lonely.


----------



## Dewdman42 (Mar 10, 2018)

because that was the sound currently in the instrument


----------



## Alex Fraser (Mar 10, 2018)

procreative said:


> Anyway Im in the UK so its way past bedtime and my teddy's getting lonely.


<looks at clock.>
Ah, yes. Bugger. Damn you, VI Control..


----------



## procreative (Mar 10, 2018)

Dewdman42 said:


> because that was the sound currently in the instrument



To explain here is my setup test:

ID1 = Sustain (which is the default first patch)
ID2 = Marcato
ID3= Staccato

I record notes on ID2, change them in the Event Editor to -, then change the playback patch to ID3 or Staccato.

As soon as I hit play the pre-recorded notes play Sustain despite being set as -


----------



## procreative (Mar 10, 2018)

Anyway, we'll just have to differ as you seem to refuse to accept I have tried it and the result contradicts what you said.


----------



## Dewdman42 (Mar 10, 2018)

if what you say is true, then its a bug, report it to apple. good night


----------



## stigc56 (Mar 11, 2018)

babylonwaves said:


> my best practise is to record with the intended articulation. and if i change the ID on notes later, controllers will make the display "jump" but it won't do anything bad - UI based load aside, depending on the instrument. IMO it would be better if logic would give you an option on which type of MIDI data carries an ID but for now, my personal setup works just fine. @Dewdman42: ID0 is undefined (not sure if you mean that by calling it "nothing"). and "undefined" will always be treated like the first available ID available in logic.


It's certainly true, that it doesn't DO anything, but in the case that I reported it's a rather busy string section playing lots of different articulations on VSL Synchron Strings running on in VEPro6 on a slave, and the "jumping about" may put some strain on my slave don't you think?


----------



## Dewdman42 (Mar 11, 2018)

can you post the articulation set you’re using or send via pm? My view is that if the GUI is changing at all when you don’t want and expect keyswitches, then it should be looked into.


----------



## Dewdman42 (Mar 12, 2018)

So I have been doing some testing and just want to clarify the "feature/bug" pointed out by procreativ where keyswitch for id1 is sent out for any events that are undefined.

What I have discovered is that its not neccessarily id1. Its the "first" articulation, whatever id it has. So the following two things happen when an articulation set is active:

If you don't specify an input keyswitch or none is active, then incoming midi during record will get encoded with the id# of the "first" articulation on the list. If the first one has an id=49, then that will be the id encoded to incoming midi events, unless via input keyswitch you select a different articulation. If the first one is id1, then obviously it will be #1, which is probably most common. This includes even when the MIDI REMOTE button is off, because basically the plugin window has the little articulation control added now and whatever is selected there will be encoded into midi you're playing, like it or not. There is no option to turn that off as long as an articulation set is active.
During playback, undefined events playback the keyswitch corresponding to the "first" articulation, again regardless of the actual id#. If the first one is #49, then fine... any events in the pianoroll with undefined artid "-" will play back the keyswitch of the first articulation. Its not clear to me right now, whether the plugin window articulation control effects this or not
The above is the reason the OP was getting his flickering GUI. When he recorded his parts, he may not have used input keyswitches. So all midi events, including CC, were encoded with id=1. Later he used the pianoroll to set the articulation id's for many notes to something other than id1. Now during playback, if there are CC's happening at the same time as notes..then the notes all have to fire their keyswitch and the CC's in between fire the keyswitch for id1 and it goes back and forth like that with a lot more keyswitches then neccessary.

The work around is to make sure the first articulation in the list is something called "reserved" or "-" or whatever you want to call it, that has no output keyswitch. Use a very high id#. The highest artid allowed is 254. Then the second articulation in the list would be id1, id2, etc..

With the above then all non-switched incoming midi would be assigned "reserved" artid=254. Later you edit the notes to whatever articulation you want and during playback all the CC's with artid=254 would not send out the spurious keyswitches. Also any events with undefined "-" artid will attempt to play the keyswitch for the first articulation(254) and since no keyswitch defined for it, no problem.

I have submitted bug/feature requests to apple about this and I hope they will consider changing the default behavior, but I'm not holding my breath.


----------



## stigc56 (Mar 26, 2018)

I think people tend to be angry with each other here, that makes me sad!
Well I went back to the problem, and made an articulation set with a dummy as the first art id. In the articulation set I just set the output to "nothing". So it worked for a while and then not


----------



## Dewdman42 (Mar 26, 2018)

When you say it worked for a while and then not... what started happening wrongly?


----------



## mc_deli (Mar 27, 2018)

Car crash thread guys. Not one of our best. In the absence of moderation, please be civil.
I think everyone on this is trying to help each other but maybe a little more velvet glove


----------



## stigc56 (Mar 27, 2018)

Well I found a way I think. The first art. should be a dummy, and send nothing to - in my case VEPro running VSL Synchron Strings. This way the modwheel - controlling the VelocityXfade - will send no KS to the VEPro. The drawback is that the default KS will be gone, replaced by the last.


----------



## Dewdman42 (Mar 27, 2018)

stigc56 said:


> Well I found a way I think. The first art. should be a dummy, and send nothing to - in my case VEPro running VSL Synchron Strings. This way the modwheel - controlling the VelocityXfade - will send no KS to the VEPro. The drawback is that the default KS will be gone, replaced by the last.



Yea unfortunately in order to insert a dummy at the top of the list you have to manually shift all the rest down by one row because the lame editor in LPX doesn’t have the ability to insert a row. You can also try to edit the plist file directly if you’re brave. But anyway you still want to see artid1, etc but you need the dummy one at the top of the list in order to essentially have no default.


----------



## stigc56 (Mar 27, 2018)

Well I have been on to it all day. Now doing it in Excel for Mac, using VBA. Planning to share it with you all when it's a bit more complete. But it's working and I can reuse the maps for similar instruments, like all VSL woodwinds and so on. Have to filter Aftertouch and all that though, but it's easy in the preferences.


----------



## Dewdman42 (Mar 27, 2018)

Would love to see the vba!


----------



## stigc56 (Mar 27, 2018)

Go ahead, please remember it's definitely a "work in progress"!!! 
https://www.dropbox.com/s/tdlav9lof4htn4b/Logic Articulations Mapper V0.6.xlsm?dl=0


----------



## Dewdman42 (Mar 27, 2018)

Very interesting...... please keep us posted...


----------



## Vik (Mar 27, 2018)

Dewdman42 said:


> the lame editor in LPX doesn’t have the ability to insert a row.


Send them feedback about that:
https://www.apple.com/feedback/logic-pro.html


----------



## Dewdman42 (Mar 27, 2018)

already have


----------



## Dewdman42 (Oct 2, 2018)

I just want to report that I have been testing out 10.4.2 to see what they fixed in terms of some of the bugs we found in 10.4.1, but it still has some of these bugs, I don't think they fixed it. Its not really clear to me what they did, according to their notes, they totally missed the problem it seems. I just reported 4 new bug reports to apple about it. 

My opinion is that 10.4.2 output switching from articulation sets is still fundamentally broken and unusable, better use your own scripts or one of the third party solutions like artzid or AG. Just use articulation set for the naming of articulations and nothing else. I also would not recommend using input switches, but that might be ok for some.


events without articulation id are still ending up having the output switching sent as defined for the first articulation on the list. That includes any keyswitches or channelizing needed
If you try to combine channeling with a key switch using the multi-switch support, the key switch will not be sent on the channel you provide and that the event is being channelized to.
If you try to use the articulation set to channelize events, but set the track channel to a specific #, then the articulation set won't channelize it, the track setting overrides it. Has to be set to ALL. This could be a big problem for multi configurations.
if you have an articulation set active, you can't record any events to a track without at least one of the articulation id's being encoded into every event..there is no way to disengage or choose "-" as the articulation id to use while recording an event. Other then disabling the articulation entirely. I did not test to see whether CC's will always get that mandatory articulation id assigned to them or not, but its a problem.
There was something else I reported that I can't recall now.


----------



## rconn (Nov 28, 2018)

I've just come back to the idea of using articulation sets with 10.4.2. It looks like the articulation ids for CC messages are now being stripped out and you can't assign an articulation to them in the event list. They are marked with a "-". Before this would cause the default articulation to fire, but it seems like that is no longer the case. I need to do more extensive testing but it looks like this is fixed.


----------



## PaulBrimstone (Feb 22, 2020)

Dewdman42 said:


> Yea unfortunately in order to insert a dummy at the top of the list you have to manually shift all the rest down by one row because the lame editor in LPX doesn’t have the ability to insert a row. You can also try to edit the plist file directly if you’re brave. But anyway you still want to see artid1, etc but you need the dummy one at the top of the list in order to essentially have no default.


Sorry to revive this old thread, but I'm trying to insert a dummy at the top of the artic list, as recommended. However, I'm darned if I can manage to shift the other artics down in order to make space. Has Logic changed, and does anyone know how to do this, please?


----------



## Dewdman42 (Feb 22, 2020)

You can’t, the editor sucks. So you have to manually edit all the rows. You may be able to edit the plist directly if you’re brave


----------



## PaulBrimstone (Feb 22, 2020)

Dewdman42 said:


> You can’t, the editor sucks. So you have to manually edit all the rows. You may be able to edit the plist directly if you’re brave


Gah, as in rewrite every list — no thank you! But thanks for the quick response, @Dewdman42. I might have a go at the plist edit, though. Light a candle for me...


----------



## Dewdman42 (Feb 22, 2020)

OS X has a built in command line utility called PlistBuddy which might be helpful. You might be able to make a script that inserts the row at the top for you that way


----------



## Alex Fraser (Feb 22, 2020)

Dewdman42 said:


> the editor sucks.


Correct.


----------



## PaulBrimstone (Feb 22, 2020)

Dewdman42 said:


> OS X has a built in command line utility called PlistBuddy which might be helpful. You might be able to make a script that inserts the row at the top for you that way


Good to know, @Dewdman42 I managed a manual edit, thanks, but will certainly check out the utility, which would save a lot of time. Or I might just give up entirely and migrate to StaffPad  Cheers.


----------



## Dewdman42 (Feb 22, 2020)

Here is a quick bash shell script I just made using PlistBuddy that can basically insert a dummy articulation row at the top, it inserts it with ArticulationID=254. Pretty easy operation with PlistBuddy actually, but anyway with this script you can just call the script and the name of the plist file, and it will do it all quickly. enjoy


```
#!/bin/bash
# Script to insert one dummy articulation at top of articulationSet

CMD="/usr/libexec/PlistBuddy -c"

for count in "$*"
do
    NEXT=`$CMD "print :Articulations" steve.plist |\
         awk ' BEGIN {max=0} $0 ~ /^[ ]*ID =/ {if($3>max) max=$3} END {print max+1}'`

    $CMD "Add :Articulations:0 dict" "$count"
    $CMD "Add :Articulations:0:Output array" "$count"
    $CMD "Add :Articulations:0:ID integer" "$count"
    $CMD "Set :Articulations:0:ID ${NEXT}" "$count"
    $CMD "Add :Articulations:0:ArticulationID integer" "$count"
    $CMD "Set :Articulations:0:ArticulationID 254" "$count"
    $CMD "Add :Articulations:0:Name string" "$count"
    $CMD "Set :Articulations:0:Name Dummy" "$count"
done
```

let me know if you have any questions about it.


----------



## Dewdman42 (Feb 22, 2020)

As a follow up, I just want to give instructions for how to manually insert a row into an articulationSet using PlistBuddy. Its not that hard and this is a common situation where the articulationSet editor basically sucks. So here is how to do it pretty easily with PlistBuddy. yea I know this is the scary command line prompt, but if you need to insert a row into an articulationSet, this is the only easy way right now.


Open a terminal window and cd to directory where the articulationSet plist files are found


```
cd ~/Music/Audio Music Apps/Articulation Settings/
```



Backup any plist files you intend to operate on here!



Run PlistBuddy and specify the name of the plist file you are going to edit:


```
PlistBuddy myfile.plist
```



a PlistBuddy prompt will present itself and await for you to ender PlistBuddy commands. What are those commands? You can find out by googling PlistBuddy and find out a lot, but also there is a manpage for it, which you can view like this:


```
man PlistBuddy
```



Once you have the PlistBuddy prompt, you can use the *PRINT* command to display the contents of the articulation set in a formatted way:


```
Command: print
```



You will see there is an array called *Articulations*. Each element of that array includes *ArticulationID*, *Name* and *ID*. You will need to look through this array and see what the largest ID value is, its usually the last one. For example:




```
Articulations = Array {
   Dict {
      Output = Array {
      }
      ArticulationID = 38
      Name = Articulation 38
      ID = 1038
   }
}
```

In the above, the last articulation has an ID field value of 1038. write that down. That should be the largest ID value, generated by LogicPro in the articulationSet until now, you will need to use a higher ID number for the new row you will insert, such as 1039 in this case. But just in case, look through the listing to make sure that new ID number is not being already used. Doesn't really matter what it is, just something that isn't already used.


If you want to insert a new articulationID, for example, at row #5, then remember that number and the above largest ID number used, then do something like the following at the PlistBuddy command prompt:


```
Add :Articulations:5 dict
Add :Articulations:5:Output array
Add :Articulations:5:ID integer
Set :Articulations:5:ID 1039
Add :Articulations:5:ArticulationID integer
Set :Articulations:5:ArticulationID 26
Add :Articulations:5:Name string
Set :Articulations:5:Name My New Articulation 26
```



Don't forget to use the PlistBuddy *SAVE* command to save the results after you do a print to make sure it looks how you want.


----------



## PaulBrimstone (Feb 23, 2020)

Dewdman42 said:


> As a follow up, I just want to give instructions for how to manually insert a row into an articulationSet using PlistBuddy. Its not that hard and this is a common situation where the articulationSet editor basically sucks. So here is how to do it pretty easily with PlistBuddy. yea I know this is the scary command line prompt, but if you need to insert a row into an articulationSet, this is the only easy way right now.
> 
> 
> Open a terminal window and cd to directory where the articulationSet plist files are found
> ...


Fantastic—what a gift! Thank you for taking the time @Dewdman42. I will definitely summon up my courage and give this a try.


----------



## Dewdman42 (Feb 23, 2020)

Ps or you can also just copy and paste the xml directly which is actually easier the More I think about it but you have to make sure you get the xml syntax right. In any case PlistBuddy is an easy way to make automated scripts for this kind of thing. For example the script I shared a few posts ago could easily be changed to insert the new row at row five instead of at the top of the list. And it could even be adapted to take a parameter to specify the row number, which would be a very useful script actually. Anyway the above instructions may be useful for someone


----------



## Dewdman42 (Feb 24, 2020)

Here's an updated version of the shell script I posted earlier. This shell script is actually pretty useful, basically it will insert one row to the indicated articulationSet plist file. By default it inserts a row at the top of the list, with artid=254 and the name "dummy", but some command line options are provided to set it to any row you want and use any artid or name you want.

enjoy

save this into a file, make sure the file has execute permissions and then execute it from the command line. Using -h will give you the command line options


```
#!/bin/bash

LINE=0;
ARTID=254
NAME="NEW"
CMD="/usr/libexec/PlistBuddy -c"
THISCMD=`basename $0`
read -r -d '' USAGE <<EOB
Usage: ${THISCMD} [options] file.plist

Options:

  -l <n>     line number  (default 1)
  -n <name>  articulation name (default "NEW")
  -a <artid> articulationID (default 254)
  -h         help
EOB

#===================================
# check for line number argument -n
# default is first line
#===================================

while getopts 'hl:a:n:' FLAG
do
    case "${FLAG}" in
        a) ARTID="${OPTARG}"
           ;;
        n) NAME="${OPTARG}"
           ;;
        l) LINE=$((OPTARG-1))
           ;;
        h) echo
           echo "$USAGE"
           exit 1
           ;;
        *) echo
           echo "$USAGE"
           exit 1
           ;;
    esac
done

if [ $OPTIND -gt $# ]
then
    echo
    echo "ERROR missing filename"
    echo
    echo "$USAGE"
    exit 1
fi

#======================
# Get the filename
#======================

shift "$((OPTIND-1))"
FILE=$1

#==========================================
# look for the largest ID value used in
# plist Articulations array, use one higher
#==========================================

NEXT=`$CMD "print :Articulations" $FILE |\
     awk ' BEGIN {max=0} $0 ~ /^[ ]*ID =/ {if($3>max) max=$3} END {print max+1}'`

#==========================================
# Call PlistBuddy to add the row
#==========================================

$CMD "Add :Articulations:${LINE} dict" "$FILE"
$CMD "Add :Articulations:${LINE}:Output array" "$FILE"
$CMD "Add :Articulations:${LINE}:ID integer" "$FILE"
$CMD "Set :Articulations:${LINE}:ID ${NEXT}" "$FILE"
$CMD "Add :Articulations:${LINE}:ArticulationID integer" "$FILE"
$CMD "Set :Articulations:${LINE}:ArticulationID ${ARTID}" "$FILE"
$CMD "Add :Articulations:${LINE}:Name string" "$FILE"
$CMD "Set :Articulations:${LINE}:Name ${NAME}" "$FILE"
```


----------

