Since its earliest incarnations, one of the most common prescriptions for curing Logic of its occasional ills (read: wonky, strange, or seemingly buggy behavior) has been to trash its preference file. This practice is not specific to Logic, as almost all applications create preference files, and when those files occasionally become corrupted they can adversely affect the behavior of the app.
The mechanism behind how such files can ever become corrupted has always been a mystery to me. Maybe it is to you too. Regrettably, I can't shed any light on the causes, though it's not like I haven't tried over the years to find out. You may take solace as I have, however, in the answer provided me from numerous conversations I've had with computer programmers on the question of "why do the prefs get corrupted?" Their answers, almost without variation: "it just happens sometimes".
Thus, while the cause itself is not known (and perhaps doesn't even matter) I can't provide you with, as the old adage goes, an ounce of prevention. What I can offer instead is the pound of cure in the form of:
Before any otherwise mild-mannered Logic user goes off on a preference trashing rampage, it would serve them well to know what their names are and where they're located:
"Main" Logic Preferences (.plist)
Control Surface Preferences
Once you've located those files, you'll be in a fine position to do away with, finish off, rub out, or in some other way dispatch them. Though before taking any such actions, let's get familiar with what kinds of information those files contain.
The .plist preference file stores all of the parameters found under the various tabs in Logic's Preference pane, as well as some important parameters which don't appear in there at all (to be revealed shortly).
Figure 1: General Preferences: Project Handling
There are a considerable number of parameter settings that will be wished into the cornfield (lost forever) by trashing the .plist file.
Wait. I've just realized that the heading for this paragraph in conjunction with "cornfield" might be regarded as an intentional pun. I can assure you, dear reader, that it was not. I would never stoop so low. Never. [ahem]
Consider this: the Preferences Pane has nine categories of options. Between them there are 21 tabs as well as various individual settings panes, totaling over 150 parameters that will potentially be initialized when you trash the prefs. I offer this perspective to temper your enthusiasm should you get the urge to pommel your prefs just because something isn't working right in Logic. Trashing prefs should be a last resort. And trashing the prefs doesn't guarantee that it will fix a problem! But even if you do polish off the .plist prefs in an attempt to right some strange behavior in Logic, you can create additional headaches for yourself by not restoring them back to the setting that gave Logic the operation you were used to prior to finishing off that file.
Here we see the icon for accessing the Preferences as seen in the header above the Arrange area.
Figure 2: Prefs & Settings can be accessed from Logic's Toolbar
It's important to note the distinction between the Preferences and Settings ("Project Settings"). Preferences are "global" and shape the way Logic looks, feels, and operates for any project, whereas Project Settings are parameters used to adjust the behavior or alter various aspects of Logic's operation for individual Projects. Examples of these include the metronome settings, or the number of count-in bars when recording. So when it comes to trashing prefs, a song's Project settings will not be affected.
So when is the right time to consider snuffing your .plist file? Well, let's start with a few situations which, in my opinion, don't warrant trashing prefs:
All of the above are common problems which -- in most cases -- have nothing to do with a corrupt .plist file.
OK, so when should you opt to trash prefs? Well, it would be impossible to catalog all of the errant behaviors that would suggest driving a stake through the heart of the .plist file, especially because the symptoms indicating that Logic's performance is going south can be rather subtle. So my best advice, as I mentioned earlier, is to use the technique of trashing prefs as a last resort when all other troubleshooting efforts have failed to right Logic's wrongs. Trashing prefs, then, is a form of troubleshooting voodoo, but it might just save the day.
Now, this process of "trashing" the preferences is a bit of a misnomer, as it doesn't literally mean finding the .plist file, moving it to the trash, and then emptying the trash. That would be an extreme and unnecessary (if not potentially regrettable) maneuver. Here's the preferred technique:
Upon re-launch, Logic will create a fresh preference file, with all parameters set to their default settings. The very first thing you should do now is re-load your key commands to re-establish the way you navigate around Logic. Next, go into your preference files and re-establish your preferred settings. This means methodically going through the settings and restoring them. Yes, it may be a bit time-consuming, but really you have no other choice if you want Logic to behave as it did (in all the good ways) prior to trashing the prefs.
At this point you should open a song that was previously exhibiting problematic playback and see if trashing the prefs has resulted in a fix.
Assuming that Logic is now running smoothly as a result of forcing it to create a fresh .plist file, there may be some residual "loss" of certain parameter settings. Amongst the preferences and other user settings that are stored in the .plist file are:
Figure 3: the color palette, showing a few custom colors in the lower left-hand corner
Figure 5: EXS24 Sampler Preferences
Figure 6: EXS24 Virtual Memory Settings
If you find that the troublesome behavior that prompted you to trash the prefs remains, you have the option of restoring your original prefs, especially if you wish to regain the attributes that were lost (as listed above). The procedure is:
Out of all of the items that get reset to default settings after trashing the prefs, the one that is the most highly problematic (in my opinion) is the setting for Sample Accurate Automation. The default is "Volume, Pan, and Sends". I don't understand the "logic" of this setting, but be that as it may, after trashing your prefs I suggest setting it to what you see in the illustration below, "Volume, Pan, Sends, Plugin Parameters".
I'll make no bones about it: Logic's control surface preferences are flaky, flaky, flaky. They get corrupted frequently, and even if you don't have a control surface such as a Euphonix or Mackie Control, these prefs can be cause for concern, as they govern the way incoming MIDI messages are interpreted. Symptoms of a .cs file gone bad are:
In these situations it's best to double-check that the fault is not with your controller. But if you're reasonably sure that it's fine, go ahead and "trash" the .cs prefs:
If your controller now works as expected, the likelihood of your .cs prefs having become corrupted is fairly high. One caveat: trashing the .cs prefs will wipe out any custom control surface functions you've programmed (e.g., the Learn function). But what this operation reveals is that you can build a library of custom control surface settings by moving (or copying) those files to a folder to which you give a descriptive name. The reason for this is that you can't rename the .cs files, otherwise they won't be recognized by Logic. And to restore a custom CS setting, quit Logic and swap out the existing .cs file with one of those you've saved.
(Ed- The MIDI Video Tutorial by Peter Schwartz is essential edutainment in my humble opinion. If you work with MIDI in any way, then you need to check this out!)