Submit a whole file-full of tunes into the database.
The basics of this are fairly self-explanatory - specify a file on your local machine, push the 'Upload' button, and the file is sent to this site, which picks through it and any ABC tunes it finds will appear in the tune listings under your name.
But there are situations in which picky little questions can arise, and confuse things. These are likely to be of more interest & relevance to experienced ABC users.
Record the file name
This is fairly straightforward. If requested (the default) the name of the file you uploaded will be kept for each tune stored, in a field called %%File. This can be a helpful reminder of where things come from. What is actually stored will depend on your system, or possibly on the browser. As I do it (Opera/Linux), all the site gets told is the bare filename. People doing the same thing from Microsoft systems seem to pass the whole thing in, complete with drive and path. The site doesn't get clever with this, it just records whatever it's told.
Accept tunes that originated here ?
It's possible that the file you're uploading could contain copies of tunes previously downloaded from here. These identify themselves by having a magic ID number included in the header. This can be handled in two different ways. By default any such duplicates will be treated as an unwanted accident, and rejected (they will turn up in the Postponed Tunes list for later review, and possible storage under a different ID number). Alternatively, if you choose to accept these, the new versions will overwrite whatever was previously stored under that ID (assuming it was one of your own tunes, of course; it's not possible for you to affect anything belonging to someone else. In this latter case it will, again, be bounced into the 'Postponed' list). You have to choose a single one of these options for all tunes. I could do an 'ask' option to allow decisions on a per-tune basis, but it really isn't a high priority at the moment.
This provides a convenient way to modify large amounts of data. I can think of two ways this might be useful (there may be more).
- I originally invented it for people like myself who sometimes just plain lose patience with "user-friendly" graphical front ends getting in their way. Many ABC users have their own favourite tools, and there can be times when the Right Thing To Do is to take hold of a bunch of tunes, do something to them, and feed the processed results back into here.
- It also provides a do-it-yourself 'undo' function (which, NB, doesn't otherwise exist). Download a list of your tunes as ABC, keep them handy somewhere on your local machine, and you can undo any subsequent changes by re-uploading it.
Keeping tunes private
Add an extra line, %%Private: (it doesn't need a value), into the tune's header to indicate that it should be kept private. See here for a discussion of the ID and Private fields.
Default header values
The ABC file format allows for the possibility of writing "header lines" outside a tune, to supply default values. This can save a lot of typing; it can also cause some unexpected effects (if your upload file here is a bunch of local files concatenated together, did you remember to turn any outstanding values off at the end of that file ? No, I often don't either). If you write your files in this style you'll probably know about it, and know when it's appropriate to tick the 'Yes' box to have it happen. This is implemented in a much more liberal style than Chris' original description - it'll accept any key:value line that would be valid inside a tune header, except for X: T: K:.
Upload Behaviour
The processing of an uploaded file is slower than I'd like. This isn't too noticeable with files containing a few, or maybe a few dozen, tunes but beyond that it becomes a nuisance; particularly when a continued lack of response from the server leads to browser time-outs, and so on. So I've had it break the processing into chunks, sending a 'progress report' page to show how far it's got, with a 'Refresh' header that tells the browser it's instantly out-of-date and thus causes it to request the next chunk. Which is kind of neat, and nicely reassuring, but has one result that you may not expect - if you click any other links while it's processing, it'll go there instead of doing any more chunks; the processing of uploaded tunes into the database will hang, unless / until you return to that screen. In other words, you have to let it finish, on screen. If you go to the Tunes Front Page in the middle of an upload, you'll see an extra button telling you about it, and offering to restart the processing. Of course, you can carry on doing other things from a separate browser window, so it doesn't have to hold you up (in which case you'll still see that button on the Tunes Front Page. I suggest you try and ignore it). I doubt this will be very relevant to very many people. It was important to me in the early days of development, because I was testing it with a file containing upwards of 4,000 tunes; and it was gruesome. I wouldn't think there'd be many people likely to do it on this scale. (But, if you want to, of course, by all means go ahead; it ought to cope. Complain if it doesn't.)
See Also
- Guidelines for Submissions
- ABC on this site, particularly the bit about pseudo-headers.