TChandler

Currently a limitation of Logic's API I'm afraid. Other DAW APIs do support this functionality. Other APIs do support this, and Logic is the odd one out in this regard. Hopefully we can work out a way to support this with Apple in a future Logic update.

Yes this can happen, but "rebuild Defaults" moves all learned assignments to no zone. First the best tip of all: When learning parameters to the USER pages, first Open the controller Assignments dialog and LEAVE IT OPEN, tucked away in the corner somewhere. Sometimes the process of the controller assignments window opening can affect the assignment, but it has to be open as part of Logic's learn mode process. This applies to any controller, not just CS12. With the Controller Assignment dialog open, the most important part next is the correct order for assignment: - Hold SHIFT - Click parameter on plugin - Move control on CS12 - Release SHIFT only when you see the control name in the display, and the control moving on the plugin. The controller assignment is learning the LAST ACTIVATED parameter on the plugin - you are not assigning a parameter to the last turned CS12 control so the order is very important.

So sorry you are having this issue, but the good news is it's often simple to rectify. Please contact Nektar support. If you send your '.cs' file into support we can take a look for you. I'm not a fan of Logic's learn assignments which is why we moved the whole plugin mapping system to controlCore. It's so easy for users to make mistakes. We regularly get reports of a key not working on the keyboard for example and it's always down to a learn assignment of the key's MIDI message. This will happen for soft synth support too in an update, there's a lot more parameters to handle, so we focused on the insert FX first. The CS12 (and other Nektar controllers) do as much as possible to reduce the chance of mis-assignments by putting control of learn on the device, handling learn mode on/off, assigning the correct message type and feedback all just by holding the SHIFT button down on the controller and turning a control. Overall, the process is simple and smooth. However, Logic always learns the 'last learnable parameter' and we can't guard against this being the wrong one. Additionally, when learn is active, even when triggered on our device, Logic is listening out for ANY incoming MIDI fro ANY connected device. So there's also potential for mis-assignment of MIDI messages too particularly if they are transmitting a regular handshaking message (CS12 doesn't do this). Some plugin parameters are not automatable which means they can't be learned, so even if you follow the process exactly, there's still room for error. Since almost all of Logic's actions (including open plugin window and rebuild defaults!) is learnable, if you triggered that, then tried to learn a non-automatable parameter, you would end up mapping rebuild defaults by accident! The best advice I can give is if something does not seem right: - Rebuild Defaults from the Control Surfaces menu - Check 'No Zone' for any odd looking learned parameter. - Check the top level of each control surface for odd looking learned parameters. - Delete anything that doesn't look right! Almost all of the strange behaviour or 'glitches' reported thus far have been down to erroneous user learn assignments, sometimes on other control surfaces. Regarding potential conflicts with Eucon, I can't confirm or deny this as we have no Eucon system to test against, but the .cs file would provide a clue. Best, Tim

ControlCore and Nektarine reference the same file, so they will be picked up automatically, but you may need to toggle ControlCore on and off. ControlCore panel can be opened at //Applications/Nektar/ControlCore. It's a pretty complicated control panel, so here's the full instructions for use: To stop controlCore, click "stop controlCore" To start controlCore, click "start ControlCore" 😉

I suspect you managed to learn an assignment that shouldn't be such as rebuild defaults and Logic still has the assignments stored in the cs file. You need to locate: ~/Library/Preferences/com.apple.logic.pro.cs Ensure Logic is shut down first. Then delete that file. If you deleted the file before Logic was shut down it doesn't work.

1. If you map instrument parameters to the USER1 and USER2 pages in Channel mode, the settings are stored against the instrument - so changing tracks to a different instrument the controls will update automatically. 2. Kontakt is a dynamic plugin that presents different parameters according to the library. Some libraries don't present any parameters at all. To control a parameter on the CS12, it must be automatable in Logic. The first 12 automatable parameters are presented across the 12 rotaries of CS12. So my suggested way of working is to ensure the parameters in each library you want are set as the first 12 automation IDs. 3. The firmware file is in the mountable drive you open to get the nkupdate.app:

You had engaged MASTER mode for the Mixer Channel section. SHIFT+[SELECT] toggles the fader between MASTER and SELECTED CHANNEL. When Master is active, ARM, MUTE, SOLO buttons are all disabled and off, as is the pan pot. That said, it should be resetting to selected channel mode on restarting Logic. I'll double check this.

I believe all the MIDI ports are active in the 'Inputs' tab by default, and you should just leave them like that. Actually I just tried disabling them and this prevents the CS12 working with Logic, so that's something I'll pass over to our support team to add to troubleshooting. Thanks for leading me to this! CS12 is not a standard MIDI controller and there is no need to be concerned with MIDI port assignment. However I think this shows there are existing expectations about how devices work with Logic, that we need to consider in more depth. The majority of CS12 functionality is handled via Logic's API and ControlCore. This includes user assignments. The only time MIDI is used is when making assignments on the USER1 and USER2 pages which uses Logic's internal learn. Even then, the MIDI handling is done for you automatically to ensure correct feedback and MIDI messaging is assigned allowing for high resolution control. The assignments are made as follows: Ensure User1 or User2 pages are active. Hold SHIFT. Move parameter on the instrument. Turn control on CS12 - you will see the parameter name and value appear in the display as the control takes over the assigned parameter. Repeat previous 2 steps as required. Release Shift when done.

First thing to try is to press SHIFT+MIXER on CS12. This closes all plugins and will prevent any CS12 enforced plugin window opening on channel navigation. You can also use SHIFT+<> buttons on CS12 to navigate arranger tracks and you will likely not get this behaviour. Now, here is an explanation of exactly why this plugin window opening happens: The CS12 <> buttons are navigating Mixer channels, not arranger tracks. It does this by banking and selecting the next channel (as there's no global prev/next mixer channel command in Logic). This means the CS12 is able to select aux/bus channels too plus it's much quicker as you can hold a <> button and scroll through channels using Data/Menu. The select operation is the same as pressing a channel SELECT button on any other control surface - which I expect would result in the same behaviour. I believe it was mentioned earlier in the thread someone had experienced this with an SSL controller at some point which makes sense. When a new channel is selected with a control surface Logic automatically opens the plugin window if there are plugin parameters being scanned. The problem is this is not exclusive to the control surface on which the SELECT button was pressed. 😡 Now for the likely source of the problem - In the case of instruments or the first plugin on an audio track opening I suspect it to be a controller keyboard with a Logic script that either uses a plugin host, or is in instrument control mode. In the case of inserts only opening, I suspect a control surface with a plugin host or looking out for specific plugins. In these cases the script for that controller is constantly scanning the first instrument/insert parameter, or the instrument name to see if the plugin host is present. As such, the plugin parameter is always scanned and this results in the plugin window opening on channel change (CS12) or channel select (other control surfaces). In all cases this issue can be addressed in Control Assignments by locating the plugin parameter assignment on the control surface and ticking the 'exclusive' box. Script writers for these control surfaces can (and should) automatically set the exclusive box for a parameter that is to be constantly scanned by adding 'exclusive=true' to the control item entry in their scripts. Nektar controller keyboard scripts have been updated accordingly. Addressing this by removing the .CS file may fix the issue briefly, so long as the plugin parameter that is being scanned is not active on restarting Logic. So if the controller keyboard was connected, the problem would remain. To address the issue properly, please send your .CS file into support and we can build up a support article on how to update the controller assignments for different controllers that present this issue.

Sorry I missed this originally. Rather than listing the maps, it's probably easier to point out the factory map location: //Library/Application Support/Nektar/MapFiles/nektarine/nektarine/Inserts Nektarine and ControlCore share the same map files.

A quick address for some questions/issues that have come up: - Any mapping limitations - Not as far as paging is concerned since we don't use a simple page based architecture. You can create page hierarchy's in Nektarine, with dedicated navigation buttons. There is a limitation of 256 active insert parameters that ControlCore can see due to Logic's control API currently. Should you need to go beyond the first 256 parameters, you can use CSParameterOrder.plist to re-arrange parameters and ensure the first 256 (these are what ControlCore sees) are available. I haven't come across many insert FX with more than 256 params however! - Plugin windows opening on track selection - if plugins are hidden (SHIFT+PLUGIN) they come back into view automatically on track change with the CS12. Instead use SHIFT+MIXER, which closes all plugin windows and prevents opening on track change. Other issues that can cause this behaviour - plugin link set to Multi (yellow). This is detailed in the user guide. With plugin link set to multi it is intended behaviour for the plugin windows to open on track change. Unfortunately beyond the settings that can be handled directly with CS12 there are still settings in other control surfaces that cause windows to automatically open on track change with the CS12. If a control surface is scanning plugin parameters or instrument parameters constantly and hasn't set those assignments as exclusive. This is particularly common where a control surface is using a plugin host/wrapper or a control surface is looking out for specific plugins by name. The workaround is to locate the problem parameter in controller assignments and tick the exclusive box when it is selected. You can also send your CS file into Nektar Support and we will take a look for you. As was mentioned further up in the thread this issue affects other control surfaces too, so it's worth reporting the issue the manufacturer of the non-exclusive control surface. The script developer needs to add 'exclusive=true' when creating the control item mapping for an instrument/plugin name/parameter that is going to be constantly scanned. The majority of problems we've seen in user reports are down to existing controller assignments and other control surface mappings so the CS file is very useful for us. - Mouse Vs CS12. This has come up a few times. The CS12 is not designed to replace the mouse - it's designed to fit with a user's existing workflow. The [SELECT] button functionality gives the user control over any channel parameter clicked with the mouse for example. This was specifically designed to allow focus on the computer screen without having to look down at the control surface. We even added the Fader Mute option [SELECT]+Tap the fader to allow one hand on the pan pot, whilst the other hand is on the mouse selecting the parameters as I was still finding the need to look at where the motor fader relocated too a distraction during sound design. - Nektarine - in the current release for CS12 there is no color setting. Most of what you require for editing plugin maps can be handled on the device. The two editing features you may want to use Nektarine for are: - creating detailed page hierarchy - renaming parameters. To rename a parameter, use the 'display text' column on the control mapping page. Note that for updated text labels to show in Logic, currently you will need to restart controlCore after saving the map in Nektarine. The controlCore panel is available at ~/Applications/Nektar/ControlCore The team are currently working on a Nektarine update for CS12 users. For now I suggest all problems and feature suggestions are reported to support.

No, it's the same part. We've only had 3 reports of touch responsive issues thus far in support, so it's not a common issue. We do want to look at improving resilience to external factors that can affect touch responsiveness so it's important that customers are reporting these issues and in the case of @StudioQ1 we have some excellent data to work with.

There's no restrictions at all in ControlCore, as it's not hosting anything directly and is really just simple data management. However there is a restriction with Pro Tools in that there is no API available for 3rd party manufacturers to integrate hardware with Pro Tools.

I'm glad you were able to address this issue in the end, but to clarify what the problem was: Current version of Logic does not present the input and output gain controls for the compressor to auto-mapping control surfaces. These parameters are missing when a default CSParameterOrder.plist is created for the Compressor. We supply updated CSParameterOrder.plist files which puts these missing parameters back into the parameter list so that they are presented to the CS12. The plist bundle we have provided requires manual copying to ~/Music/Audio Music Apps/Plug-in Settings. We have not included the plists as part of the main installer because: 1. Some people use the plists for re-arranging parameter orders on other control surfaces, so we didn't want to override their settings. 2. This issue has been reported to Apple and should be addressed at some point, in which case you won't need the plists any more. In the meantime, if you find a parameter is mapped but doesn't seem to do anything in our pre-mapped Logic FX assignments it is most likely because the plist files are not installed.

It depends on the plugin unfortunately. If the plugin has the same name string across versions, then it will pick up the VST3 map automatically with the AU version loaded. Unfortunately, some manufacturers use different name strings according to the version and in this case Nektarine/ControlCore effectively sees a different plugin. As above, it depends on the plugin... We have found many workarounds are required in plugin mapping as plugins do not expect such a high level of control. I can recreate the link issue with Slate VCC, it's just how the plugin is handling incoming automation data unfortunately. That said, I can see how we could add a workaround for this via ControlCore. I'll create a feature request to handle linked parameters. It's a good suggestion and one of the workarounds we have missed out. Thanks for the detailed feedback!