Make one Filemaker record for each track.
In the record the fields would be: Track code, name of track, name of album, Composer, performer, conductor etc..
You can then sort on Album, or on Composer or what ever etc..
You can then make subsummary fields that automatically group the tracks into albums in track order or in composer order or....
You base the DB on the smallest unit (i.e the track)
For this to work you will need to work out a short code to be able to give each track a unique code. This can be automated.
You can then manipulate the information any way you want.
I'd suggest you use the following tables (that's files in version 6);
Tracks would be related to Albums by AlbumID. Credits is related to both Tracks (by TrackID) and People (by PersonID), and has a field for the role that person performed on the track.
Excellent! Yesterday, I studied Filemaker Pro databases I prepared several years ago and, as well, my iTunes list, but I couldn't quite figure out what to do because I was conceiving of the project as being based on albums. In the middle of the night, I awakened with the realization that the solution probably lay in dealing with the smallest unit -- an individual track -- and building up from each of these small units instead of creating a record for an album, and trying to break it down. It's conceiving of the project more like a spreadsheet, really, more like iTunes lists. Your reply this morning confirms my idea and provides much more detail, with clear guidance. I especially appreciate your mention of the subsummary fields -- which I have never created -- as something I can add after all the track data is complied. Many, many thanks for your excellent suggestions.
I do have one further question: Why is a track code necessary? And what should it contain? Would it be sufficient for the code to simply be a sequential number, indicating the order in which the records were prepared (the track code for the first track record I prepare would be 1; the second, 2; etc.) or should the code attempt to convey, say, an album number, LP number within the album (for multi-LP boxed sets), side, and then track? For example, in the first album, which is a boxed set comprising eight LPs, the second track on the back side of the third LP could be designated 001.03.B.02 (first album, third LP, back side, second track) -- but is this necessary, or desirable?
Thanks, Comment. I'm a novice at building databases, so your idea initially strikes me as more complicated because, as I understand it, it is a relational database comprising at least four separate files upon which a master file draws.
However, if I understand correctly, it might prove to be simpler and easier to build in the long run because repeating information would be entered only once. For example, a file of composers (probably in your suggested People file) would be built once, then, for example, every time a track's composer was Beethoven, the composer field in the track record would display the composer name, referenced by the PeopleID, instead of having to type the name. This would also help ensure consistency in presenting information and reduce the chance for errors. Furthermore, changing or updating information in any of the related databases would instantly update that information in all related fields.
This is a very intriguing idea. Since I'm a novice, it still strikes me as a bit daunting -- but something tells me that, halfway through my project, I would be glad I had adopted your approach. I'm going to give it more thought. Thanks, again.
D H B wrote:
if I understand correctly
D H B wrote:
a file of composers (probably in your suggested People file)
It is a People file, because the same person can be the composer on one track and a conductor on another. BTW, depending on your intended use, the smallest unit here might be the role. If you ever want to produce a report such as:
• Symphony No. 1 Jeremiah
• Shostakovich Symphony No. 5
• Symphony No. 1 Jeremiah
you will need a table with two records for "Symphony No. 1 Jeremiah" - and that's where the Credits table comes in.
I am definitely NOT a super contributer
So I suppose I go for simplicity.
I would still go for a Data Base built around the track. The track record layout for entering the information would probably look a bit like iTunes information page. I am also thinking of the possibility that you may be into multitrack albums.
Later you can build simpler layouts - buttons that will shift you to layouts with specific sub-summaries, find and sort scripts. So theoretically at the touch of a button you can see the information you have in the way you want it.
You will always have at least or two Albums or discs with the same name but different composers or artists. So have a field for Album Code (its name is no good (duplicate names) so may be use its registered number) and a Field for the track number. This will allow you to sort on individual Albums (and tracks within the album).
Other sorts scripts will be on composer, song title, etc
Subsummaries mean you will only see the Album name once followed but a list of its tracks names etc . Or the composer's name once followed by the list of specific songs.
All the information for each track will be available if you wish (depends on the layout you design).
For each track you will need to add all the information. There are simple ways to do this such as (Mac) <Command "> or duplicate the record and change the unique data.
I just can't thank you enough!
I think your approach is right for me, at my level of using FileMaker Pro (a novice -- a paradox in using this product! Perhaps the company could introduce a version called FileMaker Nov[ice]?).
Also, since I'm a graphic designer, I need to SEE things to understand them, and your track-level record keeping is easy to SEE. I'm sorry to admit that the other poster's comments are hard for me to imagine, to see. Nonetheless, I have no doubt that his are not only valid and valuable insights but also worth serious attention for those more experienced than I. I wish I could join him in sharing an understanding of relational databases, but I cannot.
Again, MANY THANKS for your insightful advice. It's just what I needed to lauch forth on an exciting database-building adventure!
D H B
Once last idea getting Info from your iTunes:
First create the fields in Filemaker
You can copy the information from the iTunes list page. Arrange it across the itune page how you want first.
(On a Mac Click in first item hold shift and click in the last item) Copy
Then put it into say Word arrange it so each item is on a tab then save it as text file.
*You can by pass Word and import into Filemaker. If all fails delete and imported set and have another go.
Best to start with an empty Filemaker file.
All being well you can import that file into Filemaker making sure you line the info up correctly.
So at least you will/may have the song names and all the info as well! if not more.
You may need to look up "import" in the help me menu
D H B wrote:
the other poster's comments are hard for me to imagine, to see.
You should simply try it - it's not that complicated. As for visualisation: a page for each album, with the album's tracks listed in a portal, is much clearer than a mile-long list where you have to spot the change in the album's name column. Not to mention copy/pasting the album's name 20 times (and then again when you discover a typo). Seriously...
D H B wrote:
Perhaps the company could introduce a version called FileMaker Nov[ice]?).
They have something like that - it's called Bento (Mac only).
Dear Ms. Dumiya & Mr. Comment*:
Thank you both for so assiduously attending to my inquiry.
After rereading your posts and reassessing my skills -- remember, I worked in FileMaker Pro a few years ago when my version of the program, 6.0, was current -- I believe you BOTH have "the solution"; it all depends on what I'm able and willing to tackle.
- Dumiya, I know you know what I know, and from that I believe your solution is well founded: Immediately, I can do what you describe, and I would be happy to do so.
- Comment, I know you know what I don't (yet) know -- your use of the term "portal" threw me! And I checked the Help file, but, despite its verbal clarity, I just couldn't "see" it, as the 6.0 Help file provides no pictures -- but I think your approach would challenge my budding skills and ultimately produce a simpler, better database: Eventually, I could do what you describe, and I would be happy to do so.
Coincidentally, today's "Word a Day" (http://wordsmith.org/awad/index.html) is "Ockham's razor" -- the maxim that the simplest of explanations is more likely to be correct. Curiously, each of your proposals satisfies this maxim:
- Dumiya, yours is easier for me to implement immediately -- but it may be harder (more time consuming) over the long haul.
- Comment, yours is harder for me to implement immediately -- but it may prove easier (less time consuming) over the long haul.
It is a delicious dilemma! (Among those not uncommonly posed to and recognized by a sexagenarian, ever curious about the burgeoning world of digital data.)
So, what I have vowed to do is this: I'm going to review all my FMP6 electronic documentation, to refresh my memory of those functions Dumiya suggests and explore those Comment cites. (Indeed, in retrospect, I realize I probably should have done so before posting my query in this forum. Mea culpa!)
All in all, I can't thank you both enough for the generous time and kind effort you have expended on my behalf. I promise to share the results of my project, which I hope will please (and perhaps surprise) you both.
D H B
*Your honorifics are my best guess, based on the style of your writing; please excuse -- and correct -- any error.
Pardon me for being somewhat blunt:
I bought a car, but I don't know how to drive it. Someone told me I could insert the key into the ignition and have the car carry me and my stuff. I hope to do so eventually - but meanwhile I'll put my things in the trunk and push. This is good, because it is an immediate solution.
BTW, you can see a real portal in action, not a picture of, by opening the Companies10.fp5 sample file in your FileMaker Tutorial folder.