I am creating a new component that I want to contribute: the LM4810 by TI.
I noticed there is a very similar component already in the libraries that I have used as a starting point, namely the LM4811. The LM4810 is a variant of the LM4811.
Both are dual headphone amplifiers and linear components. I noticed, however, that the LM4811 is in a library called ‘digital-audio’. I can understand that LM4811 being used in that context, but the only thing digital that the LM4811 has is its touch button volume control. The LM4810 does not.
What shall I do? Put the LM4810 in the ‘digital-audio’ library next to its little sister, break the family ties and put the LM4810 on its own into the ‘audio’ library, or would it be better to move both somewhere else (I propose into the ‘audio’ library)?
The ‘linear’ library seems to be a possible alternative location for these two.
The ‘texas’ library could be another option, but it does not contain linear IC’s as far as I have seen.
I doubt that anybody with more than a few months’ experience will offer a definite answer to your question.
It is probably unwise to store new symbols or footprints in the existing KiCAD library files, unless you are submitting the part for inclusion in the official libraries. It is too likely that your work will get overwritten with the next update.
The KiCAD development team is faced with organizing zillions of electronic parts into a rational library structure. Many of us create and maintain local libraries, either individually or as part of a corporate IT structure, which at first seems like a needless duplication of effort. But most of us probably won’t touch more than a few thousand types of parts, or perhaps a couple tens of thousands, in the course of a professional lifetime spanning a few decades. That makes it practical - and even very desirable - to organize those libraries using a taxonomy different from the file structure of the standard KiCAD libraries.
So my response to your request is, “Create a library structure that makes sense to you, based on the nature of the projects you do, and place your new component accordingly.”. If you do mostly power conversion projects - battery chargers, solar inverters, etc - those headphone amplifiers may end up in the “Miscellaneous IC’s” folder. If you’re focused on data handling systems they may be in “I/O Support”. If your corporate culture is driven by the purchasing department, then “TI IC’s” may be their home. And audiophile specialty companies live in an entirely different world . . .
(A few incarnations ago, the company I worked for had started organizing their schematic symbol libraries by the component’s package style. For example, ANYTHING with a 14-pin DIP footprint was in the same library: TTL logic IC’s, small microcontrollers, (some) quad opamps, DIP switches, resistor packs, etc. I guess it made sense back in the 1960’s when electronics started to replace totally mechanical systems, but the design engineering department was still dominated by mechanical designers. To their credit, the library system was later reorganized to be more in line with electrical function but the old library was left in-place for backwards compatibility; some components appeared in both new and old libraries, sometimes with the same, or different, internal part numbers. As old designs were discontinued or updated the old libraries became less significant but still caused problems.)
That was the whole point: to submit them for inclusion into the official libraries.
I have my personal libraries, but I figured that if we all create components, we might as well submit them for others to use. They would have to be of a certain minimum quality, of course, so it is good that there is a review process in place.
I have not found much useful information in the FAQ for library maintainers on the subject of the organization and structuring components into libraries. Before I file a report, I want to make sure I have not missed some piece of information.
I don’t think there is a detailed explanation what component should go where. (At least not at the moment.)
It is mostly decided on a part per part basis.
But some symbols (and footprints) are not yet organized in their correct library.
My opinion would be to move the complete family to the audio lib. But i don’t yet have enough experience with the kicad lib to really know what is best here. (Maybe @SchrodingersGat or @jkriege2 visit here and voice their opinion. Otherwise you might need to open an issue over at the repo as @keruseykaryu suggested.)
I commented on an existing issue (#1082) to raise the question.
Both @SchrodingersGat and @keruseykaryu have commented on that issue, so I guess they will see my comment.
I have no objections to raising another separate issue, but I do not want to make the list of issues any longer than needs to be.
I will give the definite answer: