Re: [abcusers] smaller notes among others
On Mon, Mar 15, 2004 at 03:08:05AM +, John Chambers wrote: Kristian Nørgaard asked: | Is it possible to write a part of the melody with smaller notes than | then rest. | This is often used when you want to show a short melodyline, which isn't | part of the main melodi. | | It should show up in the same staff as the rest. I think this has been asked before, but it hasn't led to any discussions that I know of. Current abc doesn't have any way to express this. Sorry. I don't think it's what you're lokking for, but just in case, for the sake of completeness, there is %%scale. I've just tested this in abcm2ps, and it can be applied to a whole staff, but not to less than that. And then there's %%multicol ... -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC 2.0 spec questions/suggestions - voice overlay
On Fri, 12 Mar 2004 13:29:05 -0700 (MST), Tom Satter [EMAIL PROTECTED] wrote: Hello everyone, Hello Tom, [snip] I saw one post in the last 9 months suggesting a way to make this work, but it was not really discussed at length. I would like to propose that we introduce three new symbols: ( - start a voice overlay - reset time back to previous start point ) - end a voice overlay abcm2ps has '(..)', but there is a parsing problem on the closing parenthesis. Now, in the absolute, the end of voice overlay could be ommited: overlaying stops when time is exhausted! Otherwise, there is no ambiguity having a single '' for reset, and this forbids mixing the 2 overlay types. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** | http://moinejf.free.fr/ Pépé Jef| mailto:[EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC 2.0 spec questions/suggestions - line continuations
On Fri, 12 Mar 2004 14:02:21 -0700 (MST), Tom Satter [EMAIL PROTECTED] wrote: [snip] Doing either one of these would give a way for people that like to embed key changes, etc on new lines to do it: I:implicit_line_breaks = no K:D [V:S] ccAb ccA2|fdab [V:A] ccAb ccA2|fdab K:G [V:S] xdE2|c4 c4 |! [V:A] xdE2|c4 c4 |! This would give you one line with two voices with a key change in the middle of the second measure. This does not work with most actual ABC programs: 'K:G' applies to the second voice only, and the voice S continues with 2 sharps... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** | http://moinejf.free.fr/ Pépé Jef| mailto:[EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] multicol alignment (margin units) in abcm2ps
I've been typing some things up that require a bit of annotating; alternate versions of particular bars, for example. The neatest way I've found is to use %%multicol to drop a new (partial) staff underneath, showing just the bar in question (%%scaled down). To be comprehensible, this bar must line up vertically with the one it refers to. I've been using %%leftmargin and %%rightmargin to do this, but I think it's not quite ideal, because - I don't see a specific note as to the units these accept, but they all seem to be absolute lengths ? whereas, the position of the bar it's referring to will be proportional to the paperwidth, so wouldn't the alignment only work for one size of paper ? In other words, I tried %%leftmargin 50% and it didn't complain, but it didn't do what I hoped it might either. Not suprising, for a couple of reasons ;-) but, can anybody see a less hardwired way to do this ? -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
RE: [abcusers] Making a book, how?
Once the project reaches a certain level of complexety, it may be worth learning to use MusiXTeX directly , combined with LaTeX and its relatives. http://icking-music-archive.org/; abc2mtex allowed (still allows) a shorthand way of writing traditional folk session tunes and printing them out but assumes many of the complexities available would not be used. Checking the web site above just now, I am saddened to discover that Daniel Taupin passed away several months ago. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I. Oppenheim Sent: 13 March 2004 19:49 To: [EMAIL PROTECTED] Subject: Re: [abcusers] Making a book, how? On Fri, 12 Mar 2004, Jeremy Cowgar wrote: But one question, is abc2mtex still supported? Does it support the newer standards? What about multivoice extensions, etc??? Unfortunately, the author of abc2mtex stopped its development. There is no support for any of the new ABC extensions. P.S. Ewan... I would still like to see some sample code. I am familure with Abcm2ps and know that it is currently developed. Abcm2ps generates beautiful output and can certainly be used to make music books. It might be helpful to read the tutorial at http://abcplus.sf.net Another possibility is to use Lilypond (www.lilypond.org) which ships with an ABC converter. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.chazzanut.com/ Synagogue Choir: http://www.ask-choir.org/ Business: http://www.amsterdamhotelspecials.com/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC 2.0 spec questions/suggestions - line continuations
Interesting, I still like the idea of being able to make line breaks not be manditory on the newline. However, maybe there should be a way to say that something applies to all voices (say V:* for starters)? Then you could write: I:implicit_line_breaks = no K:D [V:S] ccAb ccA2|fdab [V:A] ccAb ccA2|fdab [V:*] K:G [V:S] xdE2|c4 c4 |! [V:A] xdE2|c4 c4 |! which is explicit and less error-prone than having to repeat meter and key changes in every voice. tom Jean-Francois Moine said: On Fri, 12 Mar 2004 14:02:21 -0700 (MST), Tom Satter [EMAIL PROTECTED] wrote: [snip] Doing either one of these would give a way for people that like to embed key changes, etc on new lines to do it: I:implicit_line_breaks = no K:D [V:S] ccAb ccA2|fdab [V:A] ccAb ccA2|fdab K:G [V:S] xdE2|c4 c4 |! [V:A] xdE2|c4 c4 |! This would give you one line with two voices with a key change in the middle of the second measure. This does not work with most actual ABC programs: 'K:G' applies to the second voice only, and the voice S continues with 2 sharps... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** | http://moinejf.free.fr/ Pépé Jef | mailto:[EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- tom satter - or just plain old tom (303) 543-7623 (home) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC 2.0 spec questions/suggestions - voice overlay
Jean-Francois Moine said:
On Fri, 12 Mar 2004 13:29:05 -0700 (MST), Tom Satter wrote:
[snip]
( - start a voice overlay
- reset time back to previous start point
) - end a voice overlay
abcm2ps has '(..)', but there is a parsing problem on the
closing parenthesis. Now, in the absolute, the end of voice overlay
could be ommited: overlaying stops when time is exhausted!
Otherwise, there is no ambiguity having a single '' for reset,
and this forbids mixing the 2 overlay types.
The reason that I chose '(' for start and ')' for end is that they
are not ambiguous - it makes no sense to see a single '' immediately
at the beginning or end of a slur. It does make sense to see a single
'' just before a slur that that is why I did not pick '(' for the
opening start token.
Having a single '' mean reset to last '(' if given or to last
barline if not would make sense to me.
tom
--
tom satter - or just plain old tom
(303) 543-7623 (home)
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Making a book, how?
On 12 Mar 2004 at 15:09, Jeremy Cowgar wrote: On Fri, 2004-03-12 at 14:43, Ewan A. Macpherson wrote: On 12 Mar 2004 at 14:26, Jeremy Cowgar wrote: Can anyone give me some suggestions as to how I would create a nice book. I want to be able to give a copy or two away to other people who play with me, otherwise I would just print the resulting file from abcm2ps, but I would like to include a title page, table of contents, etc... I don't have my code handy, but I can send you examples later if you like. I would love to see some example code as I am new to really making abcm2ps do it's magic. I've snipped this down to two pages'-worth and an exemplary table of contents ... -- tunebook.abp, the file to run through abcpp %%pageheight 11in %%pagewidth 8.5in %%landscape 1 %%straightflags 1 %%stretchlast 1 %%topmargin 1.5cm %%printtempo 0 %%titleleft 1 % TITLE PAGE %%vskip 4in %%textfont Times-Roman 32 %%center Ann Arbor Pipes Drums %%center 2004 Tunebook %%textfont Times-Roman 16 % TABLE OF CONTENTS %%newpage #include contents.abc % PARADE SETS % %%header A2PD Tunebook 2004 2/4 Parade Set $P %%newpage 1 %%scale 0.65 #include gairloch.abc #include brownhair.abc % %%header A2PD Tunebook 2004 3/4 Parade Set $P %%newpage %%scale 0.68 #include greenhills.abc #include battleoer.abc % %% % LAST PAGE % %% %%header %%newpage %%vskip 5in %%center Compiled by Ewan A. Macpherson. %%center Typeset using abcm2ps by Jean-Francois Moine %%center and abcpp by Guido Gonzato. end of tunebook.abp -- contents.abc - %%center ANN ARBOR PIPES AND DRUMS TUNEBOOK 2004 %%center TABLE OF CONTENTS %%vskip .75in %%multicol start % set names %%begintext obeylines 2/4 Parade Set 3/4 Parade Set %%endtext % tune names %%multicol new %%leftmargin 6cm %%begintext obeylines The High Road to Gairloch Brown Haired Maiden The Green Hills of Tyrol When the Battle's O'er %%endtext % page numbers %%multicol new %%leftmargin 12cm %%begintext obeylines 1 1 2 2 %%endtext % start new TOC meta-column %%multicol new %%leftmargin 15cm %%begintext obeylines 2/4 Parade Set 3/4 Parade Set %%endtext %%multicol new %%leftmargin 20cm %%begintext obeylines The High Road to Gairloch Brown Haired Maiden The Green Hills of Tyrol When the Battle's O'er %%endtext %%multicol new %%leftmargin 25.5cm %%begintext obeylines 1 1 2 2 %%endtext %%multicol end - end of contents.abc --- cheers, e. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Making a book, how?
On Mon, 2004-03-15 at 10:05, Ewan A. Macpherson wrote: I've snipped this down to two pages'-worth and an exemplary table of contents ... snip cheers, Ewan, That worked great, thank you for sharing. I will start working toward this to make my simple book. Jeremy To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] smaller notes among others
Kristian Nørgaard asked:
| Is it possible to write a part of the melody with smaller notes than
| then rest.
| This is often used when you want to show a short melodyline, which isn't
| part of the main melodi.
|
| It should show up in the same staff as the rest.
John Chambers responded:
snip snip
The idea was that you could then write {1C2DE F3G}AB and the C2DE F3G
notes would follow the rules for ordinary notes, but would be drawn
with very small notes. To get the Baroque-style measured ornaments,
you could write something like |{2d3c}c6 d2|, for example. The d3c
notes would be drawn larger than grace notes, and would have the
correct lengths, though of course they would take away from the 6
counts of the real c6 note.
And, of course, one of the reactions of most other musicians would be
that this is idiotic notation which nobody in their right mind would
ever even want to use. But the Baroque crowd would be happy.
I purchased a book of fiddle tunes (not Baroque fiddle tunes, in case you
might wonder ;) ) only this past weekend which uses both grace notes of
varying length within a single ornament and smaller notes to show short
melody lines not part of the main melody. The smaller notes are used to
show when a fiddler might play a non-melody note on an string adjacent to
the string on which the melody note is played (and of course to show what
note is played).
There are abc transcriptions where unisons occur only few times in a given
piece. It may be of interest to a non-fiddler to know which note in each
case is the melody note. If we make the assumption that the melody note is
always the note of highest pitch, then there is no problem, but in the case
of this particular book that I am speaking of, there are many cases where
the non-melody note is higher pitched than the melody note, sometimes in
many note phrases that also contain non-melody notes lower than the melody
note. This could leave the non-fiddler with a fairly large number of
choices in figuring out the proper melody (of course, since there is
usually no standard version of a fiddle tune, I suppose that very few would
get too worked up if the non-fiddler just picked notes, as long as the
result sounds good).
Is your notation meant for grace note phrases only? Otherwise, how might
you use the notation you describe above to show different note sizes for
notes played at the same time, rather than as a kind of grace note? Say
for example if at some point in a tune I want to write [GB], but I want to
make it clear that G is the melody note and B is the non-melody note, and
thus I want B to be smaller. What would I do?
Randy.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: A backslash (\) at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending. It becomes pretty straightforward (actually fairly easy) to parse if you define it that way, and seems fairly consistent with the 1.* usage. Anyone see any gaping holes in that logic? You have still left open the question of whether programs should look for a simple continuation on the next line, or look for a field identifier if appropriate. (e.g. a w: field) Actually, I think that by phrasing it the way I did above, there is no assumption made at all about the next line, so it's parsed exactly as you would parse any other field/tune data line. I'm basically avoiding the term continuation in 1.* parsing because that confuses the issue -- I see it as not so much a continuation as a break/no-break flag on the line. The assumption I *am* making is that the decision to break the staff or lyric line is made when the end of line is parsed. Without a \ character, the staff or lyric line is normally broken. With a \ just before the end of line, the staff or lyric line is not broken. Thus, for a w: field with a \ at the end, you *would* have the w: on the next lyric line, which doesn't have to happen immediately. Of course, this begs another 1.* specific question - should I ignore \ at the end of non tune data or lyric lines, or flag them as parse errors or warnings? For simplicity, I'm leaning towards simply ignoring them. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
I like this way of doing it. I think that it is clearer than what I was proposing a couple days ago. This would mean that the backslash at the end of a line does not have the semantics currently written in the 2.0 spec, but it is more backward compatible with 1.x, it is defined well enough to parse without ambiguity, and it does everything that seems to be needed. If we had the ability to specify an all voices line, that would complete it :-). Then we could write my previous example as (with a little more detail): X:1 T:test M:C L:1/8 K:D [V:S] ccAbccA2| fdab\ w:a-a-a-a a-a-a-a | a-a-a-a \ [V:A] ccAbccA2| fdab\ w:i-i-i-i i-i-i-i | i-i-i-i \ [V:*] [K:G] [M:3/4] [V:S] xd | c3 c3 | w:a-a | a a | [V:A] xd | c3 c3 | w:i-i | i i | And it is perfectly clear what it is supposed to do. There is no ambiguity about what the backslashes relate to. Although, you should modify your statement so that it can occur on tune, lyric, and symbol lines (add the symbol to the list). tom Steven Bennett said: So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: A backslash (\) at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending. It becomes pretty straightforward (actually fairly easy) to parse if you define it that way, and seems fairly consistent with the 1.* usage. Anyone see any gaping holes in that logic? You have still left open the question of whether programs should look for a simple continuation on the next line, or look for a field identifier if appropriate. (e.g. a w: field) Actually, I think that by phrasing it the way I did above, there is no assumption made at all about the next line, so it's parsed exactly as you would parse any other field/tune data line. I'm basically avoiding the term continuation in 1.* parsing because that confuses the issue -- I see it as not so much a continuation as a break/no-break flag on the line. The assumption I *am* making is that the decision to break the staff or lyric line is made when the end of line is parsed. Without a \ character, the staff or lyric line is normally broken. With a \ just before the end of line, the staff or lyric line is not broken. Thus, for a w: field with a \ at the end, you *would* have the w: on the next lyric line, which doesn't have to happen immediately. Of course, this begs another 1.* specific question - should I ignore \ at the end of non tune data or lyric lines, or flag them as parse errors or warnings? For simplicity, I'm leaning towards simply ignoring them. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html -- tom satter - or just plain old tom (303) 543-7623 (home) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: ABC 1.x continuations (was ABC 2.0 draft)
Except I'm only proposing this as an aid in defining how to parse 1.* style completions (when the user has selected that as a parsing flag...), not as a change to the 2.0 spec. I actually prefer the 2.0 continuation mechanism, although I'm not strongly attached to it and could see how the 1.* style, defined the way I suggested, could actually make more sense. (Especially, as I think about it, in light of the %%continueall XCommand, which certainly should NOT behave as if one had placed a 2.0 style continuation on each line, but *should* behave, IMHO, as if there was a 1.* style continuation there...) As for the all voices line, I'm not sure I like that idea all that much -- it creates a new parsing state which opens up a number of cans of worms - specifically what is legal when you are in an all voices section and what is not. Possibly a better approach would be using something like [V:*=S] to assign the current voice specific settings of voice S to all other voices. That field would *not* have the side effect of changing voices. (You might also allow [V:A=S] or the like.) So your line below: [V:*] [K:G] [M:3/4] ...might instead read: [V:S] [K:G] [M:3/4] [V:*=S] ...and you would end up being in voice S. I don't know if I like that much either (you still need to define *exactly* which voice specific settings get copied and which do not), but from a parsing point of view, I much prefer it over what you were suggesting. --Steve Bennett I like this way of doing it. I think that it is clearer than what I was proposing a couple days ago. This would mean that the backslash at the end of a line does not have the semantics currently written in the 2.0 spec, but it is more backward compatible with 1.x, it is defined well enough to parse without ambiguity, and it does everything that seems to be needed. If we had the ability to specify an all voices line, that would complete it :-). Then we could write my previous example as (with a little more detail): X:1 T:test M:C L:1/8 K:D [V:S] ccAbccA2| fdab\ w:a-a-a-a a-a-a-a | a-a-a-a \ [V:A] ccAbccA2| fdab\ w:i-i-i-i i-i-i-i | i-i-i-i \ [V:*] [K:G] [M:3/4] [V:S] xd | c3 c3 | w:a-a | a a | [V:A] xd | c3 c3 | w:i-i | i i | And it is perfectly clear what it is supposed to do. There is no ambiguity about what the backslashes relate to. Although, you should modify your statement so that it can occur on tune, lyric, and symbol lines (add the symbol to the list). tom Steven Bennett said: So... If it can only occur on tune and lyric lines, and it can only occur where a staff break or lyric line break would be valid, then that is why I suggested a definition along the lines of: A backslash (\) at the end of a line means do not break the staff or lyric line at this point if that's what would happen because of the following line ending. It becomes pretty straightforward (actually fairly easy) to parse if you define it that way, and seems fairly consistent with the 1.* usage. Anyone see any gaping holes in that logic? You have still left open the question of whether programs should look for a simple continuation on the next line, or look for a field identifier if appropriate. (e.g. a w: field) Actually, I think that by phrasing it the way I did above, there is no assumption made at all about the next line, so it's parsed exactly as you would parse any other field/tune data line. I'm basically avoiding the term continuation in 1.* parsing because that confuses the issue -- I see it as not so much a continuation as a break/no-break flag on the line. The assumption I *am* making is that the decision to break the staff or lyric line is made when the end of line is parsed. Without a \ character, the staff or lyric line is normally broken. With a \ just before the end of line, the staff or lyric line is not broken. Thus, for a w: field with a \ at the end, you *would* have the w: on the next lyric line, which doesn't have to happen immediately. Of course, this begs another 1.* specific question - should I ignore \ at the end of non tune data or lyric lines, or flag them as parse errors or warnings? For simplicity, I'm leaning towards simply ignoring them. --Steve Bennett To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
