Chord library

[Kyle76]

Once you create a chord, is there a way to save it to a library so that you can recall it as needed?

[Admin]

Unfortunately at the moment we do not have a chord library function in the app. Certainly something we're looking to work into the app, but currently not an option.

-kyle

[Surfwhammy]

Unfortunately at the moment we do not have a chord library function in the app. Certainly something we're looking to work into the app, but currently not an option.

-kyle

Having a SQLite database for chords and lots of other stuff is not difficult to do in a Mac OS X or iOS application, and using low-level C and the SQLite API avoids all the Core Data nonsense, including the intrinsic inability of Core Data to do much of anything with foreign keys, controlled recursion, and so forth and so on . . .

[NOTE: The same strategy works just as easily in the Windows universe, although the relational database typically is different, although it can be SQLite, but so what . . . ]

The basic concept for Core Data comes from NeXTSTEP--specifically the Enterprise Objects Framework (EOF)--and it never was intended to be used as a wrapper for a relational database, which is what ultimately dooms it . . .

From another perspective, the problems are (a) that Apple never has had a relational database and (b) that Apple simply has no relational database smarts with respect to understanding how GUI programmers use relational databases, so instead of having relational databases that are easy to use, the focus is on lists, XML, flat files, and all that linear nonsense, which in some respects is fine if you only need to keep track of 10 to 20 things that essentially never change but is a bit beyond ignorant when there are a lot of things that can change frequently and have intricate and often circular relationships . . .

Using SQLite natively via its low-level C/C++ API is the smart way to do relational database work for the iPad and iPad2, and you can package it in a set of classes or whatever, which as I recall probably includes doing a private framework in one way or another . . .

And once you understand how relational databases work, it only takes about 10 or so tables to do virtually anything, and you can do it with surprisingly simple low-level C/C++ functions and SQL statements, especially if you index everything, since nothing beats an integer index for a stellar foreign key . . .

If you extend the concept into the meta-meta-metadata universe, then it works like shopping for groceries in a typical grocery store, where you know the layout of the store and have a way to determine quickly which products are available, as well as how to get them . . .

As an example, the essential strategy is to go to aisle 10 and then to get the item on third shelf at location 22, all of which are the most simple of all possible SELECT statements, since there are foreign keys and primary keys for everything, which in some respects makes it a curiously surreal network database implemented via relational database technology, and the "grocery store" can be as sophisticated as a Walmart Supercenter, where it also is possible for each item to have its own set additional stuff, which at the nearly absurd but entirely possible extreme makes it like a Walmart Cloud filled with billions of Supercenters . . .

It takes a good bit of low-level C/C++ code, but (a) everything happens in layers and (b) the low-level C/C++ code and SQL statements are simple and fast, so once you have the foundation layers, everything moves to the next higher layer, and once that layer exists, the work moves to an even higher layer, and pretty soon you can get very elaborate sets of information quickly by using a small set of high-level functions, which is fabulous . . .

Fabulous!