VMP Transcribers Hints

Some notes on transcribing MSS for the Village Music Project. Chris Partington 30/12/18

Some of these hints are to produce *correct* ABC files to the current official standard. Others are local to VMP, not because your way is wrong, but to produce consistent files within the project, and because it's easier to take in a tune at a glance when checking them if it has familiar characteristics to me (I have to do it a lot).

Please take time to read them.

Viewing The Manuscript

I usually send the images of the MS to you as a PDF, in which case it's up to you what you read it with. I am lucky enough to be able to project the PDF onto my TV, and work on the transcribing on the laptop. This means I don't have to keep switching between programs on the laptop.
Where I am working off images that are within a webpage, as the Buttrey MS was, then I use the Chrome browser. This has the facility to allow you to open an image as a full screen new tab. Most browsers don't seem to offer this.

Choice of ABC Editing Program

It's up to you. I use ABCexplorer, many use EasyABC. Others are available.

The Headers

As long as the headers start with X, followed by T, and K comes immediately before the tune body, I don't mind what order the header fields are in, since I don't know what editing software restraints you are working under. I tend to do it in the order that ABCexplorer prefers, followed by what I can remember of my past practice, which usually goes something like XTMLQRCNWSBK. However, if adding a *new* field with Explorer (for instance) it sticks it immediately after the title; when added in Word it goes where ever you prefer. So you see it all ends up a bit random anyway. I know that this may be a problem for turning a file into a database, but I figure that anybody who was going to do that would also be able to figure out a thingy to rearrange the headers to suit.

Required Fields in a VMP Header.

X: The tunes, including fragments, need to end up in the file in exactly the order they appear in the MS

T:Title(s)
The VMP Number (i.e. unique identifier, below) is suffixed to the T:tune title. This can usually be left to me unless the MS is itself clearly numbered. This number positively identifies the tune in an index which may contain many versions of the same tune. Don't bother with page numbers, they don't provide any useful extra information.

As a result, our format for tune titles is as follows, e.g. from the John Buttrey MS (assumes this example is the second tune in a manuscript with more than 100 and less than 1000 tunes)
....where the first title is the main one, spelt as in the MS but always with the definitive and indefinite articles ("The" & "A") removed to the end after a comma and a space. This is for rational alphabetical indexing.
Followed by a full stop and a single space. This makes it easier on the eye when scanning a list.
Followed by the VMP identifier for the collection, in this case JBut. (Followed by a full stop)
Followed by the item's position in the MS, and again for indexing if there are more than 10 items the first tune is 01, if there are more than 100 items, the first tune is 001 and so on.
The second title may be another title as given in the MS, or another title the tune may be known by to yourself, in which case it is "also known as", = ,aka. and the identifier, etc for as many titles as you can find. This makes it easy for cross referencing tunes in big indexes.

Fictitious Examples:-
T:Scotch Laddie. JBut.002, The   -a comma followed by a space followed by a definite article allows for indexing but still prints the definitive article correctly with the title
T:Whiskey Laddie. JBut.002     -alternative title if one is given in MS. JBut.002
T:Whiskey Lady,aka. JBut.002    -Alternative title if known but not given in ms,aka (also known as!). …%see below
T:and another,aka. JBut.002

B: This is the name and description of the manuscript or book that we are transcribing. It will end up in every tune when it goes VMP. It is easier left out from the early stages and batch inserted into the whole file at one hit by me at the very end of the process. In other words, you can leave this one to me.

M: As shown in ms, but I may "correct" if really needed, as in 6/4 when it should be 3/2. Do not change C to 4/4, or C| to 2/2.

L: Because some programs calculate the default note length according to the meter M: that you have faithfully copied from the MS, it is essential that you have specified a default L: field in every tune, to avoid bizarre printout behaviour (this was most noticeable in ABC2win). So in a MS where all the notes are crotchets for example, you can specify 1/4 (crotchets) and mark the L: as L:1/4, and it will be correct whatever abc2win or abcm2ps thinks it ought to be. On this subject "/" is shorthand for "/2" and is easier to read and to write. If you leave them as /2, I will only have to find and replace them with /

Q: Specify a speed, it only has to be something listenable, not necessarily historically correct. If you don't specify then midi makes one up and it's usually really wrong. I have to do it if you don't.
The form I use is whatever would sound useful on a metronome or toe-tapping,
i.e. for a waltz, one click per bar - Q:3/4=40 (or whatever), reel Q:1/2=100 (and not Q:1/8=400, or Q:1/4=200, which produces the right speed in midi but an impossible one on the metronome or foot) etc..6/8 is generally between Q:3/8=100or120, dotted hornpipes ca 84 bpm, plain hornpipes 100 bpm, slow march 60 bpm, quick march 104 bpm

Z: This is to indicate who is responsible for the ABC transcription and when. In the same way as B: will usually be batch entered into your file in one hit. The usual format is (say) Z:VMP.Joe Bloggs.2011.

K: “Can” be the major key that produces the correct number of sharps and flats, but I now prefer to <try> and work out what mode etc. This should always be the last header field before the tune body. There are some cases where a header is permitted during a tune, say to indicate a change of key or meter.

Those are the only fields that I must have in a submitted tune. In addition here are some optional fields which you may find necessary or desirable.

Extra Headers

R: Describes the type of tune, makes it easier to pull out all the reels or hornpipes etc when filtering. I have more recently actively avoided using the R: field altogether - unless the type is specified in the manuscript. I always tried to put one in in the past, as it's easier to gather statistics with one in, but it's very subjective and I frequently made pointless mistakes here!
Also, abc2midi, the common midi player program, has been told by its author to interpret ALL hornpipes as dotted whether written so or not, so you have to prefix it with a ‘stop’ to circumvent that. i.e. as in R:.Hornpipe.

C: Where a composer is known, whether it is given in the MS or not.
Also (naughty) this is used where there is a comment in the MS. e.g. it may say 'Irish' or 'great tune' or whatever. In this case put it within single quotes.
You can have more than one C: in a tune if you need to.

S:This can be used to indicate where the source is stored on the internet, and therefore where we copied it from. It is volatile as URLs can change, so I never use it, but you can if you wish.

N: If you know any interesting anecdotes, here's the place for them. Also the place for NB’d comments

W: - optional as to whether you want to add the dance notation. It needs to be before the K: field as we have encountered occasional problems when it is typed after the tune body. It still displays and prints after the tune though.
Lines of text have to be broken up onto separate lines by more W:s or they disappear.

V:Some tunes are multi-voiced, but I won't deal with that here.

Tune Body

Try and keep to four bars per line of music code, and consequently notation. They are easier to transcribe, navigate and edit like that. They also are easier to play for end users.
Also longer lines are often broken up by email programs and the like, leading to incoherent files. Email programs don’t like lines longer than 72 characters.
Vertical space is not at a premium on the internet and it's easier to edit lines of code if they don’t disappear off the side of the screen.
But that's only a rule of thumb.

I am in the habit of breaking bars into beats with a single space between the beats at the half bar. It may not be necessary but it helps visually with transcription and editing. I don't use single spaces around barlines but you can if you wish or if your program or your eyesight demands it. I must admit that as mine deteriorates I begin to see their virtue. I will reduce multiple spaces to single spaces if I find them.

The new (as of Dec.2011) ABC 2.1 Standard deprecates the use of exclamation marks as indicators of forced notation line breaks, preferring simple <EOL> (carriage return etc), so VMP files will adhere to that. The use of \backslash will continue to indicate that the notation line should not break even though the code line has.

Decorations, dynamics and grace notes are to be included. Whether squiggles are read as "tr", "^tr", T, ~, !trill! is a matter of taste and judgement, depending on how they appear in the ms. Decorations in future will use the !trill! form rather than +trill+, again to comply with current ABC 2.1 standard.

Repeat marks at the beginning of a tune are conventionally missed out and therefore usually considered optional. The exception is in multi-voiced tunes, which ABC2midi won’t play correctly if the initial repeat marks are missing.
Repeat marks within a tune, between parts A and B for instance, are the cause of some problems. Many authors are very cavalier with them, so we must do our best to regularise them. Pickup notes should normally be included within the repeats and the final notes of the section altered to suit ( and NB'd to show what was done). Try to avoid 1st & 2nd repeat bars where possible unless they are in the MS. Ingenuity may be required.
Different notation programs are apt to treat the different ways of indicating repeats their own way, (e.g. ::, or :||: within a line) and you may have to tweak a tune to display it correctly in your chosen program.

It was common and accepted practice at one time to use the Fermata symbol to indicate the end of a tune, instead of FINE. We replace it without comment with !fine!. Of course Fermata is also used where obviously intended.

"Bis" above a bar is a shorthand way of saying "play bar again", so we notate it again, which we can do without comment.

Tunes need to finish with a Thin/Thick line arrangement. To achieve this with repeat marks :| is correct, :|| or :|] doesn't work. Oddly, by historical accident presumably, where there are no repeat marks you must use |]

Example

Spend some time checking the accuracy of your transcription before submitting the file to me please. The most frequent errors are notes in the wrong octave, notes of wrong length or missing, and bars entirely missing or entered twice.

If you have any questions don't hesitate to ask, either directly to me, the Melnet working page, or to the VMP Transcriber's Facebook Group.

Back to Bits & Bobs

Back to Homepage