I'll just add ones twist to this discussion. I'd like to be able to handle compositions or works in a way that lets me store various information about the COMPOSITIONS. I use the tracks method similar to that described by KAM and I have a compositions look-up file in the form of Composer:Title, but it would be nice to have additional fields for such things as Opus, Year, whether the composition is included in various "Basic Repertoire" listings, and a rating of my fondness for the composition. I've found no way of managing compositions that allows me to do this. At a minimum, a customized look-up file that included additional custom fields would be step in the right direction.

David

... and what prevents this? Have you run out of all other custom fields in CATraxx already??

I've customised my Track form to include fields for Opus No., Catalogue No. (KV, BWV etc), Key, Year Written, the Work a piece of music belongs to (e.g. if I have an isolated recording of an aria, which opera does it come from) etc. As standard every Track has a Rating field - isn't that your fondness value?

Ken

All the additional fields you put in tracks apply to that particular recording of the work, not to the work itself. You could get around this by putting the same "composition" information in each of the index tracks for that work, but that is much less efficient and manageable than recording the information only once in a record in a "compositions" file.

So, if you have 5 recordings of a work, do you fill in all your composition data in each of the 5 index tracks?

David

You can easily enter data once for any track, and then copy your own personalised selection of key data from that track to any other track. This could be all of the composition data you consider to be identical between different versions of the same work.

See this thread where we dealt with exactly the same technique for another purpose. I laid out the detailed steps in message #12 of that thread.

Ken

I noticed this and thought it was pretty interesting. It would still be most efficient to be able to enter and edit data once in a "compositions" file, but in the meantime, this might do. Thanks.

David

CATraxx does not explicitly have the concept of a 'composition' class with multiple instances defining the performer, occasion, location etc. So we'll have to go with what's available, or customise what's there and adjust our ideals to get the best available compromise.

I've just tried an experiment, setting up an Album named "*MASTER COMPOSITIONS - Beethoven" and then entered 14 tracks: one for each piano concerto and one for each symphony. Conceivably you could create albums named "*MASTER COMPOSITIONS - Brahms", "*MASTER COMPOSITIONS - Bruckner", "*MASTER COMPOSITIONS - Busoni" etc. They could all be grouped/filtered/sorted by the name, and you could assign a dummy artist to them all to link by that as well. No data was entered at this stage other than an album title and the track titles. I then created a Track Data Template named 'Classical Composition' and included the various fields that I thought would be of relevance: Name of Work, Year Written, Author/Songwriter, Genre, Key, Opus No., Catalogue No., etc. Next I used this template to fill my 14 Beethoven tracks with this data, taken from existing tracks that had been populated previously (this bit is back-to-front of course - building the class from the instance!) Now I've got a set of 14 definitive classes of data for these Beethoven works that I can use whenever I add another of these instances at any point in the future.
This was easy and quick to do.

Unfortunately for my collection I don't think even this minimal extra work will produce tangible benefits. I don't have so many instances of a given composition that I would save much time when inputting data. The maximum I have for any one item is 10 'Goldberg's followed by 5 'In C's. For the vast majority of my collection I have one instance of any given item.

Undoubtedly there will be problems with the method I've just tried. Will a single album be enough to hold a class track for every composition of someone like Vivaldi? (I remember reading somewhere it was reckoned he'd written about 600 concertos alone. But one other music critic said he hadn't written that many - what he had done was to write one concerto 600 times ) What if you've got a few hundred composers? You'd end up with a lot of *MASTER COMPOSITIONS albums.
Can anyone think of alternatives for Dave?

Ken

Interesting idea, which I will play with. Another option would be just to flag one instance of each composition (in Tracks) as the "master" and to make any changes in the composition data in that track and "clone" to other instances. Conceivably you could automate/update the cloning process in access, though that adds a layer of complication. The advantage of this is that you would not have to set up any "dummy" records; you would just designate an actual record as the master.

Sorry.

My first suggestion was to do exactly this based on an existing actual instance already in your db.
However I got the very clear impression that this had drawbacks for you ("It would still be most efficient to be able to enter and edit data once in a "compositions" file, but in the meantime, this might do.") and then suggested the idea of a separate set of master data.
Now it seems this in turn has so many disadvantages that you're considering using the first method after all.

Perhaps someone else can contribute ideas that will be closer to your needs - I'm out.

Ken

Ken,

Sorry if I didn't fully grasp your first suggestion. I thought I was adding something to it: adding a custom field to mark one track on one album as the master composition track for that work. Probably this would be one's favorite performance of the composition. Changes in composition data would always be made on that track and copied to the other instances of the composition (i.e. other albums). This would allow one to filter on this master composition track to display data about compositions, with one record per composition. If your initial suggestion included this, I'm sorry I missed it.

Your suggestions (again) were very helpful in thinking about options for handling compositions within the current database structure. Thanks.

David

Despite Ken's hyperbolic objection to my method, I'm refreshing this thread to post this wiki link that is generally consistent with the method I've been using for three decades.

http://wiki.musicbrainz.org/ClassicalStyleGuide

I understand that there is more than one way to skin a CAT, but it would be a mistake to dismiss using the Artist field for the composer in a classical-only database, and it looks like that is the direction things are going in the digital audio server world.