Re: [abcusers] accidentals in ()
John Henckel wrote: In abcm2ps there is a bug. If an accidental is used several times in the same measure, it draws all of them. Thus, K:F and " =B =B " will print two notes with naturals in front of them, but only the FIRST one should have a natural sign. I am going to fix jhabc2ps so that only the first occurrance of an accidental is printed in each measure. I recommend that all other ABC rendering programs should do likewise. This is a really bad idea. Such "advisory" accidentals are often there for a good reason. Suppressing them means that you're using cpu time to make the music less readable. Nobody will thank you for this. I wouldn't even consider using software that damages my music in such a fashion. Also, by doing this, you are explicitly excluding both the Early Music and Modern Music crowds from the set of ABC users. Both of these crowds often use the convention that accidentals apply to only the one note. They have good reason for this. Discarding their explicitly-coded accidentals will mean that they can't use your software. It should be noted that, for music formatters, the question of the scope of accidentals is irrelevant. It only matters when you're playing the music. Music formatters don't play the notes, they just produce staff notation. They don't need to know anything at all about a note's pitch, only how to represent it on a page. So a music formatter like abc2ps has no business trying to second-guess the transcriber. It should simply display accidentals as shown in the ABC, and not try to "improve" on them. Notation for parenthesized accidentals is a good idea. We've had a number of suggestions that (^)A or (=)B be legal. This is probably the most intuitive solution, and doesn't seem to conflict with the use of parens for slurs. There was a suggestion that ?^A be used, but I don't think there was any reaction to this. I have wondered whether this should be discussed again. There are a number of places where parens are used like this in printed music. The one case where parens won't work in ABC is for optional slurs. Writing something like (()ab cd) is probably not a good idea. It's confusing and tricky to parse. The notation ?(ab cd) would be a better way of saying that the slur is optional. Programs could interpret this as is appropriate. A formatter could generate little parens around the slur. A player could randomly choose whether to honor the slur. In most other cases that I can think of, parens in ABC would work. An optional chord can be written as "(Em)", for instance, and everyone will know what is meant. Similarly, (.)G and (H)G are obvious and intuitive, and easy to parse. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multiple bars of rest
Eric Galluzzo writes:
| [EMAIL PROTECTED] wrote:
| ... The !...! notation might be better here, since
| that seems to be what people like for official musical directives
| such as !crescendo! and !da Capo! and so on. These are all special
| cases. in this case, !23!z could be recognized as meaning "23 bars of
| rest", and a length on the z would be unnecessary. Similarly, it's
| common in standard staff notation to use a whole rest in such
| measures regardless of the actual time signature.
|
| Hmmm. I don't know if I'd go for this. Firstly, we already have !0! through !5! for
| fingering symbols, so we wouldn't be able to do !4!z (for example); and secondly,
|this is
| a "real" notation that takes up time, not an annotation, which is what !...! notation
| seems to have been introduced for.
So where's the conflict? The use of !3! for fingering only makes
sense before a note, since there aren't any instruments (that I know
of) on which one "fingers" a rest. So !23!z means "23 of something
relevant to rests", and the only common use of numbers with rests is
for multi-bar rests. We would probably want the restriction that this
notation is only valid if the z is the only thing in the measure.
We should perhaps note that at least some programs right now will let
you use "17"z8 or "^17"z8 and will produce the right thing on paper.
The main reason you'd want to write this as !17!z is so that it will
be parsed as an officially-recognized abc construct, and not just
random text. But we don't *need* this; we can manage with quoted
text if nobody implements the !17!z notation.
I've also wondered if we could use a similar notation for the large %
that is commonly used to mean "repeat the previous chunk". This often
has a number that indicates how many measures to repeat. So !3!%
would produce a measure with a giant % superposed and a large 3
above, meaning to repeat the previous three measures. I'd bet that
lots of musicians would consider this notation "obvious", once the !!
syntax is widespread.
| Actually, there's already !f! and !pp! and such things in the draft standard, and
|James
| has implemented them in abc2midi. In fact, he's the one who originated them. :)
|These
| are not just random text; rather, they are well-defined (okay, somewhat-well-defined)
| musical instructions and hence go in !...! and not "...". I think the idea is that
|text
| in double quotes is just unparsed text, whereas text in exclamation points is an
| instruction to the ABC program.
Indeed. This might help standardize musical terminology even more. I
like to show people a couple of Bulgarian tune books in my
collection. They have tempo indications such as "kato rachenica"
("like a rachenica"). This is, of course, totally self-explanatory to
any Balkan musician. But I suspect it might not be so clear to many
other people on the planet, or to a Bulgarian musician 300 years from
now. A metronome marking just might be useful here.
(Now if I could just get a metronome that does Balkan rhythms. ;-)
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multiple bars of rest
Henning Kiel [EMAIL PROTECTED] ecrivit: | On Tue, 14 Nov 2000 [EMAIL PROTECTED] wrote: | | "^20"z8 | or | !17!z8 | | | But a midiplayer would of course not wait 17 bars... Well, if it were combining multiple voices, I'd hope it would. But when playing just the one part, it could be rather boring. I wonder what MIDI users would like in this case? | And if I write music with multiple voices the voices aren't any | longer aligned... Yeah; it looks like a formatter would need to understand the notation in this case. In the few cases where I've done multi-voice abc, I've wanted the explicit empty bars in the abc to preserve alignment, but it easy to see how someone might not like this. | So I was just talking about a feature of displaying tools, not a real | feature of ABC. | For a quick hack, for me the "^17"z8 would work, but not if I would | extract my clarinet part from a whole partitur. The traditional staff notation also qualifies as a "hack" in this case, but it's a very useful one, at least for saving trees. I'd like to see this sort of thing included in the list of abc annotations on some approved list. The !...! notation might be better here, since that seems to be what people like for official musical directives such as !crescendo! and !da Capo! and so on. These are all special cases. in this case, !23!z could be recognized as meaning "23 bars of rest", and a length on the z would be unnecessary. Similarly, it's common in standard staff notation to use a whole rest in such measures regardless of the actual time signature. | I don't know how other programs than abcm2ps handle !f! symbols | (abc2ps doesn't), but abcm2ps prints the symbols above the music line, | but I would like to have it below... | Do we need a %%symbolsbelow tag here? The favored notation seems to be "_text", where the '_' indicates that this is annotation that is to go below the staff. One of the things on my to-do list for my doctored abc2ps is to figure out how to get the text positioned correctly below the staff. I don't yet know enough postscript to get this right. Getting things printed so they don't overlap in an unreadable fashion is a bit tricky ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: SourceForge development environment questions (was: Re: [abcusers] Questions about abcm2ps)
Laura writes: | "John" == jc [EMAIL PROTECTED] writes: | John I've been registered as a developer since May. ... | John ... I still haven't stumbled across the info | John on how to put things into cvs. ... | | First, let me suggest that people who want to be developers join the | abc-discuss list at sourceforge, so we don't have to clutter up the | abcusers list with discussions of how to use cvs. Well, I joined that list some time back. I got a verification message, so I'm probably on it. But that's all I've ever received. Either the list is dead or nothing is being sent to me. I joined a couple of other lists, too, and got verification messages but nothing else has ever appeared in my mailbox from sourceforge. | I did manage to get some stuff into cvs. I used the documentation at | https://sourceforge.net/docman/?group_id=1. The two documents that | are relevant are "Getting started with SourceForge" and the | "SourceForge CVS howto". I'm willing to try to remember how I did | this if someone asks me specific questions. That's a URL that I'd have never guessed, and somehow I never stumbled across it in my wanderings. Given these pages, I've tried to check in my jcabc2ps. As often happens in the years I've been using cvs, the result is a real mess, which I'm trying to clean up. It seems to have checked in my jcabc2ps directory and everything else in the vicinity. This includes several old versions of abc2ps, and at least three versions of abcmidi. Grrr ... This does seem to be fairly common with cvs. I've seen lots of users spend hours or days trying to get cvs to check in only the contents of one directory, and being baffled by what happens. The little beast seems to like to grab everything in the parent or grandparent directory, along with the one you want. It also seems easy to get the sort of stuttering that I seem to have produced, in which a checkout produces a jcabc2ps directory, which contains a jcabc2ps directory, which contains ... I also wonder what a "vendor" is? The "cvs import" command wants this, and it's mentioned in the cvs man page. But I'm not a vendor, and I didn't get abc2ps from any vendor, so it's not at all obvious what belongs here. Or should it just be the six chars "vendor"? I did that, and it seems to have been accepted, but it doesn't make a whole lot of sense that "cvs import" would want these six chars. | As far as putting stuff up at the ftp site, the person who has done | this successfully is James Allwright. All my attempts to connect to the sourceforge ftp site have been soundly rebuffed. Similarly with attempts to ssh to their compile farm machines. Anyhow, I wonder if there's some way that I can clear out the mess that I seem to have made of my "jcabc2ps" directory and start all over? I've used "cvs delete" and "cvs commit", but then when I do a "cvs checkout", all the stuff that I tried to delete comes back. Is there some admin who can just wipe it out and let me try again? I really don't want three versions of abcmidi inside my jcabc2ps directory, but I don't know how to undo the damage. I don't seem to be finding any clues as to where on sourceforge one can ask about dumb questions like these. Their pages don't seem to contain amy mailto: links. There are some FAQs, but they don't seem to explain what to do when a checkin is messed up. It seems to be another cheery case of "Don't worry your little head about it; it'll all work just fine." But when it doesn't work just fine, well ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tall or short bar lines
John Walsh writes: | While I'm at it, I think it may also be useful to have invisible | bar lines. These could be used in difficult cases to aid the alignment | of notes between staves carrying different voices, or having different | meters (in polyrhythmic music) or when there is M:none, or when for some | other reason there were no barlines at all in one staff, as in some early | music. An alternative is some sort of tab stop that one can put in the | music to align the notes. This is implemented in abc2ps with the notation [|]. I wonder how many other abc tools understand this? I've used it in a few files, since there are places where bar lines seem to be required but I don't want a bar showing on the printed copy. One thing that I wondered about a while back, but didn't get any response from: I've seen music that uses a "broken bar", in the form of short vertical dashes (either between the staff lines or crossing them). This is useful, for instance, in an urtext edition in which you'd like to cut the bars in half for readability, but you still want to indicate which bar lines were in the original. It's also used in Balkan and Middle Eastern music to break up long bars in complex rhythms, again for readability. It seems to me that an isolated colon not next to a bar line could very well be used for this purpose. It's visually the same as the broken bar line, and doesn't seem to be in conflict with any existing usage. Hmmm ... maybe I should implement it and try using it. That would tell me whether there's some subtle problem with the idea. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Update to jaabc2ps
| gets() is only used in one place (in the original abc2ps code, at that). | Where it is used is in the interactive function and it is used to get user | input to select tunes. The buffer is 500+ characters, and it's *highly* | unlikely that the user is going to enter more characters than that. If | they should, the only thing that will happen is that the program will | crash. | | 1. User enters the search string by copy-and-paste | 2. User has copied more than they think they have. | 3. Phut. | | This ought to be fixed. Indeed. For example, on a lot of PCs running unices (such as linux), if you have a 2-button mouse, there is a common problem with the attempt at emulation of the middle button. If you click both buttons, rather than getting the Button-2-down event, something happens that tells an xterm to paste its entire history (often in some garbled form). You see the window flash, think "Omigod" and watch as the window scrolls insanely in response to the blast of input data. Typically the program running there dies, and the rest of the input goes to the shell, which valiantly attempts to interpret the flood. They keep saying that it's been fixed ... Anyhow, when cut-and-paste is an option, you shouldn't make any assumptions about how fast or how long a line a "user" can "type". To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Questions about abcm2ps
John Atchley writes: | Also, I'll be moving the distribution files to source forge once I figure out how to | get sourceforge to let me do so. Hmmm ... So I'm not the only one with this problem. When you figure it out, how about you pass on the word (or a URL for the instructions). It's a complex beast of a web site. I've been registered as a developer since May. I've periodically wandered around to see what they have, and see what I can learn. I still haven't stumbled across the info on how to put things into cvs. Or, rather, the instructions I've found have produced nothing but error messages that don't give me any clues. It looks like it should be really useful, if I could only figure out how to get it to do anything at all ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
Frank Nordberg wrote: | [EMAIL PROTECTED] wrote: | Formatting isn't important, and if we lose it, we don't lose much. | The important thing is the information content. | | Yes, but in music notation it's usually impossible to draw a clear line | between information content and formatting. Your right there. This was why I mentioned the proposed "^text" sort of extension. But an even better example is the fact that, in standard staff notation, the note heads mostly all look the same. It's their position that tells you their relative pitch and start time. (Though curiously, the stop time is indicated differently.) This is a clear case of formatting information that carries musical information. This is also one of the several ways that ABC differs significantly from staff notation, since ABC uses letters rather than physical position to indicate a note's pitch (and a number rather than a flag to indicate duration). We wouldn't be able to eliminate all formatting information, for this sort of reason. And some simple formatting information is just too useful to discard. Thus, staff ends are useful, even if you don't play them. For that matter, you don't play bar lines, either; they are primarily to make the music more readable. Even these could be eliminated without loss of much musical information content. But the basic principle is still worth noting: In the long run, it's the musical information that is of most value. Formatting information is of secondary importance, and will be routinely ignored or changed by many users anyway. The most important topic is how we represent the musical information. A bit of formatting is ok, but we shouldn't pay it much attention. This is also similar to the text world. I've seen a number of remarks from writers to the effect that they hate word processors, and prefer simple text editors. Why? Well, one journalist I heard recently just pointed out that his "product" is words. Formatting is done by the folks in the print shop, and he is quite happy to let them handle that part of the job. Not that he won't discuss it with them or criticise them at times. But his emphasis is on writing, and all he wants is a simple way to produce a string of words that others can read. Word processors are complex and distracting, and produce text that can only be read by a few people with the same sort of software. Only a few experts can do much with the text. Plain text can be sent to anyone, and they can format it however they wish to make it look nice on whatever sort of surface they are reading it from. ABC's niche, if it has one in the long term, should be similar. We should let the folks building the fancy music processing software worry about things such as formatting. What we should concentrate on is the musical information, in a form that is as easy to type and read as we can make it. One goal should be to make it easy for other music software to read ABC, and to generate it. Then ABC will function as a medium of exchange between programs that can't read each others' file formats. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Egregious example of line wrapping
Phil Taylor suggested: | Jack Campin wrote: | BarFly is AppleScriptable, isn't it? So, if you've got a Mac on | your network somewhere, you should be able to tell it to: | | - open the file | - go into split-screen mode | - do Print Preview | - save as PICT | ... | The other problem would be in figuring out how to write a CGI | to run on a unix machine which can assemble and transmit | AppleEvents to a remote Mac. I'm sure it can be done, but | I haven't a clue how. Ah, I can see it now. Someone asks my Tune Finder for a tune that happens to be in BarFly format. So my CGI scripts, running here on trillian, locate a nearby Mac that some poor victim is busily using, and downloads BarFly into it (if it's not already there from an earlier request). The victim's screen then goes into split-screen mode, and displays a page of music, which is then saved on the victim's disk, while the victim sits there wondering why the Mac has suddenly gone berserk. My CGI script then downloads the PICT file and send it off to the person who asked for it. After a while, all the Macs at MIT will have their disks cluttered with these mysterious PICT files that contain pages of music. This would make me really popular around the campus, once they traced these events and files back to my Tune Finder! (Actually, I wonder if a Mac could be commandeered this way. It does seem to be possible with Windows, as all the recent email macro virii have demonstrated. Can Apple have missed such a powerful feature? ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Egregious example of line wrapping
| Jack Campin wrote: | many people who use JC's Tune Finder will just want the gif or midi | as they wouldn't know what to do with the abc. For such a user, an | automatic fixer would be an improvement even if it only worked for | some of the tunes. | Perhaps the best of all solutions would be to detect the bad tunes | and notify their owners so the problem can be fixed at source. | | AAARGH!!! if some piece of software out there was going to niggle me | about every ABC tune I've been responsible for that it couldn't handle | I'd pull the whole damn lot off the Internet. Frank Nordberg replied: | Don't worry Jack, it ain't gonna happen. You're right. In fact, I've thought about the making my Tune Finder make a guess at the email address. You might be surprised at how feasible it is. However, an automatic message strikes me as a very bad idea. It's not quite spam, but it's a related concept. If I did it, what I'd do is (as someone has already suggested) have the tune extraction code generate a page describing the problems and supplying the requestor with a link to the error log and an email address. They could do with this as they wish. It would then take human action to send email, and nobody would be flooded with machine-generated email messages. But I've only thought about this; I'm not sure I even want to spend any time implementing it. There are more important things in this world to waste time on. Playing music is one. | But you've got a point. I have myself posted about a hundred piano | pieces in "BarFly ABC", simply because there's no way abc2ps can render | those pieces properly. I would just hate having my e mail inbox filled | up with "error messages". This is a major reason why an automatic message is a bad idea. The fact is that abc has developed several branches for different sets of users. This is both a good and bad thing. It's good because it is a force for making ABC into a more capable notation. It's bad because it produces incompatible ABC. This is another way that ABC is like traditional staff notation. I personally hope the process will continue, with people pushing for new features and for compatibility. As the owner of a somewhat significant ABC web site, the problem that I'm trying to get people talking about is that my Tune Finder is often asked for tunes that have ABC that's not compatible with the tools that my site uses. Barfly extensions are a good example of this. I can't very well adopt Barfly as one of my site's tools, because it is a GUI tool, and those don't work all that well when called by CGI scripts. It's inevitable that people working on GUI tools will do things a lot differently than people working on CGI scripts. My concern in this case would be how to detect the incompatibilities and "correct" them so that my tools can handle the ABC sensibly. However, the example that I presented was not one using extensions. It was one that had been badly damaged, probably by email software, and probably not with the owner's knowledge. This sort of damage is quite common. I doubt that any ABC users will defend it. The question is how to recover from it gracefully. In this example, what comes out in the PS or GIF or MIDI is garbage, and is not at all what was intended. I'd guess that the owners of such files would be happy to get one or two messages describing the problem. If you put a tune on the web, presumably you intend that others download it and use it. Damage like this will turn the tune into garbage for a great many users, and I'd guess that most people would quickly fix such problems when someone points it out. Meanwhile, users of the Tune Finder have a problem that I get a fair amount of email about. Many of those users don't have a clue as to what has gone wrong. They just see music that is bizarre and clearly has something badly wrong. Many of the users don't stand much of a chance of fixing it themselves. It does seem to me that a lot of this sort of damage (and some extensions) can be fixed in most cases. The problem is how to successfully recognize just the damaged ABC and not correct things that don't need correcting. Fixing extensions that my tools don't recognize is a minor problem. Both abc2ps and abc2midi tend to "pseudo-recognize" extensions by ignoring them, which is good enough in most cases. Perhaps the idea of presenting users with a special page that says "This file appears to be seriously damaged somehow" and giving them pointers or a menu of things to do about it might be the best way to deal with it. Such special pages might be a good idea in general. It would be nice if users could get at the options for abc2ps and abc2midi, and the only way to do this from a browser is via web pages that present the options, let you choose what you want, and then you push a Submit button to
Re: [abcusers] Is there a Tex style backslash character for non-breaking space?
Phil Taylor asks: | I have a plea from a BarFly user who is transcribing Polish hymns, and | he needs a way to place two words on one note. Now he can do it using | the Mac's non-breaking space (option-space), but would prefer a more | portable method, since that character is not necessarily an NBS on | other platforms. If you're using the w: lines, abc2ps and some other tools use the ~ (tilde) character as a "space treated as a letter". Its use is for putting more than one word on a single note. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Fortune My Foe V:?
| As a matter of interest, which packages are happy with the V: commands? | Just the other day someone was pointing out that they are not in the | standard. | To start the ball rolling, Muse found no problem with them. Well, abc2ps has had them for some time now. But I think there are still some incompatibilities in how V: is implemented. In fact, maybe it's time for another raging discussion of the issue ... [Troll, troll ...] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: O'Neill errors
| What sort of a scale would use ^G_A^B? | | _E^F_B or _E^F_B^C definitely make sense (tonic is D). Yup; I use both of those. However, the first corresponds to two different scales that are common in the Balkans, with tonics C and D. The second I only know with a tonic of D, though I wouldn't be too surprised to hear that it could also have A as the tonic. That seems like a reasonable scale to me; I just don't happen to know any music that uses it. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: O'Neill errors
John Henckel remarked: | I don't think the abc standard should allow K:^g _a ^b I.e., you don't think ABC should be used to transcribe music that uses scales other than the classical western-European modes. Or, if people insist on doing such a thing, they should be forced to use a classical key signature and clutter the music with accidentals to get it into the right scale. But I am curious: What sort of a scale would use ^G_A^B? I don't think I've ever heard such a scale. Presumably the ^G and _A would have slightly different (microtonal) intonation. The huge gap from _A to ^B makes it look like some sort of pentatonic scale. What's the tonic (if there is one)? To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: O'Neill errors
John Walsh wrote:
| Frank Nordberg wrote:
| A problem with the O'Neill tunes is that many of them doesn't
| seem to have a clearly defined tonal centre at all.
|
| Ah, that's interesting. I think it's one of the great interests
| of the tunes, rather than a problem, but of course Frank's talking about
| notational questions, not musical interest here.
It's interesting, but as for it being a problem, I'd say that the
current buzz phrase "Deal with it!" applies. Traditional Irish music
has a lot of examples of tunes without a clear tonal center. Usually
the feel is as if the tune were "wavering" between two (or sometimes
three) tonal centers, with none the main center. It can't be fixed;
it's part of the style. The tunes like this aren't the "norm"; they
are a minority. But they are definitely part of the tradition and
something that you need to be familiar with if you want to really
understand the style. This can bother people coming from other styles
that always have clear tonal centers. It is a minor problem with ABC,
which wants you to specify a tonic note. So you just pick one of the
likely tonics, and tell yourself that it's not a major sin.
One of my favorite examples is the well-known Blarney Pilgrim. I just
checked with my tune finder, and there are 35 instances on the Web.
About 2/3 are in G; the other 1/3 are in Dmix. The tune is highly
ambiguous about which is the tonic center. I've found that, although
it can be harmonized with chords, I like it better with just a quiet
drone, and the drone note should be D. But this doesn't mean that D
is the tonic, because a drone on the 5th is quite normal in Irish and
Scottish music. The tune is almost pentatonic, but there are a few C
naturals. To most ears, this would put it in G major, but to ears
attuned to the Mixolydian scale would make it Dmix. And the fact that
it starts and ends on the low D is probably a point of tension to
many ears ("It's not resolved"), but a perfectly satisfying ending to
ears attuned to this style of music.
| [EMAIL PROTECTED] wrote:
| and I realize I am in the minority on this, but I continue to feel
| that the K: field should describe the number of sharps or flats
| without naming a tonic and/or a mode.
|
| Well, if you'll amend that to "...the K: field should *be able* to
| describe the number of sharps or flats without naming a tonic and/or mode"
| you might not be in the minority. At least you wouldn't be alone, for I'd
| agree. But I think it should also be able to describe the tonic and/or
| mode, along with a quite few other possibilities.
Agreed. This is what I've done with my doctored abc2ps that accepts
the extended syntax
K:tonicmodeaccidentals
As a computerized music notation, one of the nice things about ABC is
that it allows you to state the tonic and mode, unlike standard staff
notation. This is useful for searches, especially when transcribers
get it right. But it's more limiting than
K:accidentals
This should be allowed, for various reasons. Frank has pointed out
one of the musical reasons: There are musical styles that lack a
clear tonic. For such music, requiring a tonic is inappropriate and
misleading, and leads to "false positives" in searches.
This is a different argument from the usual one based on transcriber
ignorance: It's better to see just K:^f than, for example, K:G when
the correct key is K:Em or K:Adorian or K:Dmix. K:^f is a way of
saying "I don't know what the tonic is, but the f's are (mostly)
sharp. With Irish music, you do see cases where what you'd like to
say is "Well, all the f's are sharp, but it's not clear whether the
tonic is G or D, and a few bars seems to have A as the tonic center."
I doubt that we'd want to have an explicit ABC notation for this.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Is anything missing?
James Allwright writes: | On Mon 02 Oct 2000 at 01:05PM -0700, [EMAIL PROTECTED] wrote: | It did come up with somewhat fewer total tunes than before, though | the number isn't very different. The main loss seems to be that | perun.hscs.wmin.ac.uk has gone away, and its 1077 tunes are also | gone. It seems to have gotten flakey some time back, with no response | in most attempts. Anyone know what happened to it? | | perun does seem to be down a lot. However, I've moved all the tunes to | the ABC project website at sourceforge, so everything can be accessed | from there. A quick check shows that the ABC search bot found around a thousand titles in http://abc.sourceforge.net/NMD/, which is the Nottingham database. Somewhat fewer titles actually (940 vs 1077) than were found on perun, but this could be simply from different organization that removed duplicates. I wonder if there are any other ABC files lying about on sourceforge? Maybe I should get serious about joining in there. Among other things, I've got a flock of test files, mostly not very musical, that could be useful for such an effort. And there doesn't seem to be a clone of abc2ps there yet. My searcher has found a number of what are obviously ABC test files, my own and others'. This is an interesting borderline case. Most of them are not really "music", and of little interest to most musicians. On the other hand, it would be useful if developers could find them quickly. Maybe we could establish a convention that such files have their first T: line start with "T: TEST:", all upper case, so that they stand out clearly as test files. I think I'll to change all mine to do this. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] O'Neill's 1001
| Frank Nordberg wrote: | In case somebody wonder why I've been so quiet recently: | | I've just finished the first half of my own private O'Neill project. | The first 500 tunes from Francis O'Neill: "The Dance Music of | Ireland" (known as "O'Neill's 1001") is now available as ABC at: | http://www.musicaviva.com/abc/oneill-1001-1-500.abc | | Dzjeez, what kind of a job do you have that leaves you with so much free | time? I can't even find the time to transcribe the odd one hundred tunes | I'd like to put on-line... Meanwhile, I told my ABC bot about Henrik's .../abc/abcusers/ directory and about the above URL, and the number of ABC titles listed for www.musicaviva.com nearly doubled. The reason that the abcusers/ directory hadn't been scanned was that it was too far from my starting URL. I've found that it's a good idea to limit the depth of Web searches to 3 hops, to avoid trying to search the whole Web for ABC. This isn't very productive; having other people spot new ABC sites and tell me about them is far more practical. And the oneill-1001-1-500.abc doesn't seem to be pointed to by an link, so it would have never been found. I've wondered about O'Neill's 1001 myself; it's nice to see someone so masochistic as to take it on. But I wonder about putting it all in one huge file. This will lead to a lot of slow downloads for people just looking for a tune or three. So when does the Svenska Laatar Project begin? (How many volumes of that were there?) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Is anything missing?
Henrik said: In case somebody wonder why I've been so quiet recently: I've been a bit quiet, too, in part because of a bit of reprogramming of my ABC search bot. I thought I'd mention it now because I just ran a full search, and thought people might like to check with my tune finder (http://trillian.mit.edu/~jc/music/abc/findtune.html) and see if any of your tunes are missing. The reason for this is something that I'd sorta been wondering about since I started hearing, a few months ago, about a new breed of web search program. The problem was all the "hidden" web pages that are not on disk as files, but are generated on the fly by programs. It seems that the big search sites are developing tools to extract these "hidden pages" and index them. When I first heard this, my thought was "Uh, oh ..." Last week, my fears came true. A couple of search programs learned how to invoke my tune finder's scripts and the resulting pages with their links to scripts that convert ABC to PS, GIF, PNG, MIDI and other formats. One little monster was systematically asking for every ABC tune in my indexes, in every format that my scripts know how to return. And it was asking in parallel from a large set of machines. It drove trillian's load average up to 25, filled the disk with temp files, and brought everything to a halt. Luckily the folks who run trillian, at MIT's EE Dept, have a bit of a sense of humor. I actually spotted the disaster before they did, and they had email from me waiting for them. I added a "blacklist" feature to my scripts that knows the IP addresses of the worst culprits and won't talk to them. Meanwhile, I've been put in charge of trillian's robots.txt file, and all the other search bots seem to have been scared away from my own music stuff for the present. My tune finder was a zombie for a day or so, but it has recovered. My own search program now follows a somewhat more complex strategy: It looks for and parses robots.txt files, and mostly obeys them. This has cut its search time in half, actually. But it also compares a URL with its explicit list of "allows" URLs, i.e., its list of starting URLs, and searches them even if the machine's global robots.txt file says not to. This is necessary so that it can search my own ABC files, which are now off limits to searchers. It should find ABC files if they're below a URL in my starting list, even if the machine as a robots.txt file. It did come up with somewhat fewer total tunes than before, though the number isn't very different. The main loss seems to be that perun.hscs.wmin.ac.uk has gone away, and its 1077 tunes are also gone. It seems to have gotten flakey some time back, with no response in most attempts. Anyone know what happened to it? Aside from that, there were losses of 1 or 2 ABC files on a number of other sites, but no single huge losses. You might check to see if any of your tunes are missing. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New Orleans Jazz
Atte Andr=E9 Jensen writes: | Y'know, I've gotten a number of email messages from jazz musicians | wondering the same thing. ... | | And one of them is me! What stalled me is the issue of copyright. I would | not have an official collection of abc's on my sitespace without that in | place.=20 My experience so far says that this may not be that big a deal. Make sure that your main page has a notice to the effect that you aren't sure of the copyright status of a lot of the tunes, and anyone who knows should send you email. Also say that if a tune's rightful owner objects to it being there, you will remove it and replace it with a copyright notice. And, most important, say that an alternative is to add a copyright notice, email address and URL to the ABC headers if they prefer. In my various email contacts with tune writers, so far I've had only one who didn't want their tune in ABC on my site. What typically happens is that they don't have a clue about ABC. So I send them my brief intro, and also a copy of their tune in ABC. I ask them to edit it, and to suggest the copyright notice, email address and URL they'd like to see in it. They invariably send it back with this information. I think that most people realize pretty quickly that the ABC file is not really much of a competition for a printed copy, and is no competition at all for any recordings. They also realize that having their email address and URL in the file is free advertising. It is that, but it's also attribution that I like to see in all my ABC files. I'd bet that the composers of jazz tunes will mostly respond the same way. Be prepared to send them a brief intro to ABC. I have a couple at: http://trillian.mit.edu/~jc/music/abc/doc/ You can copy them, and modify them however you like, maybe with one of the jazz standards as the example. Chances are that you'll also be asked to remove one or two tunes, but if you're prepared for that and have a friendly notice to that effect, you probably don't have any real legal worries. And the few who don't give you permission are probably hurting their own pocketbooks. I've received a fair number of requests for printed copies of the tunes in my collection. I'd guess that Henrik and Richard and the owners of other large ABC sites also get such requests. So far, I've said "No" and referred people to some of the music publishers and book sellers. Ultimately, online stuff doesn't really hurt sales of printed copies, because books are just too convenient (as long as they open flat on a music stand ;-). The main thing that online archives do is make it easier for people to find what they want. A guaranteed reaction to finding tunes online is "I like these tunes; where can I find more like them?" If there are links that lead to the printed copies of tune collections, they will also lead to sales. You want to educate the publishers to this, as subtly as you can. So my advice is to put what you have online now. And send me the URL. Or post it to this list and any other relevant lists that you know of, with maybe a hint that you'd like to find others to help with the online jazz fake-book project. And collect URLs for online sellers of the printed fakebooks. If they give you any hassle, just let them know that if you can't include a few of their tunes, you will also remove the link to their site. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Musicator2abc-conversion
S=F8ren writes: | | I have about 450 Musicator-files (.mct) with scandinavian folktunes which= | I | would like to convert to abc-format for web-distribution. They are | currently distributed as GIF-files (check: | http://www.folketshus.dk/folketshus/spillefolk/noder.html) which are OK f= | or | screen-presentation, but to lousy and unpractical for print, I think. | | Conversion via MIDI is very tidy (means not practical possible) since all | notation layout is lost. | | Does anyone know about conversion-tools - or does anyone know about | Musicator-file-format ? Got a pointer to a spec? If Musicator files are text files, it's likely that I or someone else could grind out a perl program to chew it up and spit out ABC. It would also be helpful if you could give a URL for a directory of files in Musicator format. Then we could look them over and decide whether we want to tackle the translation. (Or maybe I could use this as the excuse I've been looking for to get some more experience with python. ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] New Orleans Jazz
Derek Lane-Smith wrote: | It seems to me that abc is an ideal format for building a library of New | Orleans Jazz standards. Does anyone know of such a database? Or of one in | some other format that is accessible, and that can be converted to abc? Y'know, I've gotten a number of email messages from jazz musicians wondering the same thing. What I tell them is that I agree; jazz musicians usually like fake books, and abc is a good tool for that. With the w: lines, it's nearly ideal. I also tell them that I don't know of any abc jazz sites, this is an ideal opportunity for them to be pioneers and start one, and they should send me the URL as soon as they have a few tunes online. So far I haven't heard back from them. So how'd you like to be the pioneer? Pick a dozen or so standards, type them up, and send me the URL. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABCchecker
| There are several ABC programs that do support multiple voices - I though= | t | that there was a list of these somewhere but I can't find it. maybe I've | missed it. John Chambers' FAQ ( | http://trillian.mit.edu/~jc/music/abc/ABC-FAQ.html ) includes a number of | lists of which programs support which features, but I don't see a list of | programs supporting V in there. Hmmm ... Maybe we should get together a list. Anyone want to volunteer info on specific programs they're using, and whether (or how well) V: is handled? | A little more digging around reveals the following list of programs, whic= | h | also includes some information about features they handle: | | http://trillian.mit.edu/~jc/music/abc/ABCsoftware.html Jeez; I thought I deleted that one; it's gotta be really out of date. ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V:
| Muse has handled V: for long enough that I've forgotten how long | ago I did it. Memory getting weak in old age, eh? Anyhow, this reminds me of something that I started some time back and haven't collected much data for: http://trillian.mit.edu/~jc/music/abc/doc/ABCfeatures.html The Muse entry for V: lines has been duly changed to "Yes". There is also the question about which of the various proposed forms of the V: lines are supported. My table currently lists only the name= and clef= fields. Maybe I should try to dig up a list of all that have been proposed and/or implemented and add them to the table. Another question: How many branches to abc2ps are there now? I'd like to know about any that are available on the Net, and the best URL to download them from. Then there's the problem of putting such a spreadsheet up on a web page. It might get rather wide ... -- Modern GUIs are very well designed, for people with three hands. The real problem has been how slow customers have been to make necessary hardware upgrades to meet the requirements of the software. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Removing gracenote ties for bagpipe notation
Eric Mrozek writes: | I'm using abc2ps/Ghostscript to print bagpipe music and would | appreciate information on how to remove the curved tie | between the grace-notes and the melody notes. Jackson. | | The last I knew there was no command line option to turn off | ties on grace notes. My bagpipe variant of abc2ps, available | at http://www.eecs.umich.edu/~mrozek/abc/abc2ps.html, | will turn off grace note ties if the tune header contains a |K:HP | line (which sets the "key" to "highland bagpipe"). Fortunately | for your purposes it also removes the key signature, forces | all the main notes to be stem-down and all grace notes to be | stem-up, and prints straight flags instead of curved flags | (common conventions for printed bagpipe music). | | For those who aren't interested in bagpipe notation, you | can always contact the authors Michael Methfessel (abc2ps) | or Jean-Francois Moine (abcm2ps) and ask them for specific features | or options. Or contact me. ;-) It seems that abc2ps is going through the process of branching, to solve the problems of various users who can't get their music notated properly using the original. This is somewhat inevitable, of course, and isn't really a criticism of the original program so much as a comment on how useful it really was despite its limitations. Anyhow, I've also gotten a bit frustrated with the limitations on grace notes, including the spurious slurs. I've been thinking of getting rid of this misfeature. Actually, what I'd do is make it optional, with the option defaulting to off. So, for the benefit of those working on their own branches of abc2ps, maybe we could get a few pointers to just what chunk(s) of the code need to be modified to suppress these slurs on grace notes. If not, maybe I'll try to find time to dig in and fix it myself. And maybe relax a few of the other "rules" for grace notes. For example, I have several cases where I really need a grace note at the end of a main note. With abc2ps, you can only get this if there's another note afterward; you can't get it before a bar line. And, of course, it's slurred to the next note, not to the preceding note. And while I'm at it, I may try to figure out why abc2ps won't put things like fermatas over bar lines ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Auto harmonization
Frank Nordberg writes: | | ABCTwin is a program for automatically creating two and three part | harmonisations of ABC files. It can be downloaded (just 48 KB) at: | http://www.logeny.com/abctwin.htm Thanks, Frank. I fed that URL to my tune finder, and there are now 166 new titles in the index. They have quite a number of examples of ABCTwin's output on their site. The harmonies are rather stereotyped and boring, of course, but are probably quite useful for people who want to learn how to do such things. | Unfortunately it's Windows only. Anybody got similar ideas for other platforms? I have an even dumber tool that I've used, which simply replicates a melody line N notes higher or lower, using [...] to get the harmony. I wouldn't really consider offering it to the public, because it's so basic and invariably needs some editing. I mostly use it from within the vi editor to cut out a few measures and add a basic harmony in 3rds or 6ths, which I then tweak with a bit more editing. I've been thinking of experimenting with more complexity, though. Thus, in the Balkan music that I play, there's a substyle that uses very closely coupled harmonies, mostly thirds, but 4ths and 5ths at some spots. The style has very stereotyped rules, and I've been thinking that I could probably program it to know the exceptions from the 3rds. Also, I'd consider this an example of why it's difficult to design a general program for harmonies. This style is a "parallel thirds" sort of harmony, but some of its details are different from other similar harmonies. A decent program to generate harmonies would need to have a lot of options to tell it what style you want. And its output would still get sneers from most Real Musicians who know the style. But such a program could be very useful as an educational tool. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
