setting file

The short answer is the Public files directory /sites/default/files/

The settings file can come from many places. Collections ( related groups of variations ) from http://livethemer.com/collections can have a settings file included.
If visit admin/config/livethemer/livethemer on your site you can see a Select a settings file field that shows the available settings files. They are grouped into Editable and Read-Only. The Editable ones are stored in the public files directory usually sites/default/files. The Read-Only settings files if selected will be copied to your public files directory so they can be edited.

Well, okay...BUT:
1. I created a xxx.settings file in my preferred location (/sites/default/files/livethemer/.), chmod to 775, flushed cache and then went to admin/config/livethemer and selcted my new custom settings file.
2. Imagine my surprise when I peeked at the sites/default/files/ directory and found an identically-named settings file sitting there...
3. Livethemer created this on my behalf?
4. Livethemer is using this new file instead of the one I created (which is still empty)
So, not critical, but certainly confusing... I'd prefer to keep the files directory as clean as possible, heence the desire to use a livethemer directory.
Thoughts/clarifications?
(amazing contribution to the Drupal community btw!)

Livethemer is actually 2 modules, livethemer.module is the engine that displays the theme settings, livethemr_inspector.module is the editor used to create changes to settings files.
When the livethemer_Inspector module is enabled, if you select a read only settings file it is copied over so it can be edited. We assume that you want to make changes when the inspector is enabled.
If you turn off the Inspector and select a settings file then the one you choose will be selected, kept in the location it was chosen from and will be the one used by Livethemer.
You won't be able to make changes until the livethemer_inspector.module is enabled.

Okay, thanks for the additional clarifications.
I'm still having trouble.
Here's a review.
1. Rather than use the supplied settings files, I simply created a new empty file in the files directory and made sure it was writable.
2. When done with edits, I turned off the Inspector module and manually copied the settings file (attached) back to sites/all/variations. The permissionss were left at 775.
3. LiveThemer however now shows 2 copies of the settings file, both under editable.
4. And the theme is not being overridden with changes.
5. Wondering if I had stuffed things up with the custom ssettings file, I started over by enabling the Inspector and selecting clean grey as the active file.
6. I can see that the settings file has been copied into files/ for editing...but
7. The Inspector simply refuses to load.
So, back to basics.
Browser: FireFox, latest updates and Firebug plugin...
Server: LAMP
LiveThemer Debug: nothing returned for any of the settings files selected.
What's next?

Sorry...attachments here.

And yes, extensive use of drush cc -1 in between all of these attempts!

And finally:
Using Chrome (latest) the Inspector loaded and I was able to step through all of the theme changes once again. These were all made to the editable version of clean grey and looked fine with Inspector on.
when done, as instructed, I turned off the Inspector module and made sure that the same editable settings file was selected in the LT config. Cleared cache and...the settings file is not being read. No LT mods are rendered.
No red errors at any stage in Chrome>console...
Clues?

Hi — we'd be interested to know whether you got any Livethemer messages in your site's watchdog. We suspect you'll have this message:

"The Livethemer css overrides file cannot be found. You must re-enable the Livethemer Inspector module in order for it to be regenerated."

Regardless, we have realised that we were doing something quite fundamentally wrong. The generated overrides.css file was prefixed with the theme's name. The overrides css file is actually not related to the theme but to the settings file. Hence we have modified the way the overrides css file is named; it now prefixes with the settings file not the theme. This should fix the problem you have experienced.

We also now generate the x-overrides.css file whenever it can't be found, even if the inspector module is not turned on. Previously the inspector module had to be turned on for the overrides css file to be regenerated.

Thanks for your help improving the way this is handled!

We'll push this to the dev branch now.

Jeff & Tony