What's new

Logic 10.4 Articulation Discussion

I’m assuming it’s using the same trick as the vepro multiport macros, except in a script instead of in the environment; a much better place to do it!
GASP!! Thanks for the clue! Just tested it in a script and it works!
Peter, your secret is out!! But I'm not telling either. :)

Rob
 
@Peter Schwartz

ok I like it! its going to take me a while to go through my template and name and configure every thing....but it all works! so I'm very happy, thank you!


only mistake I made was buying NameX as it was bundled in with ArtzID anyway! doh!
 
Last edited:
@robh
Sorry 'bout dat. It's been my long-standing policy to never discuss the code. All I can say is that I tested the bejesus out of it before releasing it into the wild, so I know it's solid.

@PeterJCroissant
Indeed, CC Cloning is the answer to your question. :)

@procreative
Indeed, when you use a multi-part/multi-track configuration in Logic you are dealing with a single software instrument channel and up to 15 additional "aliases" of that SI channel. They all have MIDI channel settings. The original "real channel" gets set to ch1, the aliases to consecutively higher numbered channels. These act as channel filters. So if you select track 3 (alias instrument 3), only MIDI on channel 3 will be sent to that alias.

Since you're only dealing with one real instrument channel, any MIDI FX apply to the entire instrument. For a MIDI effect to work independently for each channel there would have to be a "poly channel" version of the FX, with up to 16 sets of GUI controls so that each one could be set independently for each channel. The Singularity Script acts "poly channelly" but regular MIDI FX do not.

On a similar-ish note, the fader you see on the real and all the alias channels are one and the same. So if you alter that fader on any one channel, it moves exactly the same amount on all of the others – because there's only really one fader to begin with.

Audio FX will also apply to the entire instrument if you're returning all audio from the plugin to its stereo output. But if you've got the plugin configured for multiple outputs, and signal from outputs 3-4 and higher return to Auxes, then you can achieve independent control over level and FX. Here, the fader on all of the channels (including the aliases) will only affect the level of audio returning to channel 1. And audio FX strapped across the original instrument channel will only affect the stereo output's signal. All other level and FX control is achieved on the Auxes.

(Need more coffee. BRB.)
 
Last edited:
1.Is there a way to control articulations using iPad? 2.When I change a track, can I see different articulations available to choose for each track?
 
1. Yes, if it outputs any kind of CC message, program change messages, or MIDI notes.
2. Yes, of course. :)

For any further questions about my system, please post in my ARTz•ID V2 thread because I think this thread is kinda getting hijacked by so much discussion about my system.
 
Has anyone else noticed a dramatic increase in the frequency of Logic Pro X crashing to the desktop after starting to use articulations, and always upon the sending of an articulation? The fault seems to lie with Kontakt 5.7.3, according to the crash reports. It is often happening to me within a few minutes of starting to use articulations in a Logic project ... in fact, not sure how much I'm going to be able to use them at the current rate of crashes. I've submitted a bug report to NI. (So far I'm using Spitfire palettes with ARTzID 2.0 ... I don't know if the crashes are specific to that set of libraries and components or not.)
 
I'm tempted to think it's a Kontakt problem, perhaps (?) specific to 5.7.3. I've been using Kontakt 5.6.6 and haven't experienced anything like this during development of V2. Ultimately, the messages V2 sends to plugins are no different (and not in excess) of what they'd normally need to receive to switch articulations, except that the timing of those messages is extremely tight with respect to the onset of the notes. However, if you were to use Logic's built-in articulation switching, you'd find it performs in exactly the same way.

It would definitely help to try and narrow down the players... Is it always the same libraries and palettes? Does it happen with Play-based instruments as well? Etc.
 
I haven’t been getting any crashes and I’ve been using articulation sets a lot lately with heavy scripting. Did you upgrade to 10.4.1 yet?
 
I haven’t been getting any crashes and I’ve been using articulation sets a lot lately with heavy scripting. Did you upgrade to 10.4.1 yet?

Yes. This seemed to start after that (although I wasn't making very heavy use of articulations prior to that, so I don't think it was necessarily introduced with the update). Anyway, the likelihood is that Kontakt is at fault, given that the console log always points to it.
 
I'm tempted to think it's a Kontakt problem, perhaps (?) specific to 5.7.3. I've been using Kontakt 5.6.6 and haven't experienced anything like this during development of V2. Ultimately, the messages V2 sends to plugins are no different (and not in excess) of what they'd normally need to receive to switch articulations, except that the timing of those messages is extremely tight with respect to the onset of the notes. However, if you were to use Logic's built-in articulation switching, you'd find it performs in exactly the same way.

It would definitely help to try and narrow down the players... Is it always the same libraries and palettes? Does it happen with Play-based instruments as well? Etc.

I agree about Kontakt being the most likely culprit. Hopefully NI will use the crash log I sent them to figure it out.

It's been happening with a variety of palettes from several Spitfire libraries (mostly SSO, but not exclusively). I don't have any Play libraries, so I can't check that.

I do have the CC Cloner multiscript currently running in Kontakt, and I'm not sure it is strictly required for my current use cases (the ones I've told you about via email, where everything is on channel 1), so I am going to try disabling that, in case it is happening in that part of Kontakt.
 
I think I might be on to something regarding these crashes. I took a closer look at the stack dump from the crashed thread, and here are the last several lines:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 Kontakt 5.MusicDevice.component 0x000000012c06de34 NI::UIA: Picture::getAnimationWidth() const + 4
1 Kontakt 5.MusicDevice.component 0x000000012b132f13 ScriptUIModuleBase::setLabel(int, int, int) + 1859
2 Kontakt 5.MusicDevice.component 0x000000012b130611 ScriptUIModuleBase::setControlPositions() + 4145
3 Kontakt 5.MusicDevice.component 0x000000012b11a3ce ScriptUIModuleBase::SyncToEngine(bool) + 206
4 Kontakt 5.MusicDevice.component 0x000000012b11989d PerfViewModule::onEvent(unsigned int, NI::UIA::EventData*) + 301

This looks to me like something in either the Spitfire UI or the Kontakt UI (I'd suspect the former, but I don't have a symbol file for Kontakt of course, so I can't know) is attempting to respond to an event like the change of articulation, and then resulting in the following crash while it is attempting to measure the size of some screen element (as if perhaps the element hasn't been loaded yet):

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000038
Exception Note: EXC_CORPSE_NOTIFY

So tonight I've been trying to work with the Kontakt UI closed during articulation changes (which is awkward, since I'm in the process of creating articulation mappings), and I've been able to continue for a while now without any more crashes. If this holds up, then the crashes would probably be a less common issue in actual production use, since once I have my articulation mappings set up, I won't need to have the UI open nearly as much. Still, it seems like something that should be fixed by one of the parties involved.

It would be interesting to hear if others who have not had these crashes with 5.7.3 (or earlier versions), and especially others who have Spitfire libraries, could respond as to whether they've had the Kontakt UIs for these libraries visible during the articulation changes, and if not, if they might try leaving the UI open for a while and see if they start having these same crashes.
 
So tonight I've been trying to work with the Kontakt UI closed during articulation changes (which is awkward, since I'm in the process of creating articulation mappings), and I've been able to continue for a while now without any more crashes. If this holds up, then the crashes would probably be a less common issue in actual production use, since once I have my articulation mappings set up, I won't need to have the UI open nearly as much. Still, it seems like something that should be fixed by one of the parties involved.
i have had this type of crash as well when testing out my maps. as it turns out, i never really got to the ground of it. for a while i had the suspicion that it only happens when you switch to one of the legato instruments (assuming that you have multiple SF instruments stacked in one kontakt instance). which library are you having this problem with, with me, it was symphonic strings.

this is how it looks here. i'd say that's the same crash:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000038
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 Kontakt 5.MusicDevice.component 0x0000000136386e34 NI::UIA::Picture::getAnimationWidth() const + 4
1 Kontakt 5.MusicDevice.component 0x000000013544bf13 ScriptUIModuleBase::setLabel(int, int, int) + 1859
2 Kontakt 5.MusicDevice.component 0x0000000135449611 ScriptUIModuleBase::setControlPositions() + 4145
3 Kontakt 5.MusicDevice.component 0x00000001354333ce ScriptUIModuleBase::SyncToEngine(bool) + 206
4 Kontakt 5.MusicDevice.component 0x000000013543289d PerfViewModule::onEvent(unsigned int, NI::UIA::EventData*) + 301
5 Kontakt 5.MusicDevice.component 0x0000000135a2406e NI::NGL::SubFormControl::onEvent(unsigned int,
 
Last edited:
I think I might be on to something regarding these crashes. I took a closer look at the stack dump from the crashed thread, and here are the last several lines:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 Kontakt 5.MusicDevice.component 0x000000012c06de34 NI::UIA: Picture::getAnimationWidth() const + 4
1 Kontakt 5.MusicDevice.component 0x000000012b132f13 ScriptUIModuleBase::setLabel(int, int, int) + 1859
2 Kontakt 5.MusicDevice.component 0x000000012b130611 ScriptUIModuleBase::setControlPositions() + 4145
3 Kontakt 5.MusicDevice.component 0x000000012b11a3ce ScriptUIModuleBase::SyncToEngine(bool) + 206
4 Kontakt 5.MusicDevice.component 0x000000012b11989d PerfViewModule::onEvent(unsigned int, NI::UIA::EventData*) + 301

This looks to me like something in either the Spitfire UI or the Kontakt UI (I'd suspect the former, but I don't have a symbol file for Kontakt of course, so I can't know) is attempting to respond to an event like the change of articulation, and then resulting in the following crash while it is attempting to measure the size of some screen element (as if perhaps the element hasn't been loaded yet):

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000038
Exception Note: EXC_CORPSE_NOTIFY

So tonight I've been trying to work with the Kontakt UI closed during articulation changes (which is awkward, since I'm in the process of creating articulation mappings), and I've been able to continue for a while now without any more crashes. If this holds up, then the crashes would probably be a less common issue in actual production use, since once I have my articulation mappings set up, I won't need to have the UI open nearly as much. Still, it seems like something that should be fixed by one of the parties involved.

It would be interesting to hear if others who have not had these crashes with 5.7.3 (or earlier versions), and especially others who have Spitfire libraries, could respond as to whether they've had the Kontakt UIs for these libraries visible during the articulation changes, and if not, if they might try leaving the UI open for a while and see if they start having these same crashes.

Just a thought, maybe you could open your Kontakt instrument in standalone just to view for setting up the Maps? I have not got around to Spitfire libraries yet, but not had crashes anywhere else... yet.
 
Just a thought, maybe you could open your Kontakt instrument in standalone just to view for setting up the Maps? I have not got around to Spitfire libraries yet, but not had crashes anywhere else... yet.

I am using ARTzID to combine both multiple palettes into a single Kontakt instance ... I'm not sure if I can do the same thing without ARTzID in the mix. Also, if the crash is in Kontakt scripting code, I'm betting it would occur in standalone as well. Still, it might be worth a try to verify things. Thanks!
 
Top Bottom