Re: [abcusers] this tune intentionally left blank
Em Seg 07 Jun 2004 20:12, Richard Walker escreveu: There are keys like X:, T:, C:, N:, K:, etc. for everything except the body of the tune. Is there a left over symbol that could precede the body of a tune? ... or with the huge collection of abc tunes that already exists, is it simply best to write a program to do the check? No need for that. The body always begins just after the first K: field and is over at the first blank line. So, a first K: field immediately followed by a blank line means an empty (by default) body. -- Paulo Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] this tune intentionally left blank
Em Qua 02 Jun 2004 14:26, Phil Taylor escreveu: Interesting. If you look at the html source for the first tune in that file it looks like this: p class=MsoNormal style='margin-right:.5in;tab-stops:.6in 1.1in 1.6in 2.1in 2.6in 3.1in 3.6in 4.1in 4.6in 5.1in 5.6in'span lang=EN-GB style='mso-ansi-language:EN-GB'Xspan class=GramE:1/spano:p/o:p/span/p [snip] It's a long way from abc. I suspect it's actually microsoftml, and probably written in MS Word. Surely is, with all that redundance in the 'mso' style tags. You see, this garbage is intended to solve MS Office's problems of interoperability, not to produce anything convenient or suitable for the Web. (In fact, if you check the source code for the page, you can see a META element saying it was generated by Microsoft Word 10.) The right way to HTMLize it would be something like pre class=music abcnotation title=ABC notation of A. A. Cameron's Strathspey in A Mix code X:1 T:A. A. Cameron's M:4/4 L:1/8 R:Strathspey K:A Mix |:eA3 A4 B3Gd3B|eA3 A4 d3g (3f2e2d2|eA3 A4 B3Gd3B| % And so on ... /code /pre (Of course, you'd have to substitute amp; lt; and gt; for any and characters respectively in the source. Defining presentation of the ABC segment would be simply a matter of defining a style for a CODE element which is a child of a PRE element with classes 'music' and 'abcnotation' set. It would also be straightforward to parse.) Maybe the standard should state (or at least recommend) how ABC source code should be embedded in HTML/XML. -- Paulo Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] this tune intentionally left blank
Em Qua 02 Jun 2004 12:47, John Chambers escreveu: Jack Campin writes: [snip] | The problem is how best to say this. | There is a list of headers that could contain a code for no | notes. This field already uses a double quote to indicate that | accompaniment chords are present. I wonder if there's a good | single char that could stand for notes, or maybe for no | notes? Perhaps '*' (asterisk) could be used for this, as it | doesn't seem to have any other use, and it is conventionally | used to indicate an explanatory footnote. | | That sounds pretty good. Maybe I'll try implementing it. I don't think that would be a good idea. IMHO any characters that might still be available should be reserved to signal new, more productive contexts. The no notes context can be easily be indicated by a pseudocomment as long as a standard one be agreed upon. E.g. %% End of tune or %% No notes or %% End of X:tune identifier Of course, this would be just a redundant way of telling parsers that the transcriber _hasn't_ made the mistake of signaling the end of tune prematurely. -- Paulo Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Gregorian chant in abc
Phil Taylor wrote: Paulo Eleutério Tibúrcio wrote: [skip] I'm in need of some to encode Gregorian Chant, for instance, and I think I'll have to add more variety to the already existent for that). Have you looked at http://www.barfly.dial.pipex.com/bfgregorian.html)? This scheme is followed by BarFly and by Melody/Harmony assistant, and involves minimal changes to allow abc to represent Gregorian Chant. (Basically, it's just an addition to the K: field to specify which of the eight possible clefs is in use, and some reinterpretation of the standard abc symbols when a Gregorian clef is specified.) Thanks for the link, it's a good starting point. I tried to check your references on the page ( http://www.netaxs.com/~rmk/Chant/index.html and http://home.mcn.net/~relbooks/gf_salve.gif ), but they seem to be gone. I'm a member of the Coral Gregoriano de Belo Horizonte (Minas Gerais, Brazil - http://www.gregoriano.org.br ), maintained by the Father Nereu de Castro Teixeira Cultural Society where I've been a student of Gregorian Chant for the past seven years. We follow the school of Abbaye Saint-Pierre de Solesmes, whose aim is to restore the performance of the pieces as close as possible to the original medieval interpretation based on the study of the paleographic manuscripts. Their findings have been gradually incorporated to the typesetting of the Church's official GC books in square notation; some of these also carry the paleography for the pieces (e.g., the _Graduale Triplex_). As our repertoire is in the official chant books (available), typesetting them for the choir is not the issue. But we offer courses in Gregorian Chant, and production of handouts mixes typesetting the words and calculating white space to add the musical samples to a paper copy, so the document can't be computer-stored as a whole. The requirements I am trying to meet are the following: 1. A typesetting style compatible with those of the past 50 years, making possible as close a representation as possible of one or other printed version so the samples in the handout matches what the student will find in the official chant book available; 2. A typesetting for the paleographical notation, at least for the neumatic signs of Saint-Gall; 3. Automated audio rendering of the notation in MIDI (including as much of the semiological tokens as feasible) as a learning aid; 4. And, of course, typesetting in modern notation according to the the conventions usually followed by the Church books (useful for studying GC choir conduction and for typesetting pieces for occasions when a large group of non-gregorian singers are expected to join in). To me, abc matches Gregorian Chant in simplicity, so it is a better candidate for creating sources than an entirely new system I might design; also it is an open format, so GC coded in abc would be accessible to a large community. Then, the problem I face is to represent GC in abc so as to meet my needs and at the same time keeping the code fairly readable by existing pieces of software. Some of the solutions you designed for BarFly are good; others are likely to comply with one style of singing while excluding others (e.g., repeated pitches on the same syllable, which you tie up for one long note as in some schools, should be, according to Solesmes, sang as as many repeated notes, i.e., as written). I like the way you indicate liquescence; that was one problem I was still trying to solve. Also I like the S and Q in the beginning of the new melodic fragment (I was using !shortphrase! and the like, but these are required to be attached to the last note of the previous fragment, which I find distracting). Now, to represent all that information in abc would require a lot of extensions and the notation might get a little cluttered. I'd like to make the source readable and easily editable (that's the reason I've chosen abc, in the first place; SGML/XML might be usable, but would make code more complex to edit by hand). Maybe I'll have to think of splitting the information among several layers (as abc does for lyrics). More ideas are welcome. (BTW, when you talk about the horizontal episemata (K in BarFly), you seem to imply that they always apply to the whole block of notes that follow. Well, they don't always; in fact, almost any note in a group may be episematic, i.e., the episema is a feature of the note to which it is attached, applying to the next only in specific cases. Also you shouldn't miss a horizontal episema in the modern notation, as it generally indicates that the note is to be slightly hold or to receive some expression or emphasis; not so for the vertical episema, because while the former is represented in the manuscripts, the latter was introduced in the modern square notation as an aid to rhythm and is under revision.) Thanks again. Paulo E. Tibúrcio To subscribe/unsubscribe, point your browser
Re: [abcusers] Musicians and techies
John Chambers wrote: Kurt wrote: | On 30-Jan-2003 John Chambers wrote: | | ...The Internet can't be killed, but there is | still a chance that it can be made illegal for you and me to put our | own stuff online. If they can do this, they can then force us to sign | over our rights to our own stuff to get it online, and they'll be | back in the saddle. | | I followed you this far. But are there any laws or technical proposals being | made right now that would make it impossible to put your own stuff online? Or ... Well, here in the USA, a lot of ISPs have licenses that include a no servers rule. They generally aren't well enforced, but they can kick you off if you have any program listening on any port. [skip lots] In most of the country, the local ISP is a monopoly. If you don't like them, well, you don't have to have internet service, now do you? [skip] (And note that if you put your own recordings online on an ISP's machine, you may be handing over the copyright to the ISP.) This hemisphere things are not different. When I signed up with my then (really) local ISP I was told I had an amount of disk space for a personal home page and that what I put there was up to me. The ISP has, since then, been sold to foreign corporations twice before I could set up my HP, and the deal on that matter has changed. In short, a lot of what I would want to put on the net would violate the terms. Then what? Let's look for a free space provider! So far, if I publish anything via their servers, I am surrendering all my author rights and I would still be subject to the aforementioned limitations. Our problem: we have laws that state very clearly what terms the seller imposes when you by a, say, TV set that might be considered abusive; still we have no such regulations regarding ISP omnipotence. ISPs and other corporations are lobbying for their interests; Brazilian copyright law has recently been changed to comply with transnational CD, book, software and what-have-you industry exploitation and that is what they are modelling: the idea is to turn your computer screen into a better resolution extension of a TV receiver. Awkwardly, some judge has recently issued a sentence that withdraws the requirement of someone being a licenced journalist (legal here so far) to write on the press; nevertheless, ISPs still rule when it comes to write on the net. Paulo E. Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc in web pages
Karl Dallas wrote: No I'm a Human Shield volunteer. God bless you and keep you. Karl Dallas wrote: So if I understand what you're saying about option 1: I display the abc code (of a file called tune.abc) as text but if the user clicks on it, instead of hearing proper abc, what they actually hear is tune.mid. Seems a bit like cheating, but I suppose it'd work (and MIDI's not all that bloated, compared with WAV or even MP3 or WMA). Really it's not cheating. abc is neither a playing nor a display encoding system, but a descriptive encoding system. It so happens that nowadays computers have systems available designed to specifically encode information meant to be played (MIDI, Wave a.s.o.) or viewed/printed (PostScript, TeX) while abc, originally meant to communicate melodic information via ASCII-only-reliable media, has been extended so as to generate some kind of output or other (right now, I am planning yet another byproduct I need). Chris commented: [skip lots] 3. Send the ABC to the client and have it converted there. This only works if the client has conversion software installed and has their browser configured correctly, which is only feasible for a small crowd who can coordinate their software. It can't be made to work for a general public site. [skip] I've worked on a few projects that use approach 3. But there are some major problems with this. One is that no sensible user will permit downloaded code from a web site to run automatically on their machine. This is how you get things like the email viruses that are the plague of the Microsoft portion of the Net. [skip lots] I am selective about plugins myself. I get especially irritated with some promissing ones that simply cease to read code they usually did if you don't upgrade to whatever NEW!!! version they release every six or four months (each one generally 50% bigger in HD space requirements). However, some users might like a seamless integration of the rendering application with the browser and that means a plugin if the browser doesn't have built-in support (I think they'll hardly ever have for abc) or if the other options (server-side execution, pluriformat storage) don't apply. Netscape has a section on NS plugin writing at http://developer.netscape.com/docs/manuals/communicator/plugin/index.htm Those plugins might work with other browsers (Opera [http://opera.com], for instance, according to their documentation). Anyway, I think such a plugin would be of limited usability, as abc is a very loose standard (remember, it was conceived for human consumption with processed output as a byproduct) and a lot of the files available on the net use encoding features that do the task but must rely on specific software for that (and some may use custom features allowed by the standard but hard to be predicted by programmers; I'm in need of some to encode Gregorian Chant, for instance, and I think I'll have to add more variety to the already existent for that). This situation might be improved with the evolution of the abc standard itself and of initiatives such as The ABC Project [http://sourceforge.net/projects/abc] [http://abc.sourceforge.net/]. Once feasible, a plugin might be a solution, regardless of Chris's remarks, as far as the abc community is concerned (i.e., inside the abc world at least, the developers are known and trusted), but for the common surfer they would always apply, so that the option to download the source or a trusted format should still be provided. Paulo Eleutério Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] more abc interpretation questions
[EMAIL PROTECTED] wrote: [TCEGc] for [!thrill!CEGc] I really like the concept of a !thrill! ornament. It makes the music really exciting... Sorry, I just couldn't resist. The funniest part is that the typo was consistent throughout the message (I didn't cut and paste). Believe me, Freud *has* much to say about that! Who might think abc had something to do with psychoanalysis? Paulo To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] more abc interpretation questions
John Chambers wrote: Phil Taylor writes: | | 2. L=1/4 and [FG/]G , what beat is the second 'G' on? 2 or and-of-one? | | Undefined, I'm afraid. | | MusicXML has an interesting construct to deal with this kind of situation. | The backup and forward tags have the effect of moving the time point, | so you can use backup to go back to the start of a measure in order to | add an extra layer of notes. This means that you can deal with temporary | voices which appear and disappear in the course of a piece. | | Maybe we need something similar in abc? I sorta recall reading about just such a feature in abc2mtex, with a comment that it probably wouldn't work with other abc programs. I've never read about anyone else ever implementing it. Now what was that syntax? ... ABC2MTEX v. 1.6.1 User Guide section 4.2 allows multistave input with syntax similar to MusicTeX's as illustrated below (sample from the U.G.): DEFG ABcd A4 e2 c2 | equivalent to a two-stave system as this: [V:1] ABcd e2 c2 | [V:2] DEFG A4| (i.e., groups joined by '' make a set where the groups are rendered in vertical sequence upwards in diferent staves aligned on the first note while '' signals the start of the next -joined group set). Nevertheless, it says nothing about temporary voices (section 2.2.14, Chords unisons, on the regular abc construct for chords, also shows same-length voicings only). What, I think, comes closer to [...] a comment that it probably wouldn't work with other abc programs [...] is UG section 2.3.2 New notation, on the use of letters H-Z to generate whatever TeX input the user ultimately assigns to the letter in the header.tex file or in the abc file, but still it doesn't address the problem of different-length temporary voices directly. Perhaps what Phil Taylors suggests might be achieved by combining the - ABC2MTEX extension with the x-rest extension included in some packages for an invisible rest, with the additional rule that the group sets belong to the same staff, e.g. x4 CDEF xc x2D2 GABc BAGF % and so on or maybe, allowing for longer segments of chords with temporary voices, MVSTART x4 x2D2 ... CDEF GABc ... xc BAGF ... MVEND (where MVSTART and MVEND are placeholders for start and end delimiters of the multivoice staff segment, e.g. !chordphrasestart! ... !chordphraseend!, and the ... indicate omission of irrelevant matter). That way the meaning would be clear even in case voices crossed. Paulo E. Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] more abc interpretation questions
[EMAIL PROTECTED] wrote: 1. The draft standard allows U: to replace a string with another string. But if, for example, U:T = !trill! always worked, then the T: header would go to !trill! Are there any tunes that use the U: and what do they expect? I haven't come across any. In principle, I don't think it should if the T: header came on a line of its own, because the context in which both constructs would occur would then not be the same. Also if you inlined the T: header, the ':' should prevent the T from being interpreted as a symbol, as you can't have [!thrill!:Part II]. Other header letters also works as a symbol (H: = history vs. H = !fermata!, L: = unit note length vs. L = !accent!, etc.). This just requires the parsing algorithm always to read ahead for context before deciding the meaning. If I got the draft standard right, header field letters used as symbols work normally as if implicitly redefined in a U: field. Seems to me abc grammar is _not_ as context-free as one might think; then the parser should always check the context it is in. Up to the point where it has just read a 'T' after a '[' it is in state 'standby' (to allow e.g. both [T:Part II] for a part title and [TCEGc] for [!thrill!CEGc]); if then it reads in a ':', the context changes to 'just-read-a-header', else, to 'just-read-a-symbol'. 2. L=1/4 and [FG/]G , what beat is the second 'G' on? 2 or and-of-one? You had better say [F/-G/][F/G/-]G/ or [F/-G/]F/G as the meaning may be. The way it is coded does't make it clear at all. Either way the beat count for both voices doesn't balance (i. e, the sample looks incomplete): (1) G/ G/- G/ F/-F/ ? (2) G/ ? ? ? F/-F/ G/-G/ It *might* make sense if standing for something like this (after splitting the parts): [V:1] G/ G A/ B2 | % A/ B2 added just to complete % the voice melody in measure [V:2] F E D2 | % E D2 added just to complete % the voice melody in measure This *should* be codable as [FG/] [EG] [A/] [D2B2] | but then it would be expected from the parser to figure out that - in [EG] the E should start a half beat after the G and that - in [A/] the chord is filled by the remaining half beat of the E. That is confusing and the standards don't even mention this possibility: both the standards v. 1.6 (abc2mtex's User Guide included) and draft v. 1.7.3 illustrate the construct with same-length examples. Once in an arrangement I did code something like that and the typesetter (abcm2ps, probably, but I'm not sure, it was long ago) didn't render it as I expected -- and it wasn't the programmer's fault. From then on, I always spell such things out, like [F/-G/] [F/G/-] [E/-G/] [E/A/] [D2B2] | and all is pure joy. I think the standards should be reviewed so as to state that this chord construct *must* contain notes/pauses of the same length only, with ties to the next chord as needed. That would make meaning clear and leave to the typesetting application rendering details. This approach seems to me the most appropriate, because some instruments, e. g. classical guitar, can make heavy use of chords representing voices, some of which start from nowhere and end wherever they feel like it (that is, the pauses are not written out). The voicings may be clear on a typeset staff, but in abc it would be hard to algorithmically assign the notes to the intended melodic line in all cases but the simplest ones. Paulo E. Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Correct syntax for right repeat bar line after a second time ending?
Alasdair McAndrew wrote:
... I have first and second time endings, after
which I need to start a repeat. But what is the correct syntax for this?
Repeats are signaled like this:
A B c d :|
^^\(repeat everything so far)
D E F G |: A B c d | c B A G :| F E D C |]
^^ ^^\_(repeat from '|:' to this point)
A B c d | c B A G :: F E D C :|
means
A B c d | c B A G |A B c d | c B A G | F E D C | F E D C |
A B c d |: c B A G :: F E D C :|
means
A B c d | c B A G | c B A G | F E D C | F E D C |
The source of confusion seems to be the use of [ and ] to mean a thick
bar
when used with | meaning a thin bar ('[|' and '|]' indicating structure
and
alternative 1st/2nd/... repeat boxes after a bar (|[1, |[2, etc.).
When it comes to signaling repeats, ABC doesn't care to depict how they
are displayed, i.e., it doesn't mimic printed music that closely. Only
the points where the repetition starts and/or ends are marked as needed
and the typesetting program does the rest. The repeat signs are:
Sign Meaning
|: you will repeat from this point on when you meet
repeat-back sign (':|' or '::')
:| repeat from the last '|:' or start over if
there is no last '|:'
:: repeat from the last '|:' or start over if
there is no last '|:' and come back to this
point when you see a repeat-back (':|' or '::')
You would profit by reading ABC's specifications (v.1.6 and the draft,
both
available at the ABC Homepage http://www.gre.ac.uk/~c.walshaw/abc/)
and
abcm2ps's documentation. If you installed one of Guido Gonzato's RPMs,
you should find it in your /usr/share/doc/abcm2ps-version directory
(including the draft). If for some reason you don't have the doc files,
it
is worthwhile to download the package again just to get them. They
explain
how to tweak your sources so that abcm2ps does things that ABC alone
can't.
Hope this clarifies.
Happy 2003!
Paulo
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC for Linux
John Barnaby wrote: I have been an ABCwin user for some years but am now switching from windows to linux. Welcome to the promised land! Can any lister please tell me which abc program that runs on linux most closely approximates ABCwin in functions. Thanks. I'm afraid you'll have to get used to the Unix/Linux way of getting some things done, that is, use several different packages, each one designed for a specific task: one for printing/viewing (done in *n*x with TeX or PostScript, both of which you should already have right from the box in Linux) output, another for getting MIDI output, others to manipulate the abc source (transpose, separate parts multivoice tunes, and so on), some to get special output (tablature, ...). To begin with, I'd advise to get: - for viewing/printing sheet music: abcm2ps http://moinejf.free.fr/ Converts abc to PostScript. jaabc2ps http://www.guitarnut.com/abc/ Same; also generates tablatures. Win source/EXE zips and Linux RPMs available. abctab2ps http://www.lautengesellschaft.de/cdmm/ Generates PostScript and lute/guitar tablatures. Site has other useful programs (add-ons, scripts) to make specific tasks easy (number PS output pages, add abc mode to editors, extract parts, etc.). Source and binaries (Linux RPM, zipped for Win). abc2ps http://www.ihp-ffo.de/~msm/ The father of them all. Available DOS executables, DOS and Linux sources. - for MIDI, PostScript sheet music, source manipulation: abcMIDI http://abc.sourceforge.net/abcMIDI/ 4 in 1 package: abc2midi (converts abc to MIDI) midi2abc (tries to get abc from MIDI tune) abc2abc (transposes, checks, reformats) yaps (converts abc to PostScript) Normally you get the sources (usually in C) to compile (your Linux box has a C compiler, cc or gcc). You might check Guido Gonzato's precompiled RPMs for abcm2ps and abcMIDI as well as his own programs abcpp (a preprocessor to use conditional processing, macros and other source manipulation), abcprt (to get a part from a multivoice tune) and an abc add-on for Jed text editor, at The ABC Plus Project homepage http://abcplus.sourceforge.net/ Except for Skink, these are command line programs. If you don't feel like using the shell, there are Skink http://www.geocities.com/Nashville/7088/abc4mac.html Allows you to edit, view and play ABC 1.6. I couldn't get it to read more complex ABCs. From what I read on ABCWin home- page, that's not quite the functionality you're used to. Java application. Runabc http://ifdo.pugmarks.com/~seymour/runabc/runabc.html A front-end to most of the above and some more (PostScript viewers, MIDI players, builtin and user-defined editor) with interesting editing and finding functionalities. Written in Tcl/Tk (which you should have in your Linux box). Seems more like what you're looking for, as it integrates the many tools in something like an abc development environment. These, I think, will do for quite a toolbox to play with. Anyway, you might wish to check The ABC Home Page http://www.gre.ac.uk/~c.walshaw/abc/ for some more Linux apps. I myself as a rule download and try to install or build whatever abc software I can get; they seldom eat much disk space and generally have some unique feature to accomplish specific tasks. I hope it has helped. Paulo Eleutério Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC for Linux
Laura Conrad wrote: Paulo == Paulo Eleutério Tibúrcio [EMAIL PROTECTED] writes: Paulo Skink ... Paulo couldn't get it to read more complex ABCs. I hope you sent bug reports about the ABC's it wouldn't read. Wil is a really responsive developer, and after I sent him some bug reports, it now reads my abc's, but unless you tell someone about the problems, it's going to go on having bugs. Thanks for the advice. I'll see to it from now on. Paulo To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] BarFly v1.3 available
Jack Campin wrote: iCab gives the downloaded archive a TEXT file type and iCab creator type. I can't see how to set any preference in iCab to fix this; is it supposed to be under browser control? ... Servers usually send an header telling the MIME-type of a resource, but ultimately the browser controls how the file is to be handled (e.g., it may ignore the header and rely on local system's/user's settings). Seems you've already looked for a preferences section in your browser's settings menu. Maybe it is hidden somewhere; if the documentation doesn't help, look for some section on *applications* or *file types* or *MIME-types* both in your browser's and your system's configuration files or databases (as file handling may be set application-specific or system-wide). On Linux, for instance, Opera, Netscape, Lynx, Galeon, Konqueror all let you define associations of file extensions, MIME-types, applications and actions to take in each case quite transparently. ... I can change it after downloading, using a file typer utility ... It's not sure to work, because text files may be changed when transfered between different systems (e. g., Mac - Unix, Win - Unix) so that their contents display properly, while binary files (must and) transfer as is. Browsers usually recognize and manage long-time registered MIME-types properly, but must be told how to deal with unrecognized ones; seems you have to find how to configure this feature in yours. Good luck. Paulo E. Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Newbie Questions
Ed Skinner wrote: 1) Is there a FAQ? If you mean on abc notation itself, please check John Chambers' Frequently Asked Questions about ABC Music Notation url: http://trillian.mit.edu/~jc/music/abc/ABC-FAQ.html. 2) Is there a way to get automatic measure numbering? Yes, but it is package dependent. J.F. Moine's abcm2ps, for instance, lets you specify that either of three ways: in the command line, in a format file or in the tune itself; please check files 'New.Features' and 'format.txt' for details (in abcm2ps's doc directory, e.g., /usr/share/doc/abcm2ps-version/). For portability, it would be advisable not to code this information in the abc file you intend to store tunes on a permanent basis. Lots of abc software references may be found at the Abc Home Page url: http://www.gre.ac.uk/~c.walshaw/abc/ sorted by operating system and other criteria. Best regards. Paulo Eleutério Tibúrcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
