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
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
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
[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
Re: [abcusers] Clarification wanted on abc draft standard 2.0 (fwd)
On 4 Oct 2003, John Chambers wrote: I'd guess that this is fairly common. It's likely that some abc tools that handle w: lines now do align syllables with rests, but nobody has ever noticed. If this is true, then making this the official behavior would hardly break anything. And those songs would already be semi-broken, because there hasn't been an official standard for this and different tools probably do handle it differently right now. I dont believe that ABC 2.0 represents a widely accepted standard yet, rather I think that the list just got tired of the discussion This is exactly the sort of situation for which I suggested an extension to the I: field in my proposed extensions to ABC. (www.nspipes.co.uk/barry/abc2proposal.html.) I: _switch align lyrics to rests or I:SWITCH align lyrics to rests or I:SWITCH align_lyrics_to_rests (The above three forms are alternatives) The converse would be I:SWITCH no_lyrics_on_rests I would prefer to see the new standard allowing lyrics on rests (but not barlines) and allowing the above switch for the rare occasions when old files need to be interpreted. I agree with the correspondent who would rather not introduce gratuitous percussion notation. Barry Say To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Clarification wanted on abc draft standard 2.0 (fwd)
Under what circumstances would you want a word or symbol in the lyrics to align with a rest? Phil Taylor I have seen this in the case where words are spoken are shouted or indications such as (clap) (stamp). Sophisticates may well use percussion notation rather than rests in the melody line, but I have seen both. It seems more flexible to allow this rather than forbid. I think the question is why should it be forbidden? Barry Say To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] suggested modifications to the ABC standard
On 27 Sep 2003, John Walsh wrote: Stephen Kellett writes: John Walsh writes: (My own impression is that using white space as a delimiter probably works better for machines than humans---and I think I helped prove that I think you got that the wrong way around? I can give well known (in computing circles) examples of where whitespace has been used as delimiters and it has caused lots of problems. Wouldn't be the first time, won't be the last. But I was thinking of the infamous white-space-delimiter-just-before-linebreak which computers can see, but which causes many humans to make oversights which are sometimes caught before said human throws the monitor thru the window, sometimes not. Possibly we're both right on this? Following the discussions on list and some off-list, I will be modifying my suggestions to require a leading underscore on a field label. So, the format will become: (Single-letter tag)(colon)(optional whitespace)( whitespace- terminated label). The exceptions being (There are always exceptions) V: fields in the tunebody which are assumed to have a label so the underscore is superfluous I: field to allow for the I:MIDI in an earlier standard. Does anyone out there actually use the I: field. I know it is mentioned in the ABC 2.0 standard as an alternative to the directive/postscript- comment %%, but has anyone used it in notation? I know there have been some suggestions to sub-divide these huge categories to produce application-specific groups. Any thoughts. Barry Say To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] suggested modifications to the ABC standard
After much consideration and a little discussion, I have devised some modifications to the ABC standard, which I think could make the structure considerably more elegant without doing to much damage to existing applications. As they are rather complex I have described them on a web page: www.nspipes.co.uk/barry/abc2propos_r1.html I would welcome any comments on or off list. Barry SayBarry Say -- B J Say Smallpipes - http://www.nspipes.co.uk Making and Repairing Bagpipes in the Northumbrian Tradition. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC 2.0 avoiding line breaks
John Chambers [EMAIL PROTECTED] said on 24 Aug 2003 The real problem we're facing is: A lot of people really want the final backslash to mean continue with the next line of the same type. But this discription is sufficiently ambiguous that we end up with different implementers having different understandings of what such a description means, and implementing it differently. Can I suggest the following rule for the interpretation of lines terminated by a backslash. First of all we should take note of the fact that ABC consists of fields and a tunebody. Where a line of a field outside the tunebody ends in a '\' it acts as a continuation character and the next line is appended. Now for the long bit. In the tunebody of a multivoice tunes, we have one or more voicelines symbol lines, included-words line(s) and perhaps guitar chord lines. The following suggestion is simply an extension of the w:lyrics section of ABC 1.7.6 I quote: w:lyrics; supplies a line of lyrics to be aligned syllable by syllable below the previous line of notes. Syllables are not aligned on grace notes and tied notes are treated as two separate notes. Because lyrics tend to take up more space than notes, one w: field and all continuations match one line of notes, whether or not the line of notes ends with a continuation character. If a line of notes is followed by several w: fields, each one supplies alternate words for the notes (this is typically used for writing the verses of a song). endquote So the scheme would be something like this. One of the voices of the piece is selected as the primary voice. The ABC for this voice is entered in the tune body in appropriate sized chunks using continuation characters as appropriate. % 1 - 4 [V: 1] |:z4 |z4 |f2ec |_ddcc|\ % 5 - 9 [V: 1] cAB2 |cAAA |c3B|G2+fermata+Gz ::e4|\ % 10 - 15 [V: 1] f_dec |B2c2|zAGF |=EFG2 |1F2z2:|2F8|] I have chosen to continue all the lines for this voice so the staffbreaks will be at the discretion of the typesetting application. I have chosen V: 1 as the primary voice but I could as easily chose V: 2 since the order of writing the voices is not necessarily linked to the order in the score. Now, I will add the words according to 1.7.6 % 1 - 4 [V: 1] |:z4 |z4 |f2ec |_ddcc|\ w: Son que-sti~i cre-spi cri-ni~e w: Que-sti son gli~oc-chi che mi- % 5 - 9 [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. % 10 - 15 [V: 1] f_dec |B2c2|zAGF |=EFG2 |1F2z2:|2F8|] w: dim-me-lo ben mi-o, che que-sto\ sol de-si-o_. So, apart from the introduction of the [V: 1] construct and the use of +fermata+ inplace of !fermata! this is pure ABC 1.7.6 I will now add the other voices following the same procedure % 1 - 4 [V: 1] |:z4 |z4 |f2ec |_ddcc|\ w: Son que-sti~i cre-spi cri-ni~e w: Que-sti son gli~oc-chi che mi- [V: 2] |:c2BG|AAGc|(F/G/A/B/)c=A|B2AA | [V: 3] |:z4 |f2ec|_ddcf|(B/c/_d/e/)ff| % 5 - 9 [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| % 10 - 15 [V: 1] f_dec |B2c2|zAGF |=EFG2 |1F2z2:|2F8|] w: dim-me-lo ben mi-o, che que-sto\ sol de-si-o_. [V: 2] ABGA |G2AA|GF=EF |(GF3/2=E//D//E)|1F2z2:|2F8|] [V: 3] _dBcd|e2AF|=EFc_d|c4 |1F2z2:|2F8|] No further continuation characters are required. The words for these voices could then be added as could symbol and chord lines. If we wish to break the score at bar nine we remove the \ from Gz ::e4|\ If on the other hand, we wished to force a staff break after bar 8 we could change the line to: [V: 1] cAB2 |cAAA |[*]c3B|G2+fermata+Gz ::e4|\ using an extension of abc2mtex 1.6 or following the spirit of abc2win: [V: 1] cAB2 |cAAA |[!]c3B|G2+fermata+Gz ::e4|\ These constructs are a simple extension of the inline fields format. In some respects some of the confusion here is a matter of terminology. Abc2mtex 1.6 does not mention a continuation character. It says If, however, you wish to use two lines of input to generate one line of music . then simply put a \ at the end of the first line. This is also useful for changing meter or key in the middle of a line of music. This is not a very tight syntax definition but its intent to me is obvious. The role of the \ line-terminator in this case is to indicate that the subsequent linebreak should not invoke a staffbreak. The rule would be that linebreaking and continuation information is contained in the first written voice. Subsequent voices, word lines, symbols and chords must be between the lines of the first voice written in sections equivalent to the written lines of the first voice. Word lines may use a
[abcusers] Subject: ABC 2.0 - reviving E:
I am just about catching up with this review process and think I should add my tenpennorth as an advocate of abc2mtex. The ABC 2.0 draft was based on ABC 1.7.6, but the last version of ABC2mtex produced was 1.6.1 which is pretty well backwards compatible with all previous versions. 1.7.6 did not include the E: (spacing) field which is pretty well essential in TeX based type setting. Proposal: The E: field should be added as an information field specifying a spacing parameter Header: yes Tune: yes Example E:12 Multiple occurence: Replace To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] ABC 2.0 Compatibility with ABC2MTEX
I am concerned about the lack of backwards compatibility of the proposed standard with abc2mtex. Since this was the original program for ABC, I think these issues deserve some consideration. 1. I have already mentioned the E: field in a previous e-mail. This needs reinstating 2. This version of the standard has gone overboard in specifying %% type directives. As I understand it, this is a postscript notation. In abc2mtex, lines starting with \ were used to pass information directly to the typesetting level. These must be allowed in the new standard 3. When the last (none-space) character on a line is a backslash (\) the next line is appended.. If the next line is a comment, meta-comment, directive or begins with a backslash, it should be treated appropriately and the the next line appended to the previous unless (I'm sure there is a more concise way of putting this). 4. Line-breaking. I understand the logic behind the approach, but it conflicts with the ABC standard. This stated that a line of ABC generated one or more lines of input. All music was left justified and a right justified break could be forced by using *. In earlier ABC music was terminated with ** to ensure a justified final line. This is no longer part of the standard, but future software should not fall over when this is encountered. Get rid of !. Note that it has been used, it was never standard and its use is severely deprecated. 5. I preferred the approach in Guido's Draft: It should be stressed that meta-comments are not part of the ABC notation Meta-comments should be allowed to start with ' \' or '%%' The exact range of forms (The Stylesheet specification) should be an appendix. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Revising the ABC standard.
How are we going to reach decisions on a new standard? How come the proposal by Guido was suddenly expanded? Shall I now post my version on a website and call it revision IV? Are we going to vote? If so who votes?. The density of mail on the list is no guide to the opinion of list members. If someone raises an objection to some element of the standard do we then have to have 30 I agree messages on an already very active list to show this is the will of the assembly I think we must first decide whether Revision III is a step forward. Then, whichever version is taken as a basis for discussion, we need it reformulated in a hierarchically numbered fashion so that we can discuss particular sections ( 2.7.6 or whatever), propose changes and come to a decision. It may be that we have to revive the developers list and restrict discussion to the new standard until we have sorted it. What is Chris Walshaw's position on this? ABC is his invention and I would have thought he had some ownership of the standard. There is no reason why anyone should not be extend ABC and call it ABD, but for a self-selected group to take over a standard and change it gratuitously seems to set a very dodgy precedent - standard hijacking? The best examples I can think of come from Microsoft (HTML, Java) and we wouldnt want to end up like that, now would we. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
