Re: [abcusers] Version 2.0.0 voice overlay and lyrics
John Chambers [EMAIL PROTECTED] wrote: I've seen a few discussions of how slow the RSCDS has been to take advantage of the Net. My usual comment has been something like: Of course they're a bunch of conservative fuddy-duddies who are decades behind the times. The RSCDS exists to preserve a tradition. It's their role to be conservative fuddy-duddies who are decades behind the times. It's up to us radical revisionists to develop their online system, and when they're good and ready, we can give them a copy of what we've done. (When this happens, I expect they'll just invite 2 or 3 of us to do the work. There are moves afoot to do exactly that. Chances are that when this happens the RSCDS folks (who aren't all »fuddy-duddies« at all -- since the big changing of the guard a few years back they're really nice folks once you get to know them) won't quite know what hit them :^) What I'd be tempted to do is set up a SCD wiki and invite all the strathspey subscribers to contribute.) The fun thing is that this already exists. It's not been advertised a lot but I have one on the www.strathspey.org site -- it's now being used for the »frequently asked questions« that I don't have time to really work on (or so it seems). If there are other worthwhile uses for it then great. Yes; he already links to the Fiddler's Companion site. Maybe we should both be discussing with him the easiest way to interconnect all of our sites. I have sets for about 600 dances in my collection (a bare start ;-). I've developed an approach that works for me. But it might be time to start talking about linking the SCD web sites. Alan isn't really concerned about the web aspect of DanceData so far; the web front-end is really my baby. I would like to see the music aspect of DanceData souped up; Alan isn't a musician himself and I know he wouldn't mind some help in that direction. I suppose what would be nice would be an extension of the database (or at least the web front-end) to cover non-recorded sets of tunes -- so far, the database deals in suggested tunes for dances and in recordings of sets of tunes. The easiest way to do this within the existing framework might be to come up with a »super-album« (or albums) of non-recorded sets and to pretend that they're all tracks on that. On the other hand, we're really dealing with sheet music here, so the proper way to do this is by allowing tunes in the database to have sheet music (a.k.a. ABC) associated with them and then assembling sets out of the individual ABC entries, tune-finder style. We should probably take this off the ABC list since it won't be interesting to most subscribers. I get the impression that a lot of teachers have put their favorite dances into their computers, and some are online. But they all do it differently. I wonder how long it will take for this to get into a form that can actually be used? I've collected a few myself, but my dance descriptions are in N different formats. Having standardized notations for cribs, dance descriptions etc. is one of the yearly discussion topics on Strathspey that never seem to get anywhere. I thought it was one in my collection, so I whipped out my cute Kyocera smartphone (which runs PalmOS and has some ABC software installed), used the browser to find the dance on my MIT site, and handed her the phone with the dance description on the screen. I got lots of geek points for that one. Oh yes, gadgets. A colleague of mine is working on the (Linux-based) system software for one of those newfangled harddisk-based MP3 units. The difference is that that thing has a fairly big LCD screen (for video display). It has a 40GB disk, and thus could store several hundred CD's worth of MP3 dance tracks -- and it would be eminently possible to embed dance cribs or even Pilling-style graphics in the MP3 using special »tags«. I told him that if he adds variable speed control to the thing I'll buy one the first day it is out :^) We're stuck with recorded music for dance classes and I should greatly enjoy not having to haul all those CDs to class. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Trying to get Windows to run on the hardware that Linux typically runs on is like pushing an elephant through a keyhole. -- _Forbes_, November 1998 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Version 2.0.0 voice overlay and lyrics
John Chambers [EMAIL PROTECTED] wrote: Hey, glad to see you're doing this. I've volunteered in the past, but the RSCDS didn't respond. So far I'm doing this for my own enjoyment, with no official RSCDS sanction. I want to have an »Original Tunes for RSCDS Dances« book that saves me hauling 40+ booklets to those workshops where the teacher makes up his mind what to teach over breakfast on the same day (no kidding). I haven't yet decided what to do about publication of the ABC files. I suppose the thing to do would be to integrate them into Alan Paterson's DanceData somehow (or at least the WWW front end) and see what happens :^) If you're trying to transcribe the entire RSCDS versions of tunes, you might want to start commenting here about the abc limitations. You'll probably see a lot of them. Keyboard music is the worst case. I'm only doing the melody and chords. I try to stick to what is in the books but don't lose sleep over stuff that I feel needs changed. Are you doing the dance descriptions, too? No -- different construction site. I need the dance descriptions only when I'm teaching, and then I usually know what I want to do and just take the book along. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] I just found out that the brain is like a computer. If that's true, then there really aren't any stupid people. Just people running DOS.-- Haavard Fosseng To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Version 2.0.0 voice overlay and lyrics
John Walsh [EMAIL PROTECTED] wrote: I concluded that if I were to use this any more, I'd need a pre-processor of some sort... So if we want to preserve human-readability and use the in any complicated way, it might be worthwhile discussing alternatives. My little project is ABCifying the tunes from the RSCDS dance books. Some of the tunes have a second voice every so often (say, in four bars out of twenty-four), and the »« feature saves me a lot of typing in [V:2] bits that are mostly empty. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] I don't know a lot about this artificial life stuff -- but I'm suspicious of anything Newsweek gets goofy about -- and I suspect its primary use is as another money extraction tool to be applied by AI labs to the Department of Defense (and more power to 'em). -- Aaron Watters To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC source code license?
Jeff Szuhay [EMAIL PROTECTED] wrote: Is all ABC Music source code under GPL? (If so, that's a real bummer. An Artist License would be much better for its adoption in commerical products.) You can always try to contact the author(s) and negotiate a different license than the GPL. It is perfectly possible for code to be released under different licenses at the same time. Of course this may cost you something. Is the ABC Music itself under GPL? (If so, then I can't use it at all.) Well, first off there is no such thing as »the ABC Music«. The copyright of tunes notated in ABC lies with the composers and/or arrangers or their estates (for 70 years after the composers' and/or arrangers' demise) or else the public domain. It is likely that the composers/arrangers in question have delegated the licensing stuff to an outfit like ASCAP (in the US) or GEMA (in Germany). In this case you will have to negotiate with that rather than the original composers/arrangers. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Experience is a hard teacher because she gives the test first, the lesson afterwards. -- Vernon Law To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: The F F (and F F2) problems
James Allwright [EMAIL PROTECTED] wrote: What and gives you in abc2midi is a notation for tunes in 6/8 masquerading as tunes in 4/4. This covers hornpipes and probably strathspays (though I can't tell since I don't get to hear very many of those). This is not a mistake. Yes it is, as far as strathspeys are concerned. Many people play »« stuff in strathspeys tending towards 7:1 rather than 3:1 (that is, »AA« sounds like »AA« rather than »(3A2A«) but very few people if any consider strathspeys pseudo-12/8. The »« notation is so useful for strathspeys, many of which consist of nothing but »XY« and »XY«, that insisting that it is just for hornpipes strikes me as very impractical indeed. Look at, say, any volume of Kerr's Collection to see that »« (and »«) is just what the doctor ordered. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Caveat: untested, so there may be typos, or even thoughtos. -- Donald Arseneau To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The F F (and F F2) problems
James Allwright [EMAIL PROTECTED] wrote: I have taken the view that '' is a function to be used only in a very specific setting and trying to generalize it for other uses is courting trouble. So, in abc2midi, ;+ is intended for hornpipes only? What about strathspeys? Anselm To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Palm Pilot advice please
Steve Mansfield [EMAIL PROTECTED] writes: Anyone got any suggestions as to either (a) where my enquirer might find the pipe symbol On my Palm (which admittedly is a German model) the pipe symbol is »dot«-»upstroke-downstroke«. Tell your correspondent to check the built-in Graffitti help if she doesn't have her manual handy. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] You're much more likely to be knocked down by a snowball than by an equivalent number of snowflakes. -- Larry Wall To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Fonts.
Jack Campin [EMAIL PROTECTED] writes: I think it would be better to adopt one font for the symbols (music encoded in ABC doesn't need a great number of them) and let users assign other fonts to specific roles in the score themselves (title font, composer font, text annotation font...). A user who is trying to embed scores generated by your software into other documents, or match an existing house style for publication, will need the ability to control these. Definitely. If you must make a choice or set a default... My favourite variable-width serif text font is Palatino. I arrived at that choice by experiment: my vision is not particularly good, has been deteriorating for years, and this was during a bad patch. I printed a pageful of the same text at the same size in every font I could find, seeing which one was readable from the greatest distance. Palatino won by a big margin, with Computer Modern far at the bottom by an even bigger one. I rather like Palatino too. The problem with Computer Modern is that to look good it requires printing at a really high resolution (Knuth's books are typeset on a phototypesetter that does something like 4333dpi, and the 600dpi that current laser printers can manage are definitely not enough), so while it is in many ways a very good design the output devices that the likes of us are likely to have around won't really be able to do it proper justice. There is a free Palatino lookalike available with Ghostscript. I haven't done the same experiment as thoroughly with other kinds of font, but get the impression Gill Sans would beat any other sans-serif proportional font at the same test. I generally use Courier for fixed- width but I'm sure there must be something better out there. Gill Sans is another one that I like. If you go with Palatino a good sans-serif font to use with it is Optima, also by Hermann Zapf (but I don't think a free version is available anywhere). You can get a CD-ROM from Bitstream that has something like 500 fonts at a very reasonable price; the fonts are not great but they are certainly more workable than the usual »1000 FREE FONTS« offerings that you get from jumble sales, and that includes fairly nice versions of Palatino, Gill Sans and Optima. For fixed width, Courier is about as bad a font as there can conceivably be. Knuth's Computer Modern Typewriter is not at all bad (and it even comes in a sane encoding, compared to the rest of CM). Recent distributions of X11 contain a mostly-free set of fonts by BH called »Lucidux« which includes a rather nice monospaced variety. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Host: What a parasite lives in or on. Your programs have this relationship to the computer. -- Larry Wall Randal Schwartz, *Programming Perl* To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Folkband
John Chambers [EMAIL PROTECTED] writes: Part of the story was that if you played the King's tune three times, he would appear. He would usually be in disguise, of course, so you wouldn't necessarily realize he was present. And summoning the Fairy King isn't something that one does frivolously. If he doesn't enjoy your event, he has ways of making you sorry you summoned him. Of course this doesn't apply to practising the tune; the Fairy King likes his music played properly and looks benevolently on those who apply the necessary diligence ... Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] The basis of all excellence is truth: he that professes love ought to feel its power. -- Samuel Johnson, _Lives of the Poets_ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is philosophy
Simon Wascher [EMAIL PROTECTED] writes: Any expression a person wants to use should be legal as long as it does not collide with the integrity of the syntax. Not asking all the time why should we allow this ? but Why not? No. Extraneous ways of writing down the same thing means that programs which process the notation need to be more complicated in order to process all the possible variants instead of just one that is standardized. More complicated programs have a greater likelihood of containing mistakes. We emphatically do not need programs that contain more mistakes than necessary -- the world is full of them already. On a more abstract level, having several ways of writing down the same thing makes the standard longer. A longer standard takes longer for a person to read and understand, and therefore the extra complexity should be restricted to things that actually add expressive power to the ABC language. Allowing `13' and `1+3' in addition to `1,3' does not add expressive power, thus should be rejected. Finally, people new to ABC will wonder whether `1,3', `13' and `1+3' actually do mean the same thing in ABC or whether there are subtle, non-obvious differences between the three that they don't know about. This will be unnecessarily confusing. The word is `KISS'. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] I'd rather poke myself in the eye with a sharp stick than do GUI programming in Java. -- Mo DeJong To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
John Walsh [EMAIL PROTECTED] writes: Some programs (abcmus for sure, and judging by other comments in this thread, Barfly, probably others too) use the R: and M: fields to determine the tempo (and, more, a stress program) which can be modified by the user as desired. It's a great feature. I think of the translation of allegro into beats per minute as an extension of this. I must say I quite like the idea of `stress programs' as exemplified by BarFly. They are a nice illustration of my claim that ABC notation and presentation details are best kept separate. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Convictions are more dangerous enemies of truth than lies. -- Friedrich Wilhelm Nietzsche To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Looking for ABC transcriber.
James Allwright [EMAIL PROTECTED] writes: Since Playford published his collections of music several centuries ago, you are pretty safe in assuming the copyright has expired. Yes, but it might be construed that there is copyright on editorial changes within the transcription, which may be more or less obvious. A lot of Playford stuff is available from the US Library of Congress (they have a special page on the history of dancing, the URL of which escapes me right now), so one could go back right to the original sources to make sure that the ABCs in question are `uncontaminated'. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] From a limp beginning, the erotic information processing market has been rising in recent years and is now quite firm, although the recession has created some soft spots. -- Tom Betz, in rec.humor.funny (1989) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Simon Wascher [EMAIL PROTECTED] writes: For reasons of scientific quality I need to include as much as possible information of the original source within the file, as near to the original as possible. So the file should be a representation of the playback *and* the the display. The ABC file should be an approximate representation of the *musical content* of a piece. Anything else is likely hoping for too much -- as far as playback is concerned, an ABC file of Bach's Goldberg Variations would probably be closer to the sort of modern edition of the work that you can buy in a music shop than to either Bach's original manuscript (on the `display' side) or Glenn Gould's recorded interpretation of the piece (on the `playback' side). Both exploit dimensions of `presentation' that are simply not available in ABC notation, nor likely to be, and while the ABC edition of the piece would be nice to have around the house and let us have all kinds of fun with it, it would most probably never be the one or the other. As I said earlier on, if you want a near-facsimile replica of an original source, ABC is probably not the right vehicle for your work -- at least not without major tweaking of the standard and without restricting yourself to a particular output program (since the standard, fortunately, doesn't prescribe printed ABC output in enough detail for the various notation programs not to differ greatly from one another in just how they display things). Note that ABC in its current form doesn't even let you specify whether the stems of notes go up or down in a sequence like `ABc', so if you want to imitate a given score as closely as possible (we're talking `science', after all) using ABC, you have still quite a way to go before you're done. I don't know a lot about Lilypond but it might be worth checking out for your purposes. In any case if you're after a specific look to your sheet music you would do well to publish PDF as well as ABC, since even if you stick all your little presentation things into the ABC standard others will not be able to reproduce your output with anything approaching `scientific' precision unless they run exactly the same software that you do. Similarly, if you want to capture or express all the details of the performance of a piece of music then something like a MIDI file may really be the way to go, rather than ABC. All three formats -- ABC, PDF, MIDI -- fill different `ecological niches' that do overlap to some extent, but any one of the three could never fully replace either of the others. I'm not saying that you shouldn't try to make ABC do everything that you want. I'm just trying to caution you not to expect too much from ABC as it is, or ABC as it can be while still resembling what ABC is today enough to be recognizable. If music notation schemes were vehicles, then ABC originally started out as something like a bicycle -- very cheap and easy to use but still able to get us to all sorts of interesting places as long as they are not too far away from home. Now since its original invention the ABC bike seems to have acquired all sorts of useful accessories (like a lamp, 21 gears, panniers, and a radio), but that doesn't mean that we will ever be able to use it to pull a 25-ton trailer -- not without losing the ability of carrying it down the basement stair for the night, anyway, and that may be something that many of its users aren't ready to give up. Do not say this is *not* the target of abc, there is no such thing as a restriction against display matters anywhere in the standard. Its *your* ideology about abc. For me abc is a way to create compressed, easily exchangeable, freeware, playback active representations of a musical source. Guess what -- with me it's just the same. However I've been around the block often enough to have found out that it is a good idea to keep the actual information and the details of its presentation quite separate. It is not as if this was just some stupid `ideology' -- it is sound engineering practice, founded on a large body of experience in designing similar systems, which is available to anyone who deigns to enter a good computer science research library. (In fact, an hour or two on the Web reading up on the philosophy behind XML should give one a reasonably good idea of what the data/presentation dichotomy is all about, without one actually having to bother moving one's lazy self away from the computer.) You appear to have this learning experience still ahead of you. I wish you well; may your epiphany not be too painful when it comes. As it will, eventually. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] What we call 'Progress' is the exchange of one nuisance for another nuisance. -- Henry Havelock Ellis To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Simon Wascher [EMAIL PROTECTED] writes: The problem is that there are situations where it is necessary to have part of the tempo indicator displayed and parts not. Example: Q:1/4=120 - Allegro % displaying Allegro and playing 1/4=120 In your proposal how can this be done ? Q:1/4=120 note=Allegro % and switch off display of metronome speeds Again: Whether or not a metronome marking is displayed should depend on a style setting within the notation program. It doesn't need to, and in fact shouldn't, be specified in the ABC standard. The ABC standard doesn't specify the font and point size of tune titles, either -- if I want to prepare a publication using ABC-notated music this is a stylistic decision on my part since I am designing the publication. Similarly, it is a stylistic decision on my part whether I want metronome markings or historical notes displayed with the music, or how far the staves should be from each other, or how wide the margins are, and so on. An ABC file should contain all the requisite information but should make as few stipulations as possible about what programs will actually do with that information. For example, in a book of traditional Scottish reels and jigs for dancing there is no need to include metronome speeds, since these are obvious to a SCD musician, but they can still be useful for a playback program. So you just set your notation program to suppress the `Q:' line metronome speeds. But the same ABC-notated tune could figure in a book of dance tunes from all over the world, and since it wouldn't be obvious to somebody who plays Scandinavian or Israeli dance music how fast a jig or reel should be played (or `Ivanica', for a Scottish musician), you will probably want to include metronome speeds after all. So you switch them on in your notation program. Why should you have to change the ABC-notated tune to control exactly what is being printed? supposed to do). We don't need special syntax for every single ABC header field when there is a general pattern that we can apply, like the `key=value' convention outlined above. Remember : the minus sign only is used in cases where something is *not* printed. so it is additional syntax, not alternative. Yes, but we don't put C:W. A. Mozart - if we don't want the composer to be printed. We tell the notation program to leave that field out. This makes your `Q:' syntax a special case. Unnecessary special cases are ... well, unnecessary. Anselm To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Laurie Griffiths [EMAIL PROTECTED] writes:
It's your turn to say what you find unacceptable in the proposal put forward
by me and Simon (the two were pretty much identical).
As far as I'm concerned, the main problem with these proposals is that
the syntax they define is pretty much particular to the `Q:' field. So
we get a `-' here and a mandatory space delimiter there, and in another
field, once we get around to discussing it, maybe a magic squiggle here
and a couple of dots there if that looks nice and useful. Now that the
ABC standard seems about to be extended in all sorts of directions we
should instead be aiming for a consistent style of syntax that allows us
to express these extensions. For example if we accept the `key=value'
style of options in fields such as `K:' or `V:' then we should define
extensions of the `Q:' or `L:' fields in a similar fashion, for
consistency, instead of giving these fields their own syntax because in
the short term that seems to be the easier choice and sufficient for
`everything that is needed'. (This is incidentally why I would prefer
something like `L:1/8 grace=1/32' to `L:1/8 {1/32}' as proposed in
Ewan Macpherson's message, even though it may be wordier in the short
term.) Chances are that it won't be. I have also tried to illustrate how
this approach lets us easily introduce further extensions in the future
-- something that is difficult to do if more ad-hoc stuff is heaped upon
the layers of ad-hoc stuff introduced in earlier rounds of updates --
but that doesn't seem to have got through.
The other issue is one that I have expounded upon several times already,
namely that the ABC standard should as far as possible stick to
expressing musical content, and leave presentation issues like what kind
of ancillary ABC information is and isn't printed where and in what
style to individual ABC-processing software, which is where it belongs
and how most of this material (such as titles, guitar chords and the
like) is already being treated. This is a very important distinction,
and for a famous and spectacular example of getting this wrong look at
HTML after Netscape and Microsoft were through with it. I would hate to
see the same thing happen to ABC.
Anselm
--
Anselm Lingnau .. [EMAIL PROTECTED]
I think there is a world market for about five computers.
-- Thomas J. Watson, CEO, IBM Corporation, 1947
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] blasphemy! A separate project...?
Simon Wascher [EMAIL PROTECTED] writes: I looked into my files, and found that the abc files I transcribed are a pile of about 3 MB (plain ASCII). Assuming that other peoples who are listed as large collections at the abc homepage also have big collections besides what is in the net right now we are talking of at least 60 MB of content (another approximation is to multiply the 14000 titles of the www abc index with an single tune size of about 20KB makes 280.000 KB ). I would say that much of this material is such that it can use the current ABC definition till kingdom comes -- `Celtic' folk music and other one-melody-line-plus-chords stuff. At least this applies to the several megabytes of ABC-notated music on my machine. It seems that therefore a great portion of that corpus will never have to be translated into another representation. If people do come up with a new notation that is better for multivoice music, complicated classical scores etc. then by all means use that for those kinds of music. I for one am quite happy with ABC the way it is because it fits my requirements pretty much perfectly (with some tweaking which could be made unnecessary without throwing all of ABC out the window). Any completely-new notation had better be as simple as ABC for my uses before I personally am going to jump ship. Mind you, I'm all in favour of updating the ABC standard but not if new functionality is invented wholesale. Let's try and bring the various implementations together and build from there. So if an entirely new syntax appears how will this syntax interprete this pile ? what are your solutions? will you write an all plattform automatic conversion tool and is it sure that no part of thecontent gets lost in this process? I'm sure something could be worked out. A conversion tool doesn't necessarily have to work on all platforms -- there could be a Web-based conversion service for those who cannot or will not run, e.g., Perl locally to convert their files. Anyway, if a backwards-incompatible version of the ABC language (rather than something entirely new and separate) is agreed upon then there should be a way of tagging new-style files so that ABC processing software can still work with both flavours without having to guess. We could do it XML-style so that the first line of a file (or tune?) reads %%ABC version=2.0 (and this would also be the natural place to put `encoding=utf-8' and such-like if desired). Anselm To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: what should be content of abc files, was: Re: [abcusers] something really simple
Simon Wascher [EMAIL PROTECTED] writes: It is not trivial to tell where music ends and side information beginns. And as a transcriber of historical sources it is often very important to cover some side information within the exchangeable file, not just in the printed output (for file exchange). This non musical information does influence the musicans output and therefore is in a way part of the music. Abc formatting would be worthless to transcribers if it is limited to pure audible phaenonenons. Nobody says that ABC should be limited to `pure audible phenomena'. We do have repeat signs and so on which are not audible (at least not in a direct sense). However we should not try to define the meaning of the ABC notation in terms of playback and notation programs, but in terms of the musical ideas which are being transported. Saying in the standard that various bits of such-and-such a field must be displayed in such-and-such a way is a bad idea -- it is much better to say that the field *means* this-and-so in musical terms and leave it to the software authors to figure out what to do with that piece of information. This means that the information is all there in the file for anybody to look at it, but that the authors of ABC processing software have maximum flexibility to make use of it (or not). There is absolutely no need to clutter up an ABC tune with special notation that says whether `1/4=120' must be printed with a little quarter note or `1/4' or not at all, or to the top left or bottom right of the music or whatever, when it is a lot easier to put options like `PrintMetronomeMarking: true' in an ABC notation program's format file, or `--print-metronome-marking' on the command line, or a check box in an interactive dialog or whatever. As far as your `side information' is concerned that should only show up in the exchangeable file, not in the printed output: The ABC does provide the notion of `comments', i.e., lines that start with a `%'. I understand that you are not interested in these aspects of music notation, and I can tell you that I am working hard that you will never come accross those features you do not need, simply do not use them and never read the readme file description on those features. I am very much concerned that simple abc remains simple but in the same time please accept that other people do expand features you never heard of and never will use. Please don't second-guess me. I'm quite interested in seeing the ABC standard develop and improve, thank you very much. However we should try and avoid the mistakes that others have made, such as deliberately mixing presentation and content, and we should try to keep the notation as simple as possible. This is why I am in favour of Jack's proposal for tempo macros, and also why I like Phil Taylor's macro mechanism for decorations much more than the idea of inventing two hundred little special symbols within the ABC language just so the urtext of Bach's inventions can be represented in ABC. I am not prepared to accept the idea that the ABC language needs to be cluttered up, say, with magical end-of-line comments that have special meanings in some header fields just so something can be expressed which nobody really actually needs to begin with. Anselm To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Simon Wascher [EMAIL PROTECTED] writes: Example X:1 Q:n/n=n N/N=N andante will playback n/n=n and display N/N=N andante so if a numeral tempo indicator is on the very beginning of such a string it must be written a second time for the display. If no tempo indicator should be displayed but a playback tempo set this can be done using a - after the numeral tempo indicator. I think this is much too complicated. I'm still waiting for you (or anybody) to explain why an ABC tune should contain one prescribed explicit metronome speed for display and another, different, prescribed explicit metronome speed for playback, and why this would be preferable to letting users set their own playback speeds `ad hoc', external to the ABC representation, with the ABC-provided speed as a (reasonable) default. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Python is a truly wonderful language. When somebody comes up with a good idea it takes about 1 minute and five lines to program something that almost does what you want. Then it takes only an hour to extend the script to 300 lines, after which it still does almost what you want. -- Jack Jansen (1992) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Laurie Griffiths [EMAIL PROTECTED] writes: No!! I am very much against this. Although it may be convenient for writers of ABC it's horrid for readers. It makles it even harder to extract a tune and the probability would be very high that we should find orphan bits of ABC floating round with macros used but not defined. It's not as bad as all that. In the case of tempo specifications, a player program could always fall back to a list of standard speeds (like the ones given on a honest-to-goodness wind-up metronome) while outputting a warning to its user that the tempo specification is undefined. Notation programs are likely to output just the macro `name', anyway (like `Allegro'), so it doesn't really matter whether there is a speed associated with it or not. The nice thing about Jack's original proposal (which the silly discussion on `display' vs. `playback' speeds has managed to obscure quite thoroughly) is that it abstracts musical information (like `Allegro') from presentation issues and/or matters of taste/convention (like `1/4=120'). If implemented, it would, among other things, make it possible to control the tempo of a bunch of tunes without having to change the `Q:' line for every single one, which I find quite appealing. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] I think there is a world market for about five computers. -- Thomas J. Watson, CEO, IBM Corporation, 1947 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
Simon Wascher [EMAIL PROTECTED] writes: Lets say you are right, its completely impossible that someone needs that. I'm not claiming that it is impossible for anybody to need this. But if this is a sensible proposal then surely there must be an example of an application that requires it? Obviously if there isn't an actual requirement for this notation (other than `Simon says so') there is no need to clutter up the standard with it. So why bother about its syntax if you cannot imagine someone may need it? I do bother about the proposed syntax because I want the ABC standard to stay as simple and straightforward as possible (while still being as expressive as is reasonable). If this means we have to think more and harder instead of catering for every whim at a moment's notice then `tough'. The counter-proposal stands: Q:1/4=120% [1] explicit tempo specification Q:1/4=120 note=Pretty quickly % [2] explicit tempo with advisory note Q:Allegro% [3] symbolic tempo specification, metronome % speed (or range) defined elsewhere Q:Allegro note=Pretty quickly % [4] symbolic tempo with advisory note Q:Allegro 1/4=120% [5] definition of symbolic tempo Q:Allegro 1/4=120-128% [6] definition of range and it is up to individual notation programs how they will display these bits of information, while player programs should default to the metronome speeds that are specified either explicitly in the tune or, in the case of symbolic tempo specifications, elsewhere, while giving users the chance to override the speed if they want. Suggestions for tempo display by notation programs: [1] .|=120 [2] Pretty quickly - .|=120 [3] Allegro Allegro - .|=120 % if desired, and if `Allegro' is defined accordingly [4] Allegro (Pretty quickly) Allegro (Pretty quickly) - .|=120 [5] and [6] will not be displayed. Notation programs could also offer to display just metronome speeds or just advisory notes, or to suppress metronome speeds or advisory notes altogether. The `note=...' construction may seem wordy but in fact it is consistent with similar notation elsewhere in (de-facto) ABC such as the `V:' and `K:' fields. This is a lot better than inventing ad-hoc syntax for every single field, such as the `Q:n/n=n - Andante' proposal seen earlier on. In fact at some point in the future it could allow us to say something like ... some music ... Q:1/4=120 mode=accelerando ... more music ... Q:1/4=140 ... even more music ... to express a dynamic change of speed between two points in time. This falls naturally out of the `key=value' syntax, while in your proposal one would have to invent even more ad-hoc syntax on top of what is already there to allow this. It is neccesary to encounter the edges of a choosen syntax to be able if it is stringent, search deeply for the worst cases it produces. This is how a syntax is developed. Every syntax has its dark corners and all we can do is turn the pockets around till we find the least important corner in our proposal to contain the blackest hole of our syntax. So here it is: Q:n/n=n N/N=N andante, dark and sinister but without any meaning in real life. I disagree. To apply some wisdom that I think goes back to Antoine de St. Exupéry, a common fallacy in language design is to consider a language complete when there is nothing left to add. (This leads us to abominations like C++.) In fact, a design is usually much better when there is nothing left to take away (and it still does what it is supposed to do). We don't need special syntax for every single ABC header field when there is a general pattern that we can apply, like the `key=value' convention outlined above. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] When the gods wish to punish us they answer our prayers. -- Oscar Wilde, *An Ideal Husband* To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE: ABC transcrivers ID
Simon Wascher [EMAIL PROTECTED] writes: I think its quite clear that it is impossible to enforce whatever numbering scheme to all abc format users, so the only question is if we can find a solution that is based on an agreement of a large number of abc collection owners (and programmers) an so reasonable and open that others join it because they find the agreement sensible. Yes. It could be something like the identification system in librarys, probably made up the same way (are there librarians out there ?). I think the `tune/transcription ID' should be similar in spirit philosophically to the `message ID' found on e-mail messages and Usenet postings. That is, it shouldn't a priori try to `classify' the tune according to some set of criteria (which we will never be able to get a consensus on), but be merely a globally unique identifier. My view would be that the most sensible approach for this would be using URNs (or Uniform Resource Names), which are basically like WWW-style URLs but don't specify *where* a certain resource is to be found. For example, we could agree on a syntax like urn:abc-id:collection:collection-dependent-part like, for example, urn:abc-id:skye-coll:miller_of_drone There would have to be a registry for collections to ensure that the collection names remain globally unique; of course a collection would not have to refer to an actual published volume of tunes, but we could have urn:abc-id:campin:... and so on, where each owner of a collection would be free to make up their collection-dependent-parts (within the confines of URN syntax). This could of course contain an informal classification. The nice thing about this approach is that as URN usage becomes more widespread there could be a `resolving service' accessible to WWW browsers and such that would map abc-id URNs to actual URLs where the resource (i.e., tune) could be found. Of course use of this would not be mandatory; indeed it would not be mandatory for tunes to be actually available on-line. If this idea catches on we should try and get a URN namespace registered with the IANA. And the main problem will still not be solved, that nobody can stop people from stripping off all this usefull information when copying the source. Besides this there is a big problem with altered files in general: If I change the apperance of the abc text - like I do it regulary - whose file is it then, if I correct or alter the abc text - the music - what happens then ? This is difficult to get right. There could be various transformations of an ABC text that would change the bytes of the text but would leave the musical contents as well as the `meta-data' (the title, composer and so on) unchanged. In my opinion, if somebody assigns an URN to a piece of ABC text that means that he or she `signed off' on it as it stands, and that it should be passed on either verbatim or without that URN. If a piece of ABC text is changed then the URN of the `original' could be preserved in a header line. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Dost thou love life? Then do not squander time; for that's the stuff life is made of. -- Benjamin Franklin To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] German H as an alternative to B
W.Dietz [EMAIL PROTECTED] writes: - Abc is intended to be a international language. Tune notations with H and the German flag can not be understood by not-Germans. At least not by the major part of those who aren't interested in german specialties. Abc is already complex enough. Please no further confusions. - I guess a good part of the German-speaking musicians had to learn the interational B anyway. At least when dealing with chords. Personally I remember my Beatles song book.And provided you aren't playing weird jazz, the meaning of a B chord (B or Bb) always gets obvious out of the cont ext. I thoroughly agree with this. Allowing German-style note input in ABC would be much more trouble than it is worth (IMHO). I can see the problem about chords, but this is something that can easily be fixed using a preprocessor (the chord extraction script that I posted some time ago would probably be a starting point). The ABC language is fragmented enough as it is. We should work towards simplifying and standardizing things rather than inventing new complications. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] I think that's how Chicago got started. A bunch of people in New York said, `Gee, I'm enjoying the crime and the poverty, but it just isn't cold enough. Let's go west.' -- Richard Jeni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] German H as an alternative to B
John Chambers [EMAIL PROTECTED] writes: Well, I was wondering how long it would take for some German and/or Scandinavian musicians to suggest this. It didn't take long for one of each to speak up. The point comes across far better when people from that tradition call the H notation an error and idiocy. When we outsiders criticise it, our criticism can easily be taken as some sort of cultural chauvinism, but when insiders say the same thing, it becomes a lot harder to justify using such notation. Actually I've been playing off English-style music notation (with `B' in place of `H') so much that I find it thoroughly disconcerting to actually encounter music that says `H'. In fact all the German SCD musicians I know use `B' for `H' in their own arrangements and compositions for the sake of consistency. I for one will not shed a single tear if ABC is kept completely `English' in that respect. In fact I'm strongly in favour of the idea. I don't know where the `H' abomination came in but I'm quite happy to call it an error and idiocy, for the record. I do have a German passport. But it would be even better to take the opportunity to put a bit more pressure to eliminate this bad notation entirely. A lot of Germans and Scandinavians would thank us. Well, I don't think the ABC user community is quite ready yet to put that kind of pressure on the music scene at large ... :^) Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] A man should never be ashamed to own he has been in the wrong, which is but saying, in other words, that he is wiser today than he was yesterday. -- Alexander Pope To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcmac - BarFly-style abc macro preprocessor in Perl
[EMAIL PROTECTED] (Phil Taylor) writes: I'm confused now. Suppose I had definitions for `Mn' and `Mn2'. What would happen (a) for `Mc' (b) for `Mc2' (c) for `Mc4' in the body of a tune? The interesting point is whether the `n' includes a length or not. (a) and (b) will expand, (c) will not, since there is no macro definition for that length. 'n' does not itself include the length, but the length (if any) is part of the target string. So in (a) and (b) the replacement of `n' is `c', and any length specifications are taken from the right-hand side of the macro definition (the `target string', if I understand you correctly). This is what my current implementation does (phew). Actually, thinking about this some more, it would be possible to sort the macro definitions into order before expanding them, provided that you used a sort algorithm which is guaranteed not to change the order of elements which are the same size. Since the list of macros to be expanded is never going to be very big you could just use a simple bubble sort. It's no problem simply to do the replacements in reverse order of occurrence. Actually it simplifies my code considerably. The sorting business came in because my very first version processed the replacements in order of occurrence (rather than reverse order), which obviously didn't work with Jack's example, which was all that I had to go on at the time. I didn't know about the reverse-order constraint until later, and I'm perfectly happy with it if you are. As I said, the version on my web page does the reverse-order thing already. Us Mac users don't have a lot of fun with perl. Every time I try to use it I end up concluding that it would be quicker to write a program in C or Pascal to do the job. Yes, but you Mac users have BarFly to begin with. I could have coded the macro preprocessor in C (no Pascal, please ...) but it would have taken me a lot longer than the two hours or so that I have spent on it so far. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] The problem is the browser bosses spend way too long listening to the young sprouts in suits in the marketing departments who can barely add 2+2 instead of listening to real users. -- Peter Flynn, on math support in Web browsers To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcmac - BarFly-style abc macro preprocessor in Perl
Phil Taylor wrote: BarFly's macro processor does take lengths. You have to write a separate macro for each length of note. The reason for this is that an ornament which sounds right on a half note is often wrong on an eighth. I'm confused now. Suppose I had definitions for `Mn' and `Mn2'. What would happen (a) for `Mc' (b) for `Mc2' (c) for `Mc4' in the body of a tune? The interesting point is whether the `n' includes a length or not. What the current Barfly version does when it encounters a macro on a note with an accidental is to place the accidental on the first ocurrence of the principal note in the expansion. [...] BarFly doesn't do this; rather it expands the macros in reverse order to the order in which the definitions are listed. I've put a version of abcmac which is fixed in these two respects on my web page at `http://anselm.our-isp.org/abcmac/abcmac'. Maybe we can get abc2midi to process the Goldberg Variations? We could try ... Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls.-- M. Cartmill To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC in an internet cafe
Jack Campin [EMAIL PROTECTED] writes: One piece of file-context-dependence that I am likely to introduce on my site fairly soon is BarFly macros. [...] but there seems to be no interest as yet from the Unix camp. I'd rather get the ABC right first and wait for the programmers to catch up. We don't really have to wait for the programmers to catch up. If I understand BarFly macros correctly, they're simply bits of text that get replaced by other bits of text. If we're suitably desperate, writing a simple preprocessor to do that shouldn't take more than a Perl interpreter and a rainy afternoon, and it will basically macro-enable all Unix-based abc tools at the cost of a minor inconvenience. The programs themselves can be fixed in due course once the idea is firmly established (and properly documented?). If someone (Phil?) sends me a detailed description of what BarFly macros do and how they are defined in BarFly abc files I'd be happy to give it a try on the next rainy afternoon. (Right now it is sunny outside and going on 30°C.) As of now I'm not really desperate but it looks like a fun little project that might be useful to someone. And I'm always on the lookout for free beer when I'm travelling :^) Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Calm down. It's only ones and zeros. -- Sam Kass To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] abcmac - BarFly-style abc macro preprocessor in Perl
All right, everybody, please forget the simple-minded piece of junk I
posted recently, which suffered from the delusion of being a BarFly
macro preprocessor. As far as I am concerned here comes the Real Thing,
based on Phil Taylor's description of BarFly macros (I hope it does
everything right). This works at least for Phil's examples (and Jack's
tune, too). Suggestions on how to improve the `transpose this note 5
steps up' code are welcome :^)
Please let me know if you find this useful, would like to see bug fixes,
changes and/or improvements, and so on. I'll give the program a more
permanent home on my web site if there is sufficient interest.
Cheers,
Anselm
--
Anselm Lingnau .. [EMAIL PROTECTED]
There is only one basic human right, the right to do as you damn well please.
And with it comes the only basic human duty, the duty to take the consequences.
-- P. J. O'Rourke
#!/usr/bin/perl
# abcmac -- Barfly-style macro preprocessor for ABC files.
#
# Copyright © 2001 Anselm Lingnau [EMAIL PROTECTED]. Use this as you
# like as long as you don't alter or remove this comment or pretend that
# you wrote it yourself.
#
# See http://www.barfly.dial.pipex.com/bfextensions.html for a description
# of BarFly macros.
use strict;
# This defines what a macro takes as an argument.
# Currently the argument is a note name (no length).
my $arg = q{[\^=_]?[A-Ga-g](,*|\'*)};
my $subst;
my (@m, @global_m);
my $xnotes = 'hijklmnopqrstuvwxyz';
my $n_pos = index($xnotes, 'n');
my @tnotes =
qw/C,,, D,,, E,,, F,,, G,,, A,,, B,,, C,, D,, E,, F,, G,, A,, B,,
C, D, E, F, G, A, BCDEFGAB
cdefgabc' d' e' f' g' a' b'
c'' d'' e'' f'' g'' a'' b'' c''' d''' e''' f''' g''' a''' b'''/;
my ($i, $tnotes_max) = (0, scalar(@tnotes));
my %pos;
foreach (@tnotes) { $pos{$_} = $i++; };
# Transpose note `$base' according to the relative position of `$note'
# compared to `n' -- e.g., $base = 'A', $note = 'o' gives 'B'. Don't bother
# dealing with accidentals, since BarFly doesn't either.
sub transpose {
my ($base, $note) = @_;
my ($steps) = index($xnotes, $note) - $n_pos;
my ($new_note) = $pos{$base} + $steps;
die transposed note out of range
if $new_note 0 || $new_note = $tnotes_max;
return $tnotes[$new_note];
}
# Main loop.
my ($global) = 1;
while () {
if (/^([A-Za-z]):/) { # header line
if ($1 eq 'm') {# macro definition
my $def = $_;
$def =~ s/\s*%.*$//;
if ($global) { # Remember global macros separately
push @global_m, $def;
} else {
push @m, $def;
}
} elsif ($1 eq 'K') { # last line in header
my @subst = ();
# Construct a sequence of expansion commands for the macros.
# Make sure to expand longer-named macros first, to avoid
# replacing `On' before `On/'
foreach my $macro (@m) {
my ($name, $value)
= $macro =~ /m:\s*(\S+)\s*=\s*(.*)\s*$/;
my $name_len = length $name;
my $transposing;
if ($transposing = $name =~ s/n/($arg)/) {
$value =~ s/([h-z])/.transpose(\$1,'$1')./g;
$value = qq{$value};
push @subst, [$name_len,
qq{s\x01$name\x01$value\x01ge;\n}];
} else {
push @subst, [$name_len, qq{s\x01$name\x01$value\x01g;\n}];
}
}
foreach my $s (sort { $$b[0] = $$a[0] } @subst) {
$subst .= $$s[1];
}
# print - x 72, \n, $subst, - x 72, \n;
} elsif ($1 eq 'X') { # First tune starts here.
$global = 0;
}
print; # This prints »m:« lines as well - should it?
} elsif (/^$/) {# End of tune; forget non-global macros
@m = @global_m;
} elsif (!/^%/) { # non-comment line -- expand macros
chomp;
my $out = '';
while (length $_) {
if (s/^(.*?)//) { # leave stuff in quotes alone
$out .= $1;
} else {# look for macro calls to preprocess
my $v;
s/^([^\]*)//;
for ($v = $1) { eval $subst; warn $@ if $@; $out .= $_; }
}
}
print $out, \n;
} else {
print;
}
}
Re: [abcusers] linux only ?
Gianni Cunich [EMAIL PROTECTED] writes: Given this, If I really wish to use a flexible, user friendly notation package, like Melody Assistant (another software I am satisfied I have registered) or the NoteWorthy Composer, that's the rule...one tune = one file. To store a whole tune book you have to use a typesetting package... yet, none of those currently avalable really supports the abc notation except for the all too limited original standard Too bad. I use abc2ps (which does support multivoice music, for example) to create EPS files which I can include in my LaTeX documents just fine. In fact, I'm typesetting Scottish country dance books which look every bit as nice, if not nicer (if I say so myself) than most of what is on the market. See http://www.tm.informatik.uni-frankfurt.de/~lingnau/pmbook/ for an example (and yes, it would be possible to put all the ABC notation for the tunes in that book in a single ABC file and typeset it from there). I do keep every tune in its own file but even so this approach is far superior to the point-and-click packages on the market, since the music formatting is governed by a single parameter file which is common to all the ABCs. If I do change parameters like the staff width or distance, all I need to do is start a `make' run and go to the kitchen for a drink. When I come back the whole book is re-done with the new settings. I don't have to go through every single file by hand, which is a great time-saver. Finally, yes again, Zel is only available for Windows. What a pity! Yet a number of abc related softwares are available for other platforms only, but nobody did seem to care about it so far... Most of the important programs like abc2ps or abcMIDI can be gotten to run on most any platform that supports a C compiler. The worst that can happen to you is that you have to try and find somebody to compile the software for you. P.S: BTW, I was told that quality, and not quantity, is what actually matters... anybody wish to argue about the quantity of relevant/vital informations about the musical stuff uploaded on the web has got lost because of the quite_but_not_really_yet_updated abc standard compliance? Or, to say better, about what this means in terms of quality? There is hardly any sense in telling that a midi file is a rather poor exchange musical medium when what we have to compare with it doesn't even supply any universally agreed symbol for a mordent or a fermata! ABC was originally intended for a type of music where mordents or fermatas aren't usually notated at all, since every musician will put in their own decorations anyway. It turns out that most of the music available on the web in ABC format (which incidentally *is* rather a lot, most of which is quite useful, thank you very much) is of that genre, so not having any universally agreed symbols for those doesn't really hurt the `quality' of the material all that much. This is of course not to say that it wouldn't be nice to have agreement, but apparently if it was a big important issue we would have standardised on something long ago. Incidentally, MIDI files are a lousy medium for exchanging notation because among other things they don't have the notion of a bracketed repeat, which again for the type of music ABC excels at representing would be a major drawback. They may be nice for exchanging musical arrangements that you can play on your synth if you never do intend to go back to sheet music, but claiming that a text format geared towards MIDI generation is better than one meant for representing sheet music is comparing apples to oranges. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] I sometimes wonder if Microsoft keeps beating this application-OS-lovefest drum because they really have no idea how to write an OS API, so they just do whatever their apps people ask for and call it one. -- Peter da Silva To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc2ps under debian GNU/Linux
D-Man [EMAIL PROTECTED] writes: I used it. Thanks for the great package! The only problem I had was the output was only for A4 paper, but my printer has letter paper. This should be easy to fix with an appropriate format file. There are examples and explanations in /usr/share/doc/abc2ps. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Maybe this world is another planet's Hell. -- Aldous Huxley To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc2ps under debian GNU/Linux
Frank Nordberg [EMAIL PROTECTED] writes: I maintain the Debian abc2ps package ... Is there an URL I should have added to the abc applications database here? I don't know. Debian GNU/Linux users will find it on their CDs or in the obvious places on the Debian net servers (and if you're online and have your system set up correctly `apt-get install abc2ps' is all you're going to have to say to obtain the current version), and the package is probably not much use to others. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] A lawyer without history or literature is a mechanic, a mere working mason; if he possesses some knowledge of these, he may venture to call himself an architect. -- Sir Walter Scott, *Guy Mannering* To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc2ps under debian GNU/Linux
Nathan Weston [EMAIL PROTECTED] writes: Has anyone been able to get abc2ps working under debian? I had it working fine under redhat 7, but I am trying to switch to debian, and it appears to be producing bad pdf files. Have you tried the abc2ps package which is part of the Debian GNU/Linux distribution, or have you compiled your own source code? I maintain the Debian abc2ps package and would be interested in working with you to get any bugs in that package ironed out. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Portability is for people who cannot write new programs :-) -- Linus Torvalds To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Useful mistakes
In article [EMAIL PROTECTED], John Chambers [EMAIL PROTECTED] wrote: So what we maybe need in the new standard is a clear statement that P: may be used to apply arbitrary text to major sections of the music. The P: text is to be put at the left edge of the page by formatters (and presumably ignored by most other software, though players might display it as the section is played). I'm with you on this, John (SCD musicians unite!). Please could the P: purists suggest another way of putting tune titles in a medley if they don't want us to use P:. Anselm -- Anselm Lingnau . [EMAIL PROTECTED] I sometimes wonder if Microsoft keeps beating this application-OS-lovefest drum because they really have no idea how to write an OS API, so they just do whatever their apps people ask for and call it one. -- Peter da Silva To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] validation the ABC corpus
In article [EMAIL PROTECTED], Richard L Walker [EMAIL PROTECTED] wrote: Is anyone aware of any abc collections of tunes used for International Folk Dancing? John Chambers has a fair amount of stuff on his site but you have to piece it together for yourself. Anselm -- Anselm Lingnau . [EMAIL PROTECTED] And the fact is, all computer languages are imperative underneath. Some just hide it better than others. Computers are not yet smart enough to admire a good definition. -- Larry Wall To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Modes, democracy and benevolent(?) dictatorship
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Of course, this does run contrary to the other common approach, which might be summarized "If the ABC has even a tiny error, you should reject it, lest people be encouraged to keep making errors." The consequence of this is to support a »loose mode« as well as a »picky mode«. You use loose mode for stuff that comes in from elsewhere that doesn't pass in picky mode, and picky mode for stuff that you are going to send out that you want to be 100% conforming to the standard (or whatever). Anselm -- Anselm Lingnau . [EMAIL PROTECTED] Giving money and power to government is like giving whiskey and car keys to teenage boys. -- P. J. O'Rourke To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Software for extracting chords
In article [EMAIL PROTECTED], Frank Nordberg [EMAIL PROTECTED] wrote: The only thing Robert asked for that this seems to be missing, is the | | notation for bars without a chord symbol, and if you ask me that's just as well. This is actually in there but the source file doesn't trigger it. Try removing a chord from a single-chord bar and you should see it. If I were making this into a real program I would probably put in an option to control whether it is done. Ar you going to make this available on the web btw? I don't think it is all that exciting but I might. If anybody else wants to adopt this feel free -- it's only a 15-minute hack after all. Anselm -- Anselm Lingnau . [EMAIL PROTECTED] Listen, appliance manufacturers: We don't NEED a dishwasher that we can communicate with from afar. If you want to improve our dishwashers, give us one that senses when people leave dirty dishes on the kitchen counter, and shouts at them: "PUT THOSE DISHES IN THE DISHWASHER RIGHT NOW OR I'LL LEAK ALL OVER YOUR SHOES!" -- Dave Barry, *In a battle of wits with kitchen appliances* To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
