Re: [abcusers] Multivoice in ABC 2.0
There's nowhere in the tune body where you can place a single field and have it apply to all voices. There is nowhere in any ABC spec that explicitly allows that yet, but it is common for medleys to be made up of tunes by different composers or from different sources, so the informational fields should be permitted within a tune body as applying to all voices. (Having different voices by different composers is possible, as in some mediaeval music, but much less common). And of course P: needs to be like this, so that the playing order for multi-voice music can be controlled in an intuitively obvious way. It's hard to see how %%Bfly directives could be done any differently if more than one per tune were allowed - these have to start a line. And I don't see any other way you could get some effects, e.g. varying the slur curvature within a single piece (I spend more time faking that with a graphics editor than in compensating for any other missing feature in BarFly). - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice in ABC 2.0
Jack Campin writes: | There's nowhere in the tune body where you can place a single | field and have it apply to all voices. | | There is nowhere in any ABC spec that explicitly allows that yet, | but it is common for medleys to be made up of tunes by different | composers or from different sources, so the informational fields | should be permitted within a tune body as applying to all voices. | (Having different voices by different composers is possible, as | in some mediaeval music, but much less common). Hmmm ... I have a fair number of examples of this in my music binders. It's especially common in my trad Scandinavian collection. This style has a lot of harmonies, but there seems to be an idea that harmony lines are supposed to be improvised. Writing down the tune is desirable; you want tunes to be fairly stable so that people can play a tune together. But writing down a harmony line seems to be something that is mostly for the benefit of newcomers to the music, to help them learn how to do harmonies. Anyway, it's not unusual to see pages with a melody line and a harmony line, each with someone's name attached. We don't seem to have a way for abc to express this cleanly. (I've also seen a few with multiple harmony lines, each with a different composer name. One problem this can cause is that newbies often think it's music for N voices. So they play all the harmonies together, and wonder why it sounds so bizarre. ;-) I'd think that the most obvious way would be for a C: line inside a part to apply to only that part. We already have a distinction between P: lines in the header and P: lines in the music; this would just add the same distinction to C: (and maybe O:) lines. This wouldn't really qualify as an extension of the abc syntax; it's more of a semantic point. We could make a similar point with lyrics, since it's not at all unusual for different verses to come from different sources. In general, abc's scoping rules are a bit vague. But then, this is also true for staff notation. -- O :#/ John Chambers + [EMAIL PROTECTED] / \ [EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice in ABC 2.0
On 16 Oct 2003, [EMAIL PROTECTED] wrote: I do not like the unnecessary proliferation of inline fields of ABC2.0. I don't think its unnecessary. If you want to change clefs in mid line, for instance. I don't like using the K: field to indicate cleff since most of the tunes that use the V: field to date don't specify a K: for each V: (as I mentioned in the documentation of iabc). That is, most people expect voices to 'inherit' the key specified in the K: field. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html My major objection to inline fields is encapsulated in the statement from ABC2.0 rev IV --- To avoid ambiguity, inline fields that specify music properties should be repeated in each voice. For example, ... P:C [V:1] C4|[M:3/4]CEG|Gce| [V:2] E4|[M:3/4]G3 |E3 | P:D ... - the need to align the meter change in every voice seems a great problem in parsing. What action does the program take when one voice out of eight does not align. ABC 2.0 states For backward compatibility, it is still allowed to notate tune fields on a line by themselves, between the music lines: ed|cecA B2ed|cAcA E2ed|cecA B2ed|c2A2 A2:| M:2/2 K:G AB|cdec BcdB|ABAF GFE2|cdec BcdB|c2A2 A2:| If we are considering multivoice notation, this seems a far more sensible way to notate global key and meter changes than having to match inline fields in all voices. Barry Say To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice in ABC 2.0
Barry Say wrote: On 16 Oct 2003, [EMAIL PROTECTED] wrote: I do not like the unnecessary proliferation of inline fields of ABC2.0. I don't think its unnecessary. If you want to change clefs in mid line, for instance. I don't like using the K: field to indicate cleff since most of the tunes that use the V: field to date don't specify a K: for each V: (as I mentioned in the documentation of iabc). That is, most people expect voices to 'inherit' the key specified in the K: field. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html My major objection to inline fields is encapsulated in the statement from ABC2.0 rev IV --- To avoid ambiguity, inline fields that specify music properties should be repeated in each voice. For example, ... P:C [V:1] C4|[M:3/4]CEG|Gce| [V:2] E4|[M:3/4]G3 |E3 | P:D ... - the need to align the meter change in every voice seems a great problem in parsing. What action does the program take when one voice out of eight does not align. You need to place a metre change in all of the voices (if that's what you want) since you can have voices in different metres. (It's not common, but it does happen, and not only in avant-garde music - Bach did it occasionally.) ABC 2.0 states For backward compatibility, it is still allowed to notate tune fields on a line by themselves, between the music lines: ed|cecA B2ed|cAcA E2ed|cecA B2ed|c2A2 A2:| M:2/2 K:G AB|cdec BcdB|ABAF GFE2|cdec BcdB|c2A2 A2:| If we are considering multivoice notation, this seems a far more sensible way to notate global key and meter changes than having to match inline fields in all voices. Yes, that's perfectly acceptable, but you still need to put fields in all of the voices to which they apply. There's nowhere in the tune body where you can place a single field and have it apply to all voices. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice in ABC 2.0
On 17 Oct 2003, Phil Taylor wrote: Barry Say wrote: You need to place a metre change in all of the voices (if that's what you want) since you can have voices in different metres. (It's not common, but it does happen, and not only in avant-garde music - Bach did it occasionally.) I appreciate precisely what you are saying, but it seems to me we are complicating matters. Meter changes will generally be global and in that case we can write the input for all voices for the first part of the tune which is in the initial meter. Follow this by an M: field Then continue with the input for all voices for the section in the new meter. If we need to change the meter for one voice then this can be done with an inline field Yes, that's perfectly acceptable, but you still need to put fields in all of the voices to which they apply. There's nowhere in the tune body where you can place a single field and have it apply to all voices. I suggest an exactly similar argument for Key changes. I include a section from my suggested modifications to the ABC- standard at http://www.nspipes.co.uk/barry/abc2propos2.html - Multivoice notation includes all situations where multiple input lines are to be aligned in the output. The simplest cases are perhaps one voice and aligned words or symbols or chords. The fields which can be involved are: V:label (voice); w: (aligned words); s: (symbol lines); and c: (chords). K:specification %start of tune. optional fields %these should be unnecessary at his point. Multivoice block optional fields Multivoice block . . Multivoice block Blank line The Multivoice block consists of the fields mentioned above. and might look like. V:1 cAB2 |cAAA |c3B|G2+fermata+Gz ::e4|\ w: que-sto~il vi-so ond' io ri-man-go~uc-ci-so. Deh, w: ran-do fi-so, tut-to re-stai con-qui-so. V:2 AAG2 |AFFF |A3F|=E2+fermata+Ez::c4| V:3 (ag/f/e2)|A_ddd|A3B|c2+fermata+cz ::A4| A section of one voice is notated . The equivalent section of all other voices are then appended along with symbol lines, guitar chords and inline words. All voices can be multiline. The voice, chord and symbol lines do not have an included space when joined. Inline fields e.g.[M:4/4], [K:G] apply only to the voice in which they occur, but fields between blocks have a global effect across all the voices. The first voice in the block controls line-continuation and line- breaking for the whole score so the \ at the end of the V:1 field merely indicates that this is not a staff break. -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice in ABC 2.0
Barry Say wrote: I appreciate precisely what you are saying, but it seems to me we are complicating matters. Meter changes will generally be global and in that case we can write the input for all voices for the first part of the tune which is in the initial meter. Follow this by an M: field Then continue with the input for all voices for the section in the new meter. If we need to change the meter for one voice then this can be done with an inline field OK, let's see if I understand this. (It's always easier to ask a question than to read text carefully): a specification or a change in meter/key/whatever will apply to all voices, *unless explicitly changed* by an (inline?) specification. But the inline specification applies *only* to the one voice. So there is a fundamental difference between inline changes (presumably enclosed in square brackets) and (what do you call non-inline changes? Outline?) those specified by a field starting on a newline (which can not be enclosed in square brackets, or else the email linebreak demon will foil the best intentions), in that the inline changes are local, the outline (sorry! I'd better use quotes on that!) are global. So, the order of voices in the abc is usually not important, *except* in the case of an outline change, which will presumably apply to all subsequent voices, as written in the abc. Or am I confusing things? I include a section from my suggested modifications to the ABC- standard at http://www.nspipes.co.uk/barry/abc2propos2.html I couldn't find that---got the earlier version, but not the second. Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice in ABC 2.0
I do not like the unnecessary proliferation of inline fields of ABC2.0. I don't think its unnecessary. If you want to change clefs in mid line, for instance. I don't like using the K: field to indicate cleff since most of the tunes that use the V: field to date don't specify a K: for each V: (as I mentioned in the documentation of iabc). That is, most people expect voices to 'inherit' the key specified in the K: field. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice in ABC 2.0
On 14 Oct 2003, [EMAIL PROTECTED] wrote: Hi Barry, I agree about putting things in the V: header (or other headers). V: makes sense for type specific things. I disagree about removing the [] in front of the lines for voice change. The reason is that, for instance abcd is a valid voice name in the new standard and is also valid tune body, so the parser has to work a lot harder (slower) to get this to work. I dont see the problem. The first token following The V: tag must be a label. In multivoice a V: tag without a label is useless. for a single voice, that voice would either have the label defined in the tuneheader or none. I do not like the unnecessary proliferation of inline fields of ABC2.0. I fear it will lead to more syntax errors. Barry Say To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Multivoice in ABC 2.0
Hi Barry, I agree about putting things in the V: header (or other headers). V: makes sense for type specific things. I disagree about removing the [] in front of the lines for voice change. The reason is that, for instance abcd is a valid voice name in the new standard and is also valid tune body, so the parser has to work a lot harder (slower) to get this to work. Granted we could have found a better delimiter (since [ is also the start of a second ending, but [V: is not). But existing ABC parsers should already be handling this dilemma. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Multivoice in ABC 2.0
I have come to the point in my software where I must give consideration to multivoice typesetting I intend to allow V:score as an alternative to %%score. The concept of removing voices from a particular typeset version of the ABC field is excellent, but as far as I can tell there is no way of affecting the inline words. Once included in the file they will be printed out whenever their attached line is output (I presume). I am quite happy to go with whatever version of %%score is accepted but I think a decision is required on inline words. Further, I intend to allow the omission of square brackets around voice field specifiers at the start of lines in the tune body. I cannot see the necessity for this construct. Barry Say To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
