[no subject]

The database reflects your collection, not a hypothetical one. It has no 
relation to the complete body of existing recordings (however, see below).

The database I wish to produce is a tool that will enable a user to enter 
the details -- and all the details -- of his/her collection of recorded 
sound, no matter what range of media that collection is on and no matter 
what form it takes. It will also enable the user to sort the database 
records according to just about any criteria, and to search/find records 
meeting a large range of criteria. (NB: by 'record' I mean the data 
forming a computing entity, not the disc you play on a record-player.)

I can see (at least) two typical users of the database: 

(a) the keen collector with thousands of CDs, LPs, tapes, 78s, etc 
scattered about his or her study or house and with an incomplete idea of 
what is owned and where it is kept; and 

(b) a non-commercial radio station that broadcasts classical music, 
relying on subscriptions for support. Such a station might not have the 
money to commission a database costing tens of thousands of dollars, so 
they might be looking for the database I intend producing. Such a station 
would also have a collection of several thousand CDs, LPs, etc.

Both types of user might wish to know something like the following (and 
by 'know' I mean be able to bring up on the screen or print out):

What piano works have I/we got by Beethoven written between 1810 and 1820 
in the key of E-flat major, recorded by Gould between 1967 and 1970 and 
lasting between 3 minutes 10 seconds and 3 minutes 20 seconds?

I'm sure f-minor listers can think up many similar queries. In a 
prototype database that I designed in 1995 I found it interesting to list 
all the versions I possessed of, say, a Beethoven sonata movement and 
compare the times. Is Gilels really slower than Barenboim, or does it 
just sound that way? Just how much quicker than everyone else's is GG's 
version of the first movement of the Moonlight? Of course, you could 
always dig out the CDs in question (if you could find them) and check 
such information manually, but a database makes it all much easier (once 
you've entered the information).

Physically finding your CDs, tapes, etc can be a problem. An advantage of 
a database is that you can give every item a unique number, which you 
stick onto the case or cover, and then simply store items in numerical 
order. You have to look up an item in the database if you want to find 
it, but once you have established its number you can go straight to it. 
However, if the database or your computer breaks down you're in a hell of 
a mess because items are not stored logically. In that case, some users 
might like to give items unique numbers only within a shelf or case 
('Shelf 1 is all Beethoven', or 'Shelf 1 is all symphonies').

It would also be possible to allow the user to record the first 15 
seconds of a movement and save it in the database. Pressing a button 
on-screen would replay that sound bite. Sound takes up a lot of room, 
however, so not everybody would be interested in that facility. It would 
also be possible to scan liner notes and similar info into the database 
provided one had a scanner and an OCR program. But these facilities are 
refinements and probably not essential to a first version -- or are they? 
Please let me know.

For the hypothetical radio station (or the _really_ keen collector who 
wished to listen to his/her collection in strict rotation, or in random 
sequence, or without playing the same recording twice in a month), the 
database could be expanded to include (a) a means of recording the last 
three occasions [date and time] on which a particular piece (ie, a 
movement or aria or whatever) was played, and (b) a means of planning the 
future playing of pieces. I'm sure that refinement is not necessary for 
most collectors, but who knows? Please let me know.

A database is no good if it makes the user work or think. That means that 
after the first time you enter the full details of the 'Eroica' (key, 
movement names, composer, date written, etc) those details should be 
immediately available for the next time you buy a version of that 
symphony. Similarly, you enter the details of JSBach once and once only, 
then simply 'pick' his name to 'attach' it to every piece of his owned by 
you. Ditto performers.



As to the computer details, a 4D database comes in 3 parts: 

*** the 4D program itself (which I shall refer to as the 'engine'), 
*** a structure file, and 
*** a data file. 

For this database, ACI/ACIUS provide the 4D engine, I will produce the 
structure file, and you -- the user -- will create and fill the data 
file. You need all three files to work the database. If one is missing, 
the database will not work.

The 4D program itself is -- in developer terms -- an application. The 
latest version is v6, due out at the end of January 1997. It comes in two 
flavours: standalone, and multiuser (client/server); I'll look only at 
the standalone program as I don't think many people will be interested in 
the multiuser program. Please let me know if you disagree.

One can use the 4D engine in two modes, called design and runtime. When I 
am producing the structure file I will use the 4D engine in design mode; 
when you are testing or using the database (which means creating, filling 
and fiddling with the data file), you will use the 4D engine in runtime 
mode.

The structure file contains details of the layouts (screens) and all 
their paraphernalia such as buttons, drop-down menus, standard menus, 
etc. It also contains all the procedures and scripts (the programming) 
that govern the program. For example, whenever you click on an object 
(eg, a button) in a window, the program springs into life to see what you 
have done. It then performs one or more activities according to what I 
have told it to do in the script that I attached to that button. Menus 
and buttons allow you to manipulate data, delete it, sort it, search for 
it, etc.

The data file contains the information about the recordings you own. You 
can enter the data using the layouts (screens) created and saved in the 
structure file. As you add data, the file expands.

Because not everybody will have his or her own copy of 4D (it's quite 
pricey, about US$1,000), developers (that's me in this case) can 'merge' 
a cutdown runtime version of 4D with the structure file. The cutdown 
runtime version is full-strength except that there is no design mode. The 
combined runtime/structure file can be given its own icon so that it 
looks like an application, which is what it is. In that case, you need 
only two files to work the database: the combined file and the data file. 
When you receive the beta version of the combined file it may have no 
data file with it. When you double-click the combined file to launch it, 
it will ask you to let it create a data file. You have to say yes. From 
then on the combined file will remember what and where the data file is. 

You can create more than one data file but there's little point in doing 
that. 4D, or any combined file as described above, can open only one data 
file at a time. You must therefore keep all the data you wish to keep in 
one data file if you want to get maximum benefit from the database.

Some people have asked about ANSI and formatting. 4D databases store 
their data in a proprietary format. When you are adding data, the 4D 
engine decides when it is time to expand the data file; it also decides 
where within the data file it will keep your data. You can look into a 4D 
data file using any text editor but you will be disappointed. The data 
will look like a dog's dinner. You will recognise lots of words and 
numbers but they will bear no relation to each other. The engine may 
decide to store a person's name at the beginning of the data file but 
that person's address at the end, even though you may have entered the 
two data items one after the other; there could be 10MB of data in 
between the name and the address.

This has two effects. 

The first is that no other database program (engine) can read 4D data 
files. (In fact, the structure file and the data file of a 4D database 
must be compatible too. You cannot open a 4D data file using a structure 
file created for another purpose.)

The second is that, when one is designing a database, one must know at a 
very early stage exactly what will be required from the database. It is 
generally inadvisable -- and often impossible -- to start with a 
half-formed plan and then change course. Ideally, the developer should 
know every detail of the database specification before starting work. 
That is one reason I asked what f-minor members wanted from this 
database, what they considered essential, etc. The initial database 
should include not only the right stuff but also *all* the right stuff.

If you do change the design of the database after you have started using 
it, you have to create a new data file, then export all the data from the 
old data file to a text file on disk, and then import that text file into 
the new data file. And you cannot export all data in one go. You have to 
do it table by table. I would hate for beta testers to enter reams of 
their own data and then have to go through the export/import caper when 
the final version of the database appeared because I had had to change 
the structure considerably from the beta version.

Some people have asked about SQL. There is a 4D add-on that enables 4D to 
act as the front end of an SQL database (eg, Oracle) but 4D is not an SQL 
database as such. In any case, there are several flavours of SQL, just as 
there are of UNIX, so even if 4D were an SQL database there is no 
guarantee that it would be compatible with other SQL databases.

4D has an excellent search engine that enables the user to search on more 
than one field using AND and OR statements. However, many developers like 
to hide the search engine behind a custom layout that prevents the user 
asking for impossible searches. In this way a canny developer can imitate 
SQL quite well. 4D's sorting capabilities are equally good.

Some people have asked about such things as matrix numbers, sessions and 
takes, publication sources, editions used, etc. This is exactly the sort 
of info I was looking for. Because of my lack of musical and recording 
knowledge I have asked those people individually to let me have some more 
detail. If anyone else wants to add more detail, please do so.

Although this database is not a discography I think it might contain 
fields allowing the user to record data about recordings he or she might 
want to buy...possibly also recordings that the user has borrowed from or 
lent to others.

Some people have asked about blank fields that the user can define. This 
is a possibility but not a strong one. Blank fields lead to bugs and 
errors. Sorry. I would have to attach each blank field to a table, and as 
the database is going to have many tables, in order to satisfy all users 
I would have to include blank fields all over the place. That would lead 
to bloat (you don't have to have anything in a field for it to take up 
room on your disk). From my point of view it's better to define as many 
fields as possible at the outset and perhaps include additional fields in 
version 2.0 if people ask for them.

Some people have suggested having two versions of the database: a Full 
version and  Lite version. After all, not everybody will want to record 
matrix numbers and other more esoteric info. That's a good idea in 
principle but effectively means producing two different databases. I 
think what I may do is produce the Full version but allow users to hide 
some bits they don't want to see. If the Full version takes off and 
people actually start buying and using it, I think that is the time to 
start thinking about a Lite version. Any comments?

I think I'm going to use the name Opus Two (thanks, Bradley Lehman) on 
the basis of the GG quote: 'It's Opus Two that counts' (when discussing 
his Op. 1 string quartet).  However, this is still a work-in-progress 
name...for the time being. Many thanks for the other suggestions.

The beta version, which won't be ready until mid-1997, should be less 
than 2MB. If it is, I shall compress it and include it as an attachment 
to the email messages I shall send to you beta testers. If is isn't, I'll 
probably have to post it to you.

I'm sure there's more that could be said but I think that's enough for 
the time being.

Thanks for your patience and time. Please let me know if you have any 
further suggestions.


Tim Conway
<tpconway@ozemail.com.au>