Anyone know this jig?

Anyone know this jig?

The double jig is called Jim Conroy’s jig on the Branch Line CD by Jack & Charlie Coen. Jim (and John) Conroy were East Galway flute payers who gave Jack Coen many of his tunes. I picked out this interesting Jig in G major (it is in a set with Lilting Banshee). Does anyone know it, remember hearing it somewhere, or even play it?

I posted both the CD (The Branch Line) and Jim Conroy’s, but haven’t gotten many comments. Take a look and let me know.

thanks

Re: Anyone know this jig?

Sorry, Bloomfield. I went and had a listen and it doesn’t sound even vaguely familiar. Cool tune though!

Re: Anyone know this jig?

Isn’t it fun, though? Got blank stares at the session… oh, well. Maybe they play it in Montana?

Re: Anyone know this jig?

Heh, Bloomfield, we didn’t, but now that you’ve shared it with us, we do now!

Jim Conroy’s is a nifty little jig, and does vaguely remind me of some other tune, but I can’t place it. And it’s certainly different enough from whatever it reminds me of to be a distinct new tune, i.e., one that I didn’t know before.

So thanks, but sorry I can’t help with the tune’s etymology…..

Posted .

Re: Anyone know this jig?

Will,

I haven’t been able to track down "Jim Conroy’s" but the sequence of notes in the opening bar occurs in the tunes Old Hag You Hve Killed Me, The Killimer, and Humours Of Whiskey, which is probably why it is vaguely familiar.

And how did I find this? Over the months I’ve been downloading lots of abc files onto my pc - Norbeck’s collection, the O’Neill corpus, etc etc, and a few days ago I combined them into a single text file using Word. The file is big, over 3MB with about 8000 randomly-ordered entries, many of which are duplicates or near-duplicates, and I’m adding to it daily. But duplicates don’t matter for searching purposes using Word’s "Find" command, and if I find an exact duplicate I can always strip it out. I have to be precise using Find because it doesn’t use fuzzy logic. The biggest nuisances are the chord symbols - "Em" etc - so I’ve stripped them all out using Find and Replace. The file looks like being a useful searching tool, and this is the first time I’ve used it in earnest.

Omg, I’ve just realised. By revealing this I’ve probably made a stick to beat myself with! But if I can do it, so can others …

trevor

Re: Anyone know this jig?

Trevor, what a brilliant idea. Of course, now whenever the rest of us have a tune fragment we need to flesh out, we know who to call…. 🙂

It would be interesting to eventually group your list of tunes into their "families"—collating by tune type (jig, reel, hornpipe, etc.) and similarity of phrases.

Posted .

Re: Anyone know this jig?

I wonder if there isn’t a way to import such a file into Excel or similar program and then use the "sort" command to group things together. Maybe it would require too much keyboarding.

Re: Anyone know this jig?

One cell containing the title, one containing the first 3 or 4 notes, and the third cell containing the whole tune, and perhaps a cell or two for information like tune type or key — that wouldn’t be too difficult on a spread sheet program.

Re: Anyone know this jig?

I printed that jig and started to play it. It sounded familiar and as if I’d heard it very recently. I had. This morning I was playing along with my ol buddy Eddie Meehan. Well, actually, I was playing along with his LP. I skipped over that tune though and went to The Boys of the Town because I knew Boys but not Jim. I’m glad to have it.

Steve

Re: Anyone know this jig? - database construction

I’ve had a think about the question of importing my file of abc tunes into Excel, or a database application such as Access. Leaving aside the logistical problems of keyboarding a vast amount of stuff, the basic trouble is that the data we have is messy. It’s not at all like keeping a spreadsheet record of CD titles or a book library where the data is clean and can be organised with precision. A good useful database of tunes is going to be difficult, and expensive, to construct and maintain.

A few of the messy problems that come to mind:
1) As Jeremy once said, a single tune may have 20 names; a single name may be given to 20 tunes. That’s only a very slight exaggeration of the truth.
2) Almost any tune you care to name comes in as many versions as there are tune-books or players. Which one do you select for a database? Or do you put in all you can find?
3) What is the key/mode of a particular tune? That’s not always obvious either, as previous threads have pointed out.
4) Some tunes turn up in various keys, sometimes in G, sometimes in A, etc., so this will immediately cause problems for a tune fragment search.
5) Many different tunes start off with the same one or two bars.
6) The presence of chord characters (e.g. "Em", "F#m") in a tune will falsify an abc character search for tune fragments, and will have to stripped. This isn’t too difficult if you can identify them all, but I’ve noticed that some tunes have something like "G/D drone" embedded in the abc. Such embeddings are awkward to spot by find-and-replace techniques, and are best dealt with manually, which is time-consuming.
7) Double stops, which are usually optional (but not always - see "Ronfleuse Gobeil" which I posted recently), can cause the same problems as in 6).
8) Ornaments such as "~" and "{a}" will similarly cause searching problems, as in 6).
9) Transcriptions are not always consistent. For instance, "A3B" can appear "A>B", and "cdef" can appear with a space as "cd ef".
Some transcriptions can show the dotted notes in a hornpipe, many others don’t. All these will mess up a character search.
10) Classification of tunes. There can sometimes be problems in this area. Is a tune a hornpipe or a reel? And what are we to make of a tune in 2/4 time containing only quarter and eighth notes? Jeremy must recognise the problem, which is probably the reason he takes a formalised approach based on the time signature. And we all know that slow airs have to be disguised as waltzes or strathspeys for the purposes of The Session’s database!

I have no doubt that other problems would arise as soon as you start analysing the data in greater detail.

So this is why, for the time being at least, I think I shall have to stick with my Word file and amend it and simplify it on an ad hoc basis as I use it.

trevor

Re: Anyone know this jig?—Problems managing tunes in a database.

Trevor, Now you’ve got me interested in the latest database software. I haven’t had to deal with database problems this detailed since I had one foot in DOS and the other in Windows. I used dBase III and database programming back then because it had extensive capabilities that basic spreadsheet softwares didn’t. Can anyone out there tell us what softwares allow detailed search strings and programming these days? I don’t mean the basic ones, but ones that let you write detailed search strings and let you relate databases. I really like this idea for managing my tune collection. Since I’m just beginning, I don’t have the problem of transferring a massive database over to a new format and solving the problems below. I can address many things as I add songs and at least improve on some of these. Even with these problems, I love the database idea. Designing a database has to be weeeeeeeeell thought out…you did a great job of identifying some problem areas. Now to put on my thinking cap…I’m sure once I start trying to do this, I’ll run into others, but if it were me, this is how I’d handle what you’ve pointed out to us so far.

Some of these problems can be addressed in a database sort if you sort on more than one field. You can either sort the entire database based on what you’re looking for (and wait for the time it takes to resort the whole thing) and scroll the resulting biiiiiiiiiiiiiiiiig list…or you can use your find feature to pull the ones you want out and sort only those. Save the list you get, print it, or use it once and dump it, but keep your main database intact. I always save a backup of the original in case the thing gets really messed up by a bad sort and an accidental overwrite or a hiccup by the computer ( or the computer operator). Given the size of your data, it is of course easier to use it all as a text file, but if you could transfer it over the a database, you’d have to find database software that handles a database of that size and you’d have so many more sorting options. Transferring it would be a monumental task given you’d probably not be able to import the data, but have to cut and paste, but it’s do-able in this lifetime if you have a fast computer that can handle big chunks of data at a time.

Now, if I were in your shoes, this is how I’d handle the things you’ve pointed out (I’m sure someone else can improve upon this, but being me, this is what I’d do):

Once you have this in database form:

1) Find all tunes by the name you want and use the opening bars column as the sorting field. So you’d get a bunch of "Kesh" sorted by the opening bars…alphabetical, ascending or descending. Tunes which open with an odd character ( indicating chord characters for instance) would land in their own batch in the list, again alphabetically, ascending or descending.

2) I’d put the versions in that you find useful at all. Again, you find all by the tune name. Then sort by whatever you choose…opening bars, key signature, etc.

3) That presents a problem. You’d have to decide what guidelines you’ll follow for establishing the keys in your database, and realize that even then, some will fall outside the realm of your stipulations. You might fall back on an additional field that uses the musical interval pattern instead of the actual notes.

4) If you don’t have the name to sort with, you’d have to accept that sorting by frags will miss some of them (probably many more if you have embellishments and variations). You’d have to sort on the name if you had it. There would have to be a separate field of the music using a different notation method which indicated the musical intervals instead of letter notes for frags to work better. Even then, variations would mess you up, but you’d have a chance of finding that frag…a chance you wouldn’t have without it. If you were using the right kind of database software and you could write specific search strings, you could write "IF Field A=ABC OR Field A=~ABC OR Field A=abc OR Field A=~abc, return the result to X"(where you want the results to list). You’d write those variations and embellishments that are most possibly used, and you’d find most of the frags.

5) You’d have to indicate a second sort field to narrow the sort down. Sort first on the bars, then on the name for instance. If you break the tunes down by creating a field for each measure, you could narrow the search down even more. Of course, this would have to be done before you had a huge database to deal with…in the beginning so that as you add your tunes, you could enter them this way.

6, 7, 8) I agree…you’d have to strip the chords…a royal pain. Embellishments are nice to have. Perhaps keep them in case you want to sort by that opening embellishment or chord, but add a stripped down version of your tunes as you add them to the database.

9) I used to do sorts using dBase III maaaaaaaaaaaaany years ago to handle this sort of thing. I’m sure there are ways to address this today and that someone else knows what database programs have this ability. The sort was worded using symbols which indicated "If field A is A3B OR A>B OR (any other way it could be written to indicate the same notes), return the result to (the address of where I wanted the items to appear)". This is easy if you have the right software and if you are dealing with something which has limited variations to be listed.

10) Big problem area. The only thing I can think of is to use the classification which has meaning to you and realize you’ll miss out on some when you search based on classification. However, combined with a second, even a third sorting field, this can be helped somewhat. Using software as I’ve described for 9), you can write very specific search strings to weed things down. "IF field A=reel AND field B=2/4, return the results to X" You’ll still miss some, but you’ll get better results.

I loved database programming back then…it was so cool! I don’t remember exactly how the strings were written, but they "said" what I’ve described. I’m sure those types of programs have rrrrrrrrrreally got capabilities now. What’s available along these lines now? This falls outside of what basic integrated database programs can do, doesn’t it? I haven’t had to attempt anything more involved than address labels; so, I don’t know if the basic database programs are as powerful as the powerful ones from years back used to be. (I think I understand what I just wrote in that last sentence…?)