Re: [abcusers] Page break formatting
From: Laura Conrad [EMAIL PROTECTED] Date: 15 Aug 2003 07:15:15 -0400 Jeff This seems so simple that I must be forgetting some obvious Jeff reason that it couldn't work. Can anyone enlighten me? Traditionally, one of the reasons to use ABC rather than other input languages is ease of typing. True, though this is mostly in terms of inputting the actual tune. People who want something that simple probably won't use %% directives anyway. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] \ line continuation (was: Re: Changelog)
Date: Tue, 5 Aug 2003 23:18:20 +0200 (W. Europe Daylight Time) From: I. Oppenheim [EMAIL PROTECTED] 2.2. Continuation of input lines If the last (non-space, non-remark) character on a line is a backslash (\), the next line should be appended to the current one, overwriting the backslash and any spaces or remarks that follow it, to make one long logical line. This causes several problems. Logically, you've changed the continuation command to \ instead of \ + newline. I see at least two problems with this: 1) It reduces the available ABC command space, by removing \anythingelse from the list of possible commands. 2) It breaks some other existing parts of the standard, including: a) \TeX-command at the beginning of a line, required by the abc2mtex class of programs b) \,c (for c-cedille) and other commands that give accented characters I think it would be far better to simply keep \newline as the line continuation command. This way, any text on the line after the \ is still processed. You'd get an unrecognized symbol \ warning, but you don't lose anything. And if the standard additionally were to define \ (i.e., \ + space) to be equivalent to a space (i.e., arbitrary whitespace), the unrecognized symbol error would go away too. This makes the rules a lot simpler. If we also assume % and anything following it (if not a recognizeable psuedo-comment) is *ignored* (as stated in the 1.6.1 standard) rather than treated as whitespace, then: aged | dead | beef |\% this line wants to be continued cage | face | edge | would preserve the line continuation. The first step would be to chop off the comment, yielding: aged | dead | beef |\ cage | face | edge | The result would then be concatenated into: aged | dead | beef |cage | face | edge | However, the following: aged | dead | beef |\ % this line wants to be continued cage | face | edge | would turn into: aged | dead | beef |\_ cage | face | edge | (Read \_ as \ in the above. I wanted to be sure to note the space after the \ at the end of the line.) This would be parsed as aged | dead | beef | cage | face | edge | I think this works, is straightforward, and isn't terribly limiting. I.e., all we lose is a little defensive programming around \ + whitespace. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re:abcm2ps and 'extras'
Date: Tue, 12 Aug 2003 21:03:14 +0200 (CEST) From: Martin Tarenskeen [EMAIL PROTECTED] It seems that with a little knowledge of Postscript language some nice tricks can be done with a program like abcm2ps. Can anyone recommend some literature, or online documentation, about the Postscript language. A basic introduction or a complete syntax description, or something in between ? -- Martin Tarenskeen From: Ewan A. Macpherson [EMAIL PROTECTED] Date: Tue, 12 Aug 2003 15:44:51 -0400 In terms of a basic introduction, I have found A First Guide to PostScript, http://www.cs.indiana.edu/docproject/programming/postscript/postscript.html very helpful. e. In terms of a complete syntax description, the most complete document is the Postscript Language Reference Manual: http://www.adobe.com/products/postscript/pdfs/PLRM.pdf It's complete, thorough, and contains 912 pages. Jeff Bigler To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Page break formatting
Date: Wed, 13 Aug 2003 19:45:21 +0100 From: Richard Robinson [EMAIL PROTECTED] Some of the abc2ps %% commands don't properly fall under the formatting classification. [snip] But most of abc2ps's %% commands are for control of formatting. Yes. But mostly, at least, display-related. Some of them are tune-specific, some of them work on the page level. And then there's %%propagate-accidentals which has a musical meaning. I hesitate to open this can of worms, but perhaps the standard could separate commands into: %%display command command is intended for all applications that display music. %%play command command is intended for all applications that play music. %%global command command is intended for all applications. %%anythingelse command command is intended for those applications that recognise it, and can be safely ignored by other applications. (Such as the %%MIDI commands.) (The last of these is already in the standard.) This would make it easier for each program to decide which command set(s) it would need to interpret. Obviously, the standard would have to enumerate the set of existing %%command commands, which would have to be grandfathered. E.g., %%newpage would continue to work, but the preferred form would become %%display newpage Similarly, the preferred form of %%propagate-accidentals would become %%global propagate-accidentals This seems so simple that I must be forgetting some obvious reason that it couldn't work. Can anyone enlighten me? Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] empty music paper
Date: Thu, 14 Aug 2003 22:34:30 +0200 (CEST)
From: Martin Tarenskeen [EMAIL PROTECTED]
Despite the computer age and all those wonderfull abc tools, I still use a
lot of old-fashioned music paper. Today I used abcm2ps to make printable
empty music paper. With %%scale I can even make big size staves (for my
very young piano pupils).
X:1
M:none
K:C clef=none
x
x
x
x
% and so on. As much as fit on one page
Of course abcm2ps is giving a lot of underfull messages... :-)
When I have studied the docs about Postscript that some of you recommended
to me, I will probably not need abc anymore to create empty musicpaper. It
will probably take very few lines of simple PS code to do this.
Martin Tarenskeen
I had the same thought a while back and did exactly that.
Here's my PostScript file for generating staffpaper. Have fun with it.
It should give you some insight into how PostScript works as well as
giving you some configurable staff paper. The grouping variable
defines how many staves should be bracketed together.
Jeff
%!
%
% Last modified: 2003/02/05 00:59:26 by [EMAIL PROTECTED]
%
% Units of measure. Don't modify these. %
% define units of measure
/point {} def % 1 pt = 1 pt
/inch {72 mul} def % 1 in = 72 pt
/mm {72 mul 25.4 div} def % 1 mm = (1/25.4) in = (72/25.4) pt
/cm {72 mul 2.54 div} def % 1 cm = (1/2.54) in = (72/2.54) pt
% User-Configurable Data: %
/linespacing {5 point} def % distance between lines
/leftmargin {0.75 inch} def % left margin
/rightmargin {0.75 inch} def% right margin
/bottommargin {0.75 inch} def % bottom margin
/topmargin {0.75 inch} def % top margin
/grouping {1} def % group this many staves together
/papersize {(letter)} def % size of paper
% Defining macros and other non-user-configurable items%
% Don't change anything below here unless you know what you're doing! %
/staffspacing {linespacing 9 mul} def % staffspacing proportional to
% linespacing
/groupspacing {0.5} def % spacing between groups
% fraction of staffspacing
linespacing 32 div setlinewidth % thickness of lines (points)
% = 0.25 pt for 8pt spacing
0 bottommargin staffspacing sub translate % define bottom of page
% fix value of grouping if someone sets it to a nonsensical number
grouping 1 lt { /grouping {1} def } if
grouping 1 eq { /groupspacing {0} def } if
papersize (letter) eq % dimensions of letter paper
{
/pagewidth {8.5 inch} def
/pageheight {11 inch} def
} if
papersize (legal) eq% dimensions of legal paper
{
/pagewidth {8.5 inch} def
/pageheight {14 inch} def
}
papersize (A4) eq % dimensions of A4 paper
{
/pagewidth {210 mm} def
/pageheight {296 mm} def
} if
/pageavail {% available space on page
pageheight topmargin sub bottommargin sub
} def
/groupsize {% size of each group (including groupspacing)
grouping groupspacing add staffspacing mul
} def
/groupsonpage { % tentative number of groups on page
pageavail groupspacing staffspacing mul add groupsize div floor
} def
/staff {
% draw horizontal lines
0 leftmargin add 0 moveto
pagewidth rightmargin sub 0
lineto
stroke
0 leftmargin add 0 linespacing add moveto
pagewidth rightmargin sub 0 linespacing add
lineto
stroke
0 leftmargin add 0 linespacing 2 mul add moveto
pagewidth rightmargin sub 0 linespacing 2 mul add
lineto
stroke
0 leftmargin add 0 linespacing 3 mul add moveto
pagewidth rightmargin sub 0 linespacing 3 mul add
lineto
stroke
0 leftmargin add 0 linespacing 4 mul add moveto
pagewidth rightmargin sub 0 linespacing 4 mul add
lineto
stroke
%% Uncomment the following section to draw a barline at the left side
%% of each staff
%% draw left bar line
%0 leftmargin add 0 moveto
%0 leftmargin add 0 linespacing 4 mul add
%lineto
%stroke
%% Uncomment the following section to draw a barline at the right side
%% of each staff
% % draw right bar line
%pagewidth rightmargin sub 0 moveto
%
Re: [abcusers] ABC Standard 2.0 revision III
From: Laura Conrad [EMAIL PROTECTED] Date: 30 Jul 2003 09:19:29 -0400 Besides, those of us who typically read from only treble and bass clefs, can't ever remember which line an alto C clef is on. This reminds me of a conductor joke that's popular among us violists. However, I'll have to redefine a couple of symbols first, so everyone can parse the joke: U:Q=+question+ U:A=+answer+ Q: What's the difference between alto clef and ancient Greek? A: Some conductors can actually read ancient Greek. Jeff P.S. I'm about a week behind in my email. Apologies if the ABC standard for decorations is no longer +...+ ;-) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Installing abcm2ps on OS X (no actual ABC content)
Date: Fri, 25 Jul 2003 18:10:51 +0100 Once again, apologies for replying to a thread over a week late. :-| From: [EMAIL PROTECTED] (Phil Taylor) Did you read the first post of this thread? Three hours spent fighting with Unix to do something exceedingly simple and straightforward, resulting in failure. Twenty seconds on MacOS 9 allowed me to fix it. Yes, Unix is supremely flexible and powerful. But if its learning curve is sufficiently steep to terrify me (I've been using computers for thirty years) how is the average user expected to cope? A friend of mine once described UNIX as a brain surgery interface. You can do anything you want if you know what you're doing. If you don't know what you're doing, you can cause a lot of damage without accomplishing anything useful. That same friend described the earlier versions of MacOS as a hockey glove interface. The gloves severely limit what you can do, but it's just about impossible to hurt yourself. MacOS 10 could therefore be described as doing brain surgery in hockey gloves. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] man
Date: Thu, 24 Jul 2003 01:45:32 +0200 (W. Europe Daylight Time) From: I. Oppenheim [EMAIL PROTECTED] On Wed, 23 Jul 2003, Phil Taylor wrote: Actually I'd rather have them as plain text, since I have any number of seraching and indexing programs I can use with that. If that's all you want, it's trivial. Open a text file, call it man2txt.c and give it the following contents: Much simpler, using vi as an example, would be: man vi | cat vi.txt Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: %%ABC 2.0 identifier
I'm catching up on old email. Sorry if this has already been addressed. Date: Fri, 18 Jul 2003 13:03:20 -0400 From: Steven Bennett [EMAIL PROTECTED] The key is to define user fields in such a way that they can be safely ignored by computer programs trying to parse the file I think this is one of the more important points in this discussion. I think ABC needs this. In HTML, anything in is a command. Any command the browser doesn't understand gets ignored. While HTML isn't a perfect system, it is nice to have a simple method of communicating to the program, This is a command. Interpret it if you can; otherwise ignore everything up to the end-of-command delimiter. The !...! commands, whether we like them or not, work this way. Regardles of whether the syntax ends up being !...!, +...+ or whatever, the standard could (and IMO should) specify that new fields that are not part of the standard must be enclosed between appropriate delimiters, so that software that doesn't know how to interpret these fields can easily determine the extent of what it needs to ignore. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC examples with bang?
I'm catching up on old email here. Date: Fri, 11 Jul 2003 17:41:01 +0100 From: [EMAIL PROTECTED] (Phil Taylor) Bernard Hill wrote: Why is it so great? What's wrong with z8 (or z6 or whatever is appropriate)? Presumably because you can write | Z5 | and have the program interpret it as | z8 | z8 | z8 | z8 | z8 |, thus saving a lot of typing. Also, because in typeset music, Z5 would give you a five-bar rest that looks like this: | -5- | Whereas five bars of rest using five z8 bars would give you: | - | - | - | - | - | (Imagine that - is a whole rest.) Each of these forms has its own uses in typeset music. Both should play identically. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Stars and Bangs
Date: Mon, 7 Jul 2003 13:24:24 +0100 From: Jack Campin [EMAIL PROTECTED] Using + where abm2ps and abcmidi currently use ! would handle legacy tunes better. There are very few tunes out there using the obsolete chord notation, and very few chords that could cause ambiguity (has anybody ever used +fff+ as a chord?). I'm warming to this idea. The strong objection I've seen on this list to ! as a linebreak are that !...! is in the draft standard, whereas ! = break is not. The strong objection I've seen to !...! is that ! = break is already in use in approximately 9-10% of the ABC tunes that are findable on the web. Because 1.7.6 has always been a draft or proposed standard (even though it has already been implemented in a couple of programs), and because !...! is used in a far smaller percentage of the tunes that are findable on the web, it seems evident that !...! is the construct that will eventually have to give way. In the discussion to date on the list, I haven't seen any strong objection to +...+ . I'm sure we're never going to reach consensus on this issue, but I think going with +...+ will result in the least amount of objection and breaking the least number of legacy ABC tunes. I do think it would be appropriate for the standard to specifically describe !...! as deprecated, but also to encourage (but not require) programs to support those !...! commands that were explicitly listed in the 1.7.6 draft for backward compatibility. But that whole syntax, whatever its lexicon, is still a second-rate solution, rushing to implement a graphical semantics for concepts that need a musical one (the structural, control-flow terms like da capo being the worst offenders). Actually, I was under the impression that da capo and its variants was a fairly straightforward control-flow problem. My initial attempt at it would be to use three boolean flags: 1) take all second endings (initially cleared) 2) ignore 'fine' and coda signs (initially set) 3) jump to next coda sign or end (initially cleared) Whenever you encounter a repeat sign (with or without multiple endings), a fine or a coda sign, check the flags and behave accordingly. There are three situations I'm aware of in music that use this kind of flow control: a) da capo/dal segno al fine - go to the beginning/segno, play without repeats until fine and you're done. For this situation, when you get to the da capo/dal segno command: i.) set flag #1(i.e., take second endings/no repeats) ii.) clear flag #2 (i.e., don't ignore fine/coda signs) iii.) leave flag #3 cleared (i.e., don't jump when you get to fine) iv.) go back to the beginning/segno b) da capo/dal segno al coda - go to the beginning/segno, play without repeats until the first coda sign, then jump to the second coda sign. For this situation: i.) set flag #1(i.e., take second endings/no repeats) ii.) clear flag #2 (i.e., don't ignore fine/coda signs) iii.) set flag #3(i.e., jump from next coda sign to the one following) iv.) go back to the beginning/segno c) da capo/dal segno al fine e poi al coda - go to the beginning/segno, play without repeats until fine and then jump to the coda. This situation is actually the same as (b) above. The difference is that the music says fine instead of the first coda sign. i.) set flag #1(i.e., take second endings/no repeats) ii.) clear flag #2 (i.e., don't ignore fine/coda signs) iii.) set flag #3(i.e, jump when you get to fine) iv.) go back to the beginning/segno Error handling: in situation (a), if there's no fine play to the end of the piece. (Actually, this is not technically an error--some pieces do this.) In situation (b), if there isn't a second coda sign, continue playing to the end of the piece and display an error message. In situation (c), if fine is missing, continue playing through the coda to the end of the piece and display an error message. If the coda sign is missing, stop at fine and display an error message. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Solution for ! notation?
I've always thought of the %% construct as being for new and experimental stuff, which is always going to break other programs, so if the staves command becomes standard I would prefer that it got it's own field identifier. I had always thought %% was for commands specific to a particular program or subset of programs. I.e., any program could decide which %% commands it wanted to interpret, as those commands would not be part of the actual ABC. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Stars and Bangs
From: John Walsh [EMAIL PROTECTED] Date: Sat, 5 Jul 2003 18:10:28 -0700 (PDT) Irwin Oppenheim wrote: So if * serves as the !break! command, what symbol could we use for the !nobreak! command that was proposed by Laura? Well, if \ is the symbol for continuation, which tells the program Don't feel you have to put a linebreak here, you could have \\ for and I really mean it. I had also thought of \\ as well. And a picky semantic point, but one that I think is important. I believe the continue the current line if there's room command is not just \, but \ + newline (I.e., the \ character plus a actual carriage return/line feed immediately after it). If this is true, we can still use \something-else for another command. (However, we might have to interpret \ + whitespace + newline to be equivalent to \ + newline in order to support existing ABC files.) But there is a principle we're running into, now that free symbols are so scarce: something like \\ is easy to type and quite visible, so one might want to save it for something which will be used a lot. Another argument against using \\ for a no line break is the parallelism between TeX and ABC. (\\ gives a linebreak in many TeX environments.) I suspect a no-linebreak won't get much general use, tho people who use it at all might use it a lot. This would make it a candidate for a directive something like !whatever-you-do-please-don't-break-the-line-here! which will, of course be used this way: U:N = whatever-you-do-please-don't-break-the-line-here ... |abc def| N ABC DEF|... I'd recommend against making a command so long that it encourages people to use a macro for _every_ instance of it. ... |abc def| !whatever-you-do-please-don't-break-the-line-here! ABC DEF| ... is actually more readable than ... |abc def| N ABC DEF| ... because for the latter, you need to look up what N means in a separate location. In my opinion, ... |abc def| \nobeak ABC DEF| ... or ... |abc def| !nobreak! ABC DEF| ... is even better. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Solution for ! notation?
Date: Sat, 05 Jul 2003 09:07:33 +0200 From: Bert Van Vreckem [EMAIL PROTECTED] Jeff Bigler wrote: I would find it particularly useful to have an explicit linebreak command that would override the continue all line ends (append '\') option to the abc2ps-like programs. Usually, I want the program to just decide where to put the line breaks, with a few rare exceptions. Well, personally I want to be in charge of linebreaks myself. I play a lot of folk dance music which consist of phrases of 8 bars. When linebreaks are every 4 or 8 bars, this makes the score more readable. Agreed. When I'm transcribing morris dance tunes, I try to do that. When I'm doing classical music, I prefer to let the software do the splitting, and tweak it only when necessary. I never meant to suggest getting rid of newline signifying a linebreak. What I would like to see is: 1) Newline continues to signify a linebreak unless preceded by \ This can be overridden by the software. (E.g., the -c option in abc(m)2ps). 2) An additional explicit linebreak command (e.g., !) signifies a linebreak that *cannot* be overridden by the software. This would allow me to run abcm2ps with the -c option and still be able to say put a linebreak here. 3) A no line break command, which would tell the software to rearrange the output as necessary to avoid putting a linebreak there. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Stars and Bangs
Date: Sun, 6 Jul 2003 20:55:33 +0200 (W. Europe Daylight Time) From: I. Oppenheim [EMAIL PROTECTED] On Sun, 6 Jul 2003, Jeff Bigler wrote: 1) Newline continues to signify a linebreak unless preceded by \ This can be overridden by the software. (E.g., the -c option in abc(m)2ps). 2) An additional explicit linebreak command (e.g., !) signifies a linebreak that *cannot* be overridden by the software. This would allow me to run abcm2ps with the -c option and still be able to say put a linebreak here. If there exists an explicit linebreak command, there is no reason why a bare newline should continue to imply a linebreak. I can think of two reasons. a) There's a lot of ABC already in existence that depends on that assumption. b) It's nice to have the two levels of linebreak, one that can be overridden and one that can't. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Solution for ! notation?
From: Eric Galluzzo [EMAIL PROTECTED] Date: 04 Jul 2003 19:53:11 -0400 Irwin has said, rightly as it seems to me, that both are useful. However, they also seem to be incompatible. So, why not pick a symbol other than ! for the latter usage [dynamics and other decorations]? * seems ideal, and quite logical, too: in emails, IRC, etc., it is commonly used to boldface or emote something. Thus: X:1 T:Sample M:4/4 L:1/8 K:C *pp*CDEF GAB*fermata*c |] If folks do not like * (perhaps because of the aforementioned abc2mtex usage), another unused character could be chosen instead. All programs, to my knowledge, that implement the !...! construct (abcm2ps, jcabc2ps, and abc2midi?) are under active development, to my knowledge. Therefore, all of them could easily be altered to accept * as the character rather than ! (perhaps accepting the ! as a legacy construct). We would have a rather more difficult time changing abc2win, since it is not open-source; and the myriad tunes that are already on the web could not be changed. I agree. Going forward, it doesn't matter which character we choose for dynamics and other decorations. The only concern is supporting legacy ABC that's already out there. I like your solution of explicitly supporting !...! as an alternative form for the elements that are already defined in 1.7.6. For the record, I have used !...! a great deal, but I would certainly be willing to change all my ABC to use the *...* notation instead. I imagine that if we could reach a consensus on this issue, most other people who use this notation would be willing to do so as well. People just want something that works; they do not terribly care what it is. Furthermore, if this were done, I could feel free to introduce ! into my scores with the abc2win meaning, which could be useful at times. I would find it particularly useful to have an explicit linebreak command that would override the continue all line ends (append '\') option to the abc2ps-like programs. Usually, I want the program to just decide where to put the line breaks, with a few rare exceptions. While we're discussing !...! decorations, I'd like to revive a suggestion I made last year for some shorter alternatives (plus some additional decorations). In your example (and in the 1.7.6 draft standard), I note that *fermata* is particularly clunky and interrupts the readability of the ABC more than I think necessary: X:1 T:Sample M:4/4 L:1/8 K:C *pp*CDEF GAB*fermata*c |] A little over a year ago, I suggested a list of shorter delimiters. There were some problems with how I presented them, but I would like to revive the suggestion with the following slightly modified list. I'd welcome any feedback. I'm using the !...! notation in this list, but if we decide to use something other than ! (such as * or +) for a delimiter, it's easy enough to make the appropriate substitution. Symbols not associated with a note: !! repeat previous bar. (Symbol looks like a large % taking up the whole bar.) !2!, !3!, etc. repeat previous 2 (3, etc.) bars. (Symbol looks like a large % sign across 2 (or 3, etc.) bars.) !,! comma (i.e., momentary pause in the music) !,1.5! comma that lasts (for example) 1.5 times the default note length (for programs that play music) !=! railroad tracks (i.e., break in the music) !=1.5! railroad tracks pause that lasts (for example) 1.5 times the default note length (for programs that play music) !'! breath mark (apostrophe) !c! coda symbol (a ring with a cross in it) !|! phrase mark (vertical line in upper part of staff) !|l!long phrase mark (extending 3/4 of way to bottom of staff) !|m!medium phrase mark (extending to middle of staff) !|s!short phrase mark !q(!beginning of cue (display notes within this delimiter as small notes on the staff, with rests above or below) !q)!end of cue Symbols associated with a note: !+! or !*! left-hand pizzicato mark (looks like a + over the note) !+s! or !*s!snap-pizzicato (or Bartok pizzicato) mark !-! tenuto mark (dash) over/under the note !0! through !9! display the number over/under the note head (e.g., for fingerings). Multiple fingerings (for chords) displayed from top to bottom. !th!thumb symbol (for cello thumb position) !! accent mark !^! strong accent (a dark ^ over a note) !g! glissando from the next note to the one after it !g(!glissando starting with this note (I.e., all notes glissandoed together until !g)! command) !g)!glissando ending with this note (i.e., close a !g(! command) !h! fermata (hold) !h1.5!
Re: [abcusers] Re: My point of view on the abc standard
There's been a lot of traffic on this topic already. Two things I'd like to emphasize: 1) I agree that the standards committee should have a chairman, but I think the committee needs to elect him/her. 2) We seem to be in danger of falling into the trap of everything that any known ABC-related application does has to be included in the standard. This runs the risks of a) making the standard too difficult to interpret and/or implement, and b) adding features to the standard before they've been used widely enough to figure out if they're actually workable as implemented. I'd recommend that in general, we try not to add features to the standard unless: a) there is consensus (or at least an overwhelming majority opinion) as to what the feature should do, and either b) several (or at least a few significant) applications already use it, or c) more than one developer (or group of developers) is planning to implement (or in the process of implementing) the same feature Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
From: Calum Galleitch [EMAIL PROTECTED] Date: Thu, 3 Jul 2003 20:03:01 + That doesn't mean that all software should be made Free. Your software is unique, as far as I know, in coming as close to a freehand notation package as possible. I don't think there's anything else with your focus. In turn, that means there isn't all that many folk that need exactly what you provide (but the folks like Willie Donaldson who do, really do). So charge them for it. And when you're retired, and you're looking at spending your time in a rocking chair, whack a GPL on it and bask in the knowledge that people are benefitting from your generosity. In the meantime, earn your living. Another angle is the business model that a former employer of mine (Cygnus Solutions) used. Cygnus sold commercial-grade support and development for free software. They got bought by Red Hat in 2000, but up to that point, they were best known for their support of gcc (the Gnu C Compiler). The way this worked was that customers would purchase Cygnus's support for gcc, which meant that they would get a version from our CVS tree, which we would be expected to support and provide bug fixes, on the time scale that companies expect for commercial software. Cygnus shipped the compiler with source code, which was freely modifiable and distributable (under the GPL). Customers could also hire Cygnus to add specific features or optimizations that they needed, again with development to be done on the time scale that companies expect for commercial software. Cygnus contributed all of its code back to the FSF on a more-or-less quarterly basis, so the open source community did eventually reap the benefits of the work that Cygnus did. Again, this is not to say that all software has to be free, only that there are companies that have succeeded in making money from free software. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC 1.7 standard?
Date: Tue, 1 Jul 2003 00:27:36 +0100 From: Bernard Hill [EMAIL PROTECTED] In message [EMAIL PROTECTED], John Chambers [EMAIL PROTECTED] writes Bernard Hill writes: | In message [EMAIL PROTECTED], Henrik | Norbeck [EMAIL PROTECTED] writes | There was a standards committee (or some similar name) | some years ago. Don't remember who was on it, but I think it | should be revived, with a chairman/leader. | | Just one comment: having a software developer in charge of standards is | a conflict of interests. S/he can drive the standard in the direction of | his/her own software. Yeah, and I'd like to add that we also shouldn't have a musician in charge of the standard, since s/he can drive the standard in the direction of his/her own favorite musical styles. ;-) A reasonable point actually. Eg The needs of Scottish Pipers and Choral writers might lead the standard in incompatible directions. (Actually, there's an important reason that programmers should at least be consulted regularly. There is a history of computer standard committees developing standards that can't be implemented. It would be good to avoid this.) Agreed on all counts. I think the comment about musicians was meant to be tongue-in-cheek. On the other hand, I'm sure most people would agree that the standards committee standard *must* include programmers and musicians, since nearly all of the people who will ever do anything with ABC fall into one or both categories. I don't think we need to (or even can) avoid any possibility of conflict of interest. I do think the people on the committee need to be appropriately considerate of the ways in which other people use ABC, but there are several developers and musicians on this list whom I'd trust to be appropriately impartial in that regard. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcm2ps/PostScript questions
From: Calum Galleitch [EMAIL PROTECTED]
Date: Sat, 21 Jun 2003 22:02:38 +
And I don't know what the postscript for strlen() is.
stringwidth
Is there any way of right-justifying this text somehow?
The way I do right-justified text in postscript is to define the
following macro:
/flushright { dup stringwidth -1 mul exch -1 mul exch rmoveto show } def
I then use:
(text) flushright
in place of:
(text) show
Jeff
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcm2ps/PostScript questions
Sorry I didn't include this in my previous reply.
From: Calum Galleitch [EMAIL PROTECTED]
Date: Sat, 21 Jun 2003 22:02:38 +
Ewan MacPherson has been kind enough to show me the code he uses for
1st and 2nd time phrases within parts/lines, and I've taken the
liberty of reproducing part of it. My postscript skills are
insufficiently l33t to understand what's going on in there with the
line of exchs (if someone could explain it, I'd be very grateful),
though I assume it has to do with the internal workings of abcm2ps:
Actually, exch is a postscript command that swaps the last two items on
the stack. As you probably know, postscript is a postfix language,
i.e., you put items on the stack, and then you perform an operation on
the top n items on the stack. Here's a simple example. The sub
command means subtraction, i.e., subtract the top item on the stack from
the next item on the stack.
postscript code result contents of stack (bottom to top)
-- - -
2 1{2,1}
sub 1 {1}
2 1{2,1}
exch {1,2}
sub -1 {-1}
% -- draw first time indication
%%postscript /firsttime { % usage: len x y firsttime
%%postscript exch -9 add exch 2 copy
Presumably you've loaded the stack before calling the function
firsttime. It looks like firsttime takes three arguments. The the
function is called with the items {len,x,y} preloaded onto the stack.
(Postscript uses a LIFO stack, so len is on the bottom of the stack and
y is on top.)
The first exch swaps the last two items, so the stack now contains
{len,y,x}. As I'm sure you realize, the -9 add command adds -9 to the
last item on the stack.. The stack then contains {len,y,x-9}. You exch
again to put the stack back in order. The stack now contains
{len,x-9,y}.
The copy command takes one argument, which is the number of items on the
stack to duplicate. In this case, the stack starts out with
{len,x-9,y}. 2 copy would copy the last two items on the stack and
place those on the stack, resulting in the stack containing
{len,x-9,y,x-9,y}.
I hope this helps.
Jeff
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abcm2ps/PostScript questions
Final message, really. Now the postscript hackers on this list can
start pointing out all the errors in my postings. :-)
From: Calum Galleitch [EMAIL PROTECTED]
Date: Sat, 21 Jun 2003 22:02:38 +
% -- draw first time indication
%%postscript /firsttime { % usage: len x y firsttime
%%postscript exch -9 add exch 2 copy
%%postscript M 0 10 rmoveto /Times-Roman 16 selectfont (1) show
I forgot to point out that in the above, the command show displays a
string at the current point and in the current font. The string is
the argument (in parentheses) given to show. In other words, in the
above command, the:
(1) show
displays the numeral 1 at the current location.
I think what you're hoping to do is to create a function with an
additional argument, which contains the string to display. Your
function would probably look something like this:
% -- draw first time indication
%%postscript /displaycustom { % usage: len x y (text) displaycustom
%%postscript/texttodisplay exch def
%%postscriptexch -9 add exch 2 copy
%%postscriptM 0 10 rmoveto /Times-Roman 16 selectfont texttodisplay show
%%postscriptM 0 6 rlineto currentpoint stroke M
%%postscript 30 add 0 rlineto currentpoint stroke M
%%postscript 0 -6 rlineto stroke
%%postscript } bdef
% -- start / stop of firsttime indication
%%deco 1( 5 - 24 0 0
%%deco 1) 5 displaycustom 24 0 0
The only changes were to change the name of the function to
displaycustom instead of firsttime and add a fourth argument
containing the actual text to display.
Jeff
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc-mode for emacs
Date: Sun, 9 Mar 2003 14:52:49 +0100 From: Kristian =?ISO-8859-1?Q?N=F8rgaard?= [EMAIL PROTECTED] And btw: How can I change the color of the syntaxhighlightning? If you use the hilit19 package, you can add hilit mode-patterns to abc-mode.el. Here are the ones I use: ; hilit19 highlighting patterns for ABC mode (hilit-set-mode-patterns 'abc-mode '( (\\s %.*$ nil comment) ; comment - pink (^%.*$ nil comment) ; comment - pink (\\(:\|2\\|\|:\\|:\|\\|::\\|\|1\\|\|\|\\|\\[1\\|\\[2\\) nil command) ; repeat - yellow (\\(\|\\|^.:\\|\\[\\|\\]\\) nil keyword); keyword or bar line - cyan (\([^\\\)]*\\(\\(.\\|\n\\)[^\\\(]*\\)*\) nil define) ; slur - green ([_^]*[A-Za-z][0-9]?-[ \\|]*[A-Za-z][0-9]? nil define) ; tie - green (\[^\\\]*\\(\\(.\\|\n\\)[^\\\]*\\)*\ nil string) ; string - orange ([\\]+ nil gnus-group-overflowing) ) ) I set the colors using the following. If you want, you can put your own ABC-specific elements to the table below and use those elements for the mode-patterns above, instead of co-opting the existing elements of comment, define, keyword, string, command, and gnus-group-overflowing, like I did. (setq hilit-face-translation-table '( (text . palegreen) (comment . moccasin) (include . Plum) (define . green) (defun . cyan-bold) (decl . cyan) (type . yellow) (keyword . cyan) (label . orange-underlined) (string . orange) (struct . white-bold) (glob-struct . Plum) (named-param . Goldenrod) (crossref . Goldenrod) (formula . DarkGoldenrod) (active-error . default/DeepPink-bold) (error . yellow) (warning . green) (rule . cyan-underline) (msg-subject . yellow) (msg-from . green) (msg-to . pink) (msg-header . cyan) (msg-separator . black/lightblue) (msg-quote . pink) (msg-quote-1 . pink) (msg-quote-2 . orange) (msg-quote-3 . lightblue) (msg-quote-4 . green) (msg-quote-5 . yellow) (msg-quote-6 . red) (summary-seen . white) (summary-killed . white) (summary-Xed . green) (summary-deleted . white) (summary-unread . yellow) (summary-new . yellow-bold) (summary-current . green/dimgrey-bold) (gnus-group-unsubscribed . white) (gnus-group-empty) (gnus-group-full . green) (gnus-group-overflowing . red) (dired-directory . cyan) (dired-link . green) (dired-ignored . moccasin) (dired-deleted . orange) (dired-marked . Plum) (jargon-entry . cyan) (jargon-xref . Plum) (jargon-keyword . yellow) (command . yellow) ) ) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc-mode for emacs
Date: Sun, 9 Mar 2003 21:17:00 +0100 From: Atte =?ISO-8859-1?Q?Andr=E9?= Jensen [EMAIL PROTECTED] On Sun, 9 Mar 2003 12:04:13 -0800 Alice Corbin [EMAIL PROTECTED] wrote: On Sun, Mar 09, 2003 at 08:51:00PM +0100, Atte Andr=E9 Jensen wrote: Very nice, only thing is that on my system (debian 3.0) it refreshes every 30 seconds or so :-( man gv mentions that snip Maybe try it with a : after the y. Makes sense, didn't change anything, though :-( If you've got a app-defaults/GV somewhere (maybe in /usr/X11R6/lib/X11/) look at it to see what it has. GV.watchFileFrequency: 1000 tried values og 1 and 1; no change You do have watchFile set to true, right? From the man page: watchFile Whether the document should be checked periodically and updated automatically if changes are detected. Valid values are True and False. watchFileFrequency Defines the time in milliseconds elapsing between successive checks of the document when watchFile is set to True. Allowed values must be larger than 500. You might try putting these in your .Xdefaults: gv*watchFile: true gv*watchFileFrequency: 1000 I've tried them, and they work for me. (I use * instead of . so it will match even if there's some sort of subclass in-between that I'm missing.) Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] crap (was: Re: abc in web pages)
From: Jon Freeman [EMAIL PROTECTED]
Date: Thu, 6 Feb 2003 16:30:04 -
From: Karl Dallas
You don't have to euphemise crap as cr**. The word's derived from the
name of the man who invented the modern WC, Thomas Crapper.
Wrong. Go to http://www.snopes.com/business/names/crapper.htm
Chambers Dictionary give [Middle English crappe (chaffe) from Middle Dutch
krappe, prob from krappen to tear off]
In terms of its most common modern meaning, the OED gives the following
origins:
6. CRAP, V.
coarse slang.
1. intr. To defecate. So {sm}crapping vbl. n.
1846 [see DUNNY n.2 1]. 1859 HOTTEN Slang Dict. 26 Crapping case, a
privy, or water-closet. 1874 Ibid. 132 Crap, to ease oneself by
evacuation. Crapping case, or ken, the water-closet. Generally called
crapping-castle.
Jeff
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc in web pages
Date: Mon, 03 Feb 2003 09:20:54 -0500 From: Christopher Myers [EMAIL PROTECTED] I prefer abcm2ps, as it allows me more control of the output (IMHO). On the subject of abcm2ps, can anyone here tell me how to make it output two voices onto separate staves? abc2ps does this with the following command: %%staves [(1 2)] but even after reading the source code for abcm2ps I haven't found anything similar. Am I just missing this, or is there in fact no way to do it? Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] P: Field
Date: Mon, 3 Jun 2002 19:56:25 +0100 From: [EMAIL PROTECTED] (Phil Taylor) You have to put each P: field in all of the voices if you want to control playing order. Same goes for M: and K: fields (assuming that you want all the voices to change metre and key at the same point). The latter pair is actually useful for some picese. To give a couple of examples, Charles Ives's first string quartet has a section in which the first violin and viola are in one meter, and the second violin and cello are in another meter. Bela Bartok wrote several duets in which the two voices are playing in different keys. Jeff Bigler To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] re : re: what does that means ?? slurs and ties
From: John Chambers [EMAIL PROTECTED] Date: Tue, 28 May 2002 01:54:13 UTC | I suggest nothing like that. Many users seems to use ties instead | of slurs. I suggested only to make them both legal (in the | standard). What can do more can do less. I will try to use | brackets for slurs when it's possible. If not (if it may confuse) | I'll use - instead. In any case, most musicians don't consider them to be different. This one does. :-) Some folk musicians may not consider them to be different, but I'd argue that most classical musicians do. After all, the most common understanding of a slur is that the second note is to be played without an attack or articulation. That's true in the case of a tie. In the case of a slur, the sound doesn't stop between notes, but there can be (and often is) a slight articulation. It's rare, but I have seen slurs with accents (or even sforzandoes) on notes within the slur. If I saw A4-|A4-|A4, I'd play it as single note at pitch A that was three bars long. If I saw (A4|A4|A4), I'd play it as three separate notes, all connected, and with minimal (but a little) rearticulation on the second and third notes. (In bowed stringed instruments, the rearticulation is often done mostly through changes in vibrato.) If the second note is the same as the first, the result is a tie. So a tie is merely a special case of a slur. A tie is a slur in which both notes are the same. I don't agree. In a tie, each pair of consecutive notes is connected with a curved line. In a slur, the entire slurred phrase is connected with a single curved line. In most prorgams, the special case of a two-note slur looks the same as a tie, though in some published scores the slur will be slightly farther from the note heads than the tie. Also, this is splitting hairs, but a tie connects identical _pitches_, not identical notes. For example, K:Ab D- | K:A C would be considered a tie, because D-flat and C-sharp are different notes, but the same pitch (assuming equal temperament). Ties across key changes are fairly common in classical music. I'd predict that attempting to force musicians to distinguish ties and slurs will continue to be a losing battle. Most of them will have no idea what you're talking about. They look the same on paper, and they sound the same when you play them. So what's the difference? To me, they shouldn't look the same on paper (assuming the program used to typeset them is sufficiently sophisticated), and I don't play them the same. Granted, a few instruments can distinguish the two. But most can't. So to most musicians, there is no difference at all. There's just the supreme silliness of having a special name for a slur when the notes are the same. Actually, I can't think of an instrument that would be unable to distinguish between the two, though I can certainly think of some _musicians_ who can't. :-) The only user friendly approach is to allow ties between different notes and slurs between identical notes. Anything else is merely harrassing your users with silly intellectual hair splitting. I disagree about the silly intellectual hair splitting, but I do agree that a program should allow both ties between different notes, and slurs between identical notes. The former is intended to cover the case of tying two different notes that have the same pitch, but if the user wants to use a tie for notes of different pitches, I see no reason to disallow it. The latter indicates notes that are more connected than legato, but should still sound like separate notes. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] To tell the dancer from the dance
From: Laurie (ukonline) [EMAIL PROTECTED] Date: Sat, 25 May 2002 17:34:58 +0100 Thus writing in a different key and inserting accidentals to correct is not musically relevant. I disagree. Writing __B instead of A, for instance, gives an indication of the chord or chord progression that the composer had in mind. Most players would rather read A than __B, but someone analyzing the score will probably be thankful for the __B notation. In short, it isn't relevant to the sounds that come out, but it is relevant to understanding what's going on musically. I think anything that's relevant to analysis of the music is musically relevant. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] äÌÑ ÄÉÒÅËÔÏÒÁ...WQKOIKFYMT
Date: Thu, 16 May 2002 11:38:56 -0700 From: Don Parrish-Bell [EMAIL PROTECTED] References: [EMAIL PROTECTED] Hi, I hope you are not referring to me as a non-subscriber .. I just subscribed yesterday. Don I'm sure Atte was referring to the spammer as the non-subscriber, not to your humorous reply. Jeff Atte Andre Jensen wrote: On Thu, 16 May 2002, Don Parrish-Bell wrote: Interesting e-mail, but I don't read whatever language you sent this to me in. LOL. Could you perhaps translate it to English for me? I say it again: mean it could we change the behaviour of the list so that non-subscribers cannot post/mean it??? Toby, are you listening? -- love, peace harmony Atte To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE : from ABC to image
Date: Thu, 25 Apr 2002 01:42:40 +0100 (BST) From: Richard Robinson [EMAIL PROTECTED] On Thu, 25 Apr 2002, Jack Campin wrote: On my setup (old Macs) I can generate PostScript from some applications for free (I think, haven't tried lately) but creating Acrobat files needs a utility that costs money. Is there a way to do it free on any current platform? Ghostscript's ps2pdf ? Circularity alert ... ! Actually, that's exactly what I'd recommend too. Most of the musicians on my morris dance teams aren't technically oriented, and wouldn't go out of their way to install a PostScript reader, but they already have the acrobat reader plugged into their web browsers. Giving them a link to a PDF file serves their needs sufficiently. I originally took up Linux because it seemed simpler than getting TeX running on DOS. :-) When I worked in a for a company that made Windows software and I had to use Windows, I installed the MiKTeX TeX/LaTeX package, which was actually pretty easy to set up, and worked well for me. (Those plus CygWin plus emacs made the whole thing bearable.) A Google search for MiKTeX led me to http://www.miktex.org/ Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The virtues of handling music graphically
From: Doug Rogers/Yowza Software [EMAIL PROTECTED] Date: Fri, 12 Apr 2002 15:00:09 -0700 I must say that after reading about the limitations, or seeing some of the solutions ( such as: ^f-|f-|f-|_g-|g-|^^e-|e-|^f ), well, it's a real treat to simply work with a real, graphical score, and use a couple of mouse clicks to put in ties, alternate endings, text in different fonts, chords, a huge vocabulary of different symbols, etc. On the other hand, it's also a real treat to be able to typeset a simple tune (such as the tunes my morris dance teams use) in only about twice as long as it takes to play it through once, to have the source code for the typeset music take up only about 300-400 bytes, and to be able to email the source code to anybody, regardless of what kind of computer they own, and have them be able to generate an identical score in a matter of seconds. WYSIWYGs are certainly more intuitive, but ABC handles all of the examples you mentioned, and I never have to take my hands off the keyboard. I agree that the learning curve is quicker for graphical programs, and that you have to remember a lot more when using ABC. However, I've never encountered a mouse-based typesetting program that can typeset music faster than I can write it out by hand. I can typeset music using ABCs at over four times the speed I can write it by hand. If you'd like some stats on a more complex piece, my ABC transcription for two violins of the Bach Little Fugue in G Minor took a couple of hours to code (less time than it took me to write 1/4 of the piece out by hand), and is just over 4k. Once the two-violin version was finished, transcribing it for violin viola took only about ten minutes. The first few seconds were spent changing the clef for the second instrument, and the rest of the time was spent deciding which of the passages would sound better in a different octave. Jeff Bigler To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Slides
From: John Chambers [EMAIL PROTECTED] Date: Sat, 06 Apr 2002 00:37:29 UTC And in my copious spare time, I'll try to fill in more rows for all the wonderful feechurz that people are implementing. There is a bit of a problem with trying to collect such info. There isn't enough time for one person to gather all the programs and test them all, at least not if you intend to spend any time playing music. Could you please add a section for !command!, as described in the draft proposed 1.7.6 standard? (Or is the document at http://www.gre.ac.uk/~c.walshaw/abc/abc-draft.txt no longer under consideration?) I'm particularly interested in dynamics and their associated markings (crescendo, diminuendo, etc.), and I'm not aware of any existing abc-to-anything-else program that deals with them. (And I'm not enough of a programmer to write my own!) As a classical musician who occasionally plays folk, I personally find the absence of dynamics to be ABC's biggest limitation. As an aside, I play a lot of late-20th-century (and 21st-century) classical music. There are several unusual notations that have come into usage since the 1950s that are not (yet) implemented in ABC. I could mention them on this list as I run across them, if there's interest. I haven't, largely because the bother-to-worth ratio seems too high--these would serve a very small subset of the ABC community, and some of the notations would be difficult to define or implement in a plain-text system. Jeff Bigler To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Reducing Accidentals
Date: Mon, 11 Mar 2002 15:43:54 -0300 From: Luis Pablo Gasparotto [EMAIL PROTECTED] Hi Folks, Is there an application to reduce accidentals (i.e. change __a to =g)? I know that double sharps and double flats exists to be used but sometimes it's easier to read music without them. Indeed it is, but note that the reason composers actually use double sharps and double flats instead of naturals is to make it easier to identify the chords and chord progressions. I understand, being a player myself, that it's easier when playing to read =g than __a , but please do keep in mind that reducing accidentals results in a loss of information that some people would consider important. Jeff Bigler To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] The X: field
From: John Chambers [EMAIL PROTECTED] Date: Wed, 06 Mar 2002 20:46:49 UTC In fact, if you want to have a really simple way of separating ABC from text, you could just look for a line with a letter in column 1 and a colon in column 2. This was the very assumption I used when I added a hilit19 color scheme to the emacs abc mode I use. (I realize that this won't mean anything to people who don't use emacs.) Jeff Bigler To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
