Re: [abcusers] [ABCp] Parts
Wil Macaulay wrote: Yes, I do have a suggestion: if you really want to implement a 'generic parser', start by choosing a standard to implement. If you want to suggest changes to the standard, do so as an independent process. Otherwise you'll end up with a parser that only parses non-standard abc... I've chosen the following approach: - first of all be compliant with 2.0 draft standard, - then include 1.6 standard as long as it does not harm the 2.0 compliancy - than include non standard (but commonly used and/or useful) syntax. For example, the 2.0 standard includes the -8 keyword to transpose an octave down, I've added the -15 and -22 keyword (that are avalaible in other notation packages) and also extended it to other clefs so that treble-8 is recognized (as the 2.0 standard requires) but so does baritone+15! There is one important thing to note here. ABCp is, at the present stage, a scanner, not a parser. This means that, in this case, ABCp reports to the host program that the user specified a clef with TWO octave transposition. It is entirely to the host program to decide if this is acceptable or not! ABCp is an enabler for programmers that want to write software that accept ABC files as input. Using ABCp they can concentrate on the functions of their software instead of losing time to accomodate this or that ABC extension. This concept is very crucial. Let me bore you a little bit with an example:. This is a 2.0 compliant Key: K:Bb mix ^^c_d mezzosoprano transpose=+5 stafflines=3 while this is the same key K:Bb Mix Db C##\ mezzo t5 s3 that makes use of some extensions. As far as the host program is concerned, the two keys above get reported exactly in the same way: [EMAIL PROTECTED] Sf [EMAIL PROTECTED] 053 @ (The string above is a serialized version of the binary representation of the parsed key field.) The host program will use a function like abcKeyTonic() to get Bb and abcKeySemitoneTranspose() to get 5 regardless the way those information are actually represented in the abc file. A function abcError() will report if something went wrong (for example if K:Lmin was encountered). If the host program wants to deal with the string itself, it may well do so using the abcString() function that returns the Key string as it appears in the file. I hope I've been clear enough. Please feel free to comment! BTW. I still have to figure out a clean interface! The functions above (abcKeySemitoneTranspose for example) are so ugly that I'm a little be ashamed to publicly release them! R:D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] [Han-Wen Nienhuys] LilyPond 2.4.0 released
LilyPond version 2.4 was released today! LilyPond is a program for making beautiful music notation. It is open source/free software, and is available for all popular operating systems. It runs on most Unix flavors --including Linux and MacOS X-- and MS Windows. Use it for your music too! With this release, LilyPond does not rely anymore on TeX to do titling and page layout, but distributes page breaks optimally by itself to produce evenly spaced pages, while respecting user specified turning points. The slur formatting code has been completely rewritten, and now yields classical engraving quality results for most cases. In addition, version 2.4 adds fret diagrams, a safe execution mode for webserver use, a further simplified input format, better typography for ledger lines, many bugfixes and a fully revised and updated manual. Go and grab it at http://lilypond.org A big thank-you goes out to our contributors: Carl Sorensen David Svoboda Guy Gascoigne-Piggford Heikki Junes Hendrik Maryns Kristof Bastiaensen Mats Bengtsson Michael Welsh Duggan Peter Lutek Werner Lemberg Also thanks to our bug-hunters: Antti Kaihola, Bertalan Fodor, Brian Clements, Christian Hitz, Christoph Ludwig, Christophe Papazian, Daniel Berjón Díez, Dave Phillips, David Bobroff, David Brandon, Doug Asherman, Ed Jackson, Heinz Stolba, Jefferson dos Santos Felix, Karl Hammar, Marco Gusy, Martin Norbäck, Matthias Neeracher, Maurizio Tomasi, Michael Kiermaier, Pascal Legris, Peter Rosenbeck, Russ Ross, Stephen Pollei, Thomas Scharlowski, Will Oram, Yuval Harel, Happy music printing, The LilyPond development team, Han-Wen Nienhuys Jan Nieuwenhuizen Core development Graham Percival Documentation Editor Erik Sandberg Bugmeister Pedro Kroeger Build meister -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ Info-lilypond mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-lilypond -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
