Re: [abcusers] V:
Anton Keijzer wrote: To introduce myself: I have an interest in the usability of ASCII file formats for music composition by blind musicians. My question: In the case of the proposed V: extension to the abc file format, is it proposed to be legal notation to have more than 2 occurences of, for example, V:1, for different segments of the one voice? It might, in my opinion, make abc text more readable, in particular, for blind composers. This would be like the bar-over-bar layout of braille music notation. I'm not sure about braille notation, but you can certainly have multiple occurrences of each V: field. In fact, BarFly will only display the music correctly if each line is preceded by its own V: field, so the layout of the abc is the same as that of the music. Mind you, the usage of the V: field is not very standardised. I wrote a discussion of the differences between the different programs a while back; it's at: http://www.barfly.dial.pipex.com/multivoice.txt Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V:
Anton Keijzer writes: | To introduce myself: I have an interest in the usability of ASCII file formats | for music composition by blind musicians. | | My question: | In the case of the proposed V: extension to the abc file format, is it proposed | to be legal notation to have more than 2 occurences of, for example, V:1, for | different segments of the one voice? It might, in my opinion, make abc text | more readable, in particular, for blind composers. This would be like the | bar-over-bar layout of braille music notation. Some (but not all) ABC programs do this already. For example, here's a nice Swedish waltz tune with a harmony line. It's laid out like the printed page, with the staffs in the correct order. With abc2ps, this works just fine. Note the date; this has worked for at least 5 years. X: 1 T: H\okpers vals C: Lars H\okper O: Sv\ardsj\o, Sweden Z: 1997 by John Chambers [EMAIL PROTECTED] N: Harmony by John Chambers [EMAIL PROTECTED] M: 3/4 L: 1/8 K: Dm V: 1 |: A2 \ | Dmd3 efa | Gmg3 fed | A7^c2 A3G | DmF4 D2 \ | DmF2 EF AG | CE4 c2 | G=B2 GA Bd | A7A4 ^c2 | V: 2 |: z2 \ | DmF3 GA2 | GmB3 AGF | A7E4 ^c2 | Dmd4 A2 \ | Dmd2 A2 F2 | Cc2 G2 E2 | GD4 D2 | A7^C2 D2 E2| V: 1 | Dmd3 efa | Gmg3 fed | A7^c2 A3G | DmF4 A7E2 \ | DmD2 ^CD EF | GmAG G3E | A7F2 E2 D^C | DmD4 :| V: 2 | DmF3 GA2 | GmB3 AGF | A7E4 ^c2 | Dmd4 A2 \ | DmF4 A2 | Gmd4 B2 | A7A4 AG | DmF4 :| V: 1 |: A2 \ | DmAF FD FA | AF FD FA | A2 G2 zF | A7E4 G2 \ | GE E^C EG | GE E^C EG | G2 A2 zE | DmF4 A2 | V: 2 |: f2 \ | Dmfd AF Ad | fd AF Ad | f2 e2 zd | A7^c4 e2 \ | e^c AE Ac | e^c AE Ac | e2 f2 zg | Dma4 f2 | V: 1 | DmAF FD FA | AF FD FA | D7A2 d3c | GmB4 B2 \ | B2 c2 zB | DmA4 F2 | A7GF E2 D^C | DmD4 :| V: 2 | Dmfd AF Ad | fd AF Ad | D7^f2 g3 a | Gmg4 g2 \ | g2 a2 zg | Dmf4 d2 | A7^c2 AB AG | DmF4 :| To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] V:
Hi, To introduce myself: I have an interest in the usability of ASCII file formats for music composition by blind musicians. My question: In the case of the proposed V: extension to the abc file format, is it proposed to be legal notation to have more than 2 occurences of, for example, V:1, for different segments of the one voice? It might, in my opinion, make abc text more readable, in particular, for blind composers. This would be like the bar-over-bar layout of braille music notation. Please excuse my question if this is already possible or if there is a better way of doing this. Anton Keijzer To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] V: formatting (was: Susato's Danseryes)
I post this as a separate thread, since it's a general ABC issue, not specifically a renaissance one: Simon Wascher wrote: ... I would find it much better to write the music voice after voice. It is not really possible to read the four voices in paralell in the abc text anyway and it is complicate to extract parts for playing. I agree with Simon. The part extraction possibility alone is reason enough. The Danserye transcriptions are half-'n-half, btw. I started this project a while ago, but was distracted by the Praetorius Terpsichore discussion here at abcusers. When I picked it up again four days ago, I decided to change my editing policy. So the old ABCs have intermingled lines, while the new ones have the voices separated. Frank Nordberg To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] V: field (with apologies to RJP)
Without wanting to re-open the whole can of worms re: the V: field Someone recently (?) posted a URL for a web page which compared the existing variant implementations of the V: voices field. I've now lost the link - can anyone help with that address? Steve Mansfield [EMAIL PROTECTED] http://www.lesession.demon.co.uk - abc music notation tutorial and other goodies To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] V: and w: for abc2mtex
For anyone interested in updating the abc2mtex code to include multistaff music, voices, and lyrics---or who is even vaguely curious about the question: check out Source Forge, in http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/contrib/musixtex/?cvsroot=abc. This contains a discussion of the problem of implementing V: and w: for abc2mtex, some preliminary suggestions for algorithms, and a collection of examples involving multi-staff/lyrics. My feeling after doing this was that it looked quite hopeful, tho probably challenging (nothing involving MusixTeX is a slam-dunk!) and that one could even make a temporary workaround by writing a pre-processor to the present version of abc2mtex. The examples are given in both abc and MusixTeX code. The musixTeX code is fairly heavily commented to make it accessible to someone who knows a just a little about TeX and MusixTeX. (I make no claims about the quality of the abcs---I was learning to use abcm2ps as I wrote them---but the MusixTeX code is there to show what the music is supposed to look like.) The abc uses the abcm2ps conventions on voices. Some of the examples might be useful for abc test suites, quite apart from abc2mtex. The main file is multiv2.txt, which contains both the text and the examples. The examples themselves are also in separate files. My thanks to Laura Conrad for putting it on Source Forge. Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V:
[EMAIL PROTECTED] wrote: Laurie Griffiths asks - Can someone tell me how to access the ABC Users list archive. (Do we have one?) Well, I've heard it mentioned but I don't know how to get at it. I've been offline for a week now (hard disk crash), so I haven't had the chance to participate in the recent discussions, and there's *no* way I'm gonna jump into it at this stage ;) But the abcusers archive is located at: http://iona.tullochgorm.com/abcusers_archive/ Please don't tell any non-subscribers about it. It's not too well updated though. Last posting archived is dated Aug 5th 2000. Frank Nordberg To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: again
John Walsh wrote: X:7 T:Polyrhythmic with No Coherent Bar Division Z:The notes line up, but the bars don't B:MusiXTeX doc p 47 M:3/4 L:1/8 K:C V:1 F2 F2 F2|F2 F2 F2||F2 F2 F2|F2 F2 F2:| V:2 M:2/4 F2 F2|F2 F2|F2 F2||F2 F2|F2 F2|F2 F2:| V:3 M:3/8 L:1/8 F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF:| Surely the third voice is half as long again as the other two? If it were written like this it would be OK: X:7 T:Polyrhythmic with No Coherent Bar Division Z:The notes line up, but the bars don't B:MusiXTeX doc p 47 M:3/4 L:1/8 K:C V:1 F2 F2 F2|F2 F2 F2||F2 F2 F2|F2 F2 F2:| V:2 M:2/4 F2 F2|F2 F2|F2 F2||F2 F2|F2 F2|F2 F2:| V:3 M:3/8 L:1/8 F3|FFF|F3|FFF|F3|FFF|F3|FFF:| BarFly displays the second version correctly, except that there's no way to turn long barlines off in the current version, so the barlines in V1 get drawn across all three staves. All the notes line up in the correct places, and it plays correctly. I'm not sure that I understand what the SYNC command is for. Is it simply to define an area of text where all fields will be interpreted as being global to all voices? On the whole I find it more intuitive to avoid global fields except in the header. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: again
James Allwright wrote: Since nobody yet seems to have even understood my description, I get the feeling that the concept is probably a bit too esoteric and confusing for the abc community. I think I understood it OK. Perhaps the word Synch is a bit confusing, since it implies that the voices should be forcibly synchronised from this point, rather than "since the voices are already in synch here we can put in some fields which apply to all of them". Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: again
James Allwright writes: | Hmm. Sort of like a tab stop? | No, not like a tab stop at all. | | Tell me, can you use that to | synchronize at other than a bar line? | ... | Since nobody yet seems to have even understood my description, I get | the feeling that the concept is probably a bit too esoteric and confusing | for the abc community. Hmmm ... I'd have to admit that I didn't understand it, either. But if the idea is to be able to say "All the parts should be together right here" then it does seem useful. There's a similar concept in the way that abc2ps implements the w: lines. Normally each syllable lines up with a note, with * and _ used to gobble extra notes. But you can skip over all the remaining notes in a measure by using the | barline char in the w: line. So if a staff starts with N bars of instrumentals, you can put N bar lines at the start of a w: line and avoid the need to do any note counting. I'd think that something like this could be very useful with voices, since it's not at all unusual for a voice to be silent for long stretches. Rather than counting all those silent bars, it might be better if we could just omit that voice for the section. And then, at the start of a new section, use V:SYNC to say that all voices should be here now. Implementing this should be simple: Just keep track of the highest bar count in any voice, and set all voices to that bar. (But polyrhythmic music with unequal meters might complicate this.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V:
| V:1 abcd abcd | | V:2 ABCD ABCD | Well, abc2ps rejects this, but it handles: [V:1] abcd abcd | [V:2] ABCD ABCD | On user-friendliness grounds, I'd think that both should be legal. But this implies something else: Users would then have to "declare" voices in the header if they want to include any info about them. The reason that abc2ps doesn't accept the first syntax is that it accepts a voice definition (including possibly changes) inside the music portion. So it is trying to parse the abcd as an option to the V:1 line, and gets confused. A reasonable compromise might be to allow only V:# at the start of a line of music, but also allow [V:...] inline anywhere for the occasions when you want to change the voice's specs. This would be consistent with some other parts of ABC's grammar, and not too difficult to explain to users. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: again
Phil Taylor wrote: John Walsh wrote: [...] M:3/8 L:1/8 F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF|F3|FFF:| Surely the third voice is half as long again as the other two? If it were written like this it would be OK: [...] V:3 M:3/8 L:1/8 F3|FFF|F3|FFF|F3|FFF|F3|FFF:| No--there was a mistake in the part, but it wasn't that. (I just forgot a double bar line.) The original piece had twelve bars of 3/8 time in parallel with 6 of 2/4 and four of 3/4, with no tempo markings. (This is copied directly from the MusixTeX docs, by the way.) Presumably the musicians playing it would figure out the relative tempos by seeing which notes lined up in the three staves. This was why I was thinking that some sort of a tab stop before the double bar-lines (there should have been a double bar ending the sixth measure in the third voice) would tell the program to align the double bars, and give it a fighting chance to get the proper notes aligned elsewhere. I have no idea what to tell a player program to get it to play back as intended, tho. (Sorry, James, I misunderstood your proposal: I was thinking about tab stops at the time and thought you wanted to force voices to align at a certain point, rather than to recognize the fact that they were aligned.) I think it's a pretty safe prediction that whatever the V: standard turns out to be, it'll be abused much as (and for the same good reasons) the guitar chord mechanism is now: i.e. to write something that abc wasn't explicitly designed to do, but *can be made to do*. (That's called "hacking," isn't it? Maybe it'd be a good idea to design in little hackability in the first place instead of worrying about how much abc hacking's been done.) I've been going thru the MusixTeX docs, looking for examples of multi-staff music in order to see what has to be done to give abc2mtex multi-staff capability, and I ran into couple of examples which had isolated chords with notes of different lengths: e.g. three quarter notes and one dotted quarter note. If abc requires all notes in a chord to have the same duration (the 1.7.6 standard doesn't say that explicitly, but it seems to be assumed) then you could hack the extra note with an additional voice. If that's the only place in the piece that happens, you have to put in a lot of invisible rests! (Or could you use V:sync right after that note?) Even tho the extra note comes from an internal voice in the music, this still strikes me as a slight abuse of the voice mechanism. And an inelegant one, at that. Or...is this perhaps one of the things J-F Moine's floating voice was designed for? Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] V: again
I have a small suggestion regarding the V: field and global parameters. This isn't something I've implemented, just an idea I had. I'd like to know if other people think it is useful or not. The idea is that we introduce another V: directive V:SYNC which marks the point in the abc where all the currently active voices synchronize together and we go back into a global mode. Any K:, L: or Q: field from this point on will apply to all voices (so we have a mechanism for global parameters). The V:SYNC also provides a checkpoint in the abc - if the different voices have different musical time, then we know that something has gone wrong and any good abc program should report an error. The "global mode" will continue until a V: field introduces a new voice, or there is music with no preceding V: field, which is treated as V:1 by default. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: again
On Tue 23 Jan 2001 at 11:59AM -, Laurie Griffiths wrote: I think I would prefer V: SYNC string Consider: V:1 abc abc abc abc V:SYNC 1 dead dead dead V:SYNC 2 def def def def V:2 face face face V:SYNC 2 def def def def I don't think you've understood the concept here. What you've written would come out monophonic, though sometimes using voice 1 and sometimes using voice 2. The purpose of V:SYNC is to mark the end of a polyphonic section, so I think your example should be V:1 abc abc abc abc V:2 def def def de V:SYNC V:1 dead dead dead V:2 face face face V:SYNC James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: field
John Chambers a skrivas: Jean-Francois Moine [EMAIL PROTECTED] skrivis: | - there are a limited number of clefs (treble, alto and bass), and | AFAIK there are only 7 usual clefs. The clefs are named by their root | note (G for treble, C for alto and F for bass), and by their line | number (lines are numbered 1 for the lowest, and 5 for the highest). | The 7 clefs are (from highest to lowest): | G(2) - C1 - C2 - C(3) - C4 - F3 - F(4) | - so, a generalized clef indication could be: | | clef=clef_type_and_pitchline_number [snip] Simple, perhaps, but this would probably lead to a lot of confusion among musicians. It is based on the idea that clefs are doing some sort of transposition, but few musicians will be able to make much sense of this. People who use alto and bass clef rarely if ever consider them any sort of transposition. [snip] Transposition refers to a situation where, if you finger a G on your instrument, F or _B comes out. If you finger a G and a G (or g) comes out, this is not transposition. Similarly, saying that "clef=f" or "clef=F," does some sort of transposition makes very little sense, and doesn't help me know how I should type the ABC. I was not thinking about transposition, but only about how the notes are written in ABC. There are 2 schools: the first one says "when I see 'clef=bass', I don't change the indicated note pitch" (abcmidi), the other one says "when I see 'clef=bass', the pitch is 2 octaves lower" (a "c" is converted to the absolute 'C,'). It's only pitch interpretation for both printing and (standard) MIDI playing. About transposition, when some instrument implies it, the player usually knows this transposition, and (s)he does not play the notes as they are written, but better plays the right note the instrument gives. It would be better to adopt notation that says unambiguously how the clef and ABC notes are to map to the staff. Possibly the simplest and least confusing scheme was mentioned by someone (who was it?) a few months ago: Give a clef=name and also a middle=note clause if you want to be precise. The clef name could be one of the three letters CFG, or one of the three common English names. (Maybe we should include the Italian names, too?) (I'm living in latin Europe, but I don't like it: such parsing is time and space consuming while most of the users don't know about the exact ABC syntax) With this scheme, some common clefs might be: clef=G middle=B (standard treble clef) clef=G middle=d (French violin clef) clef=C middle=c (alto clef, abc(m)2ps version) [snip] Hey, stop there! What about: clef=G middle=C clef=C middle=d That's meaningless. You could also use clef=treble, clef=alto or clef=bass, of course. An interesting case would be a double (piano) staff described as: V:1 clef=treble middle=b V:2 clef=bass middle=D I don't like clef definition in voices: the real clefs should only be indicated for staves. Better use K: if you want to change the pitches of a voice. This would be reasonable for piano music, since all notes on either staff would need at most one comma or apostrophe. Note that this doesn't agree with anyone's idea of the "right" default for treble or bass clef. But your typical pianist would like it. A typical pianic may be, but not an organ player: (s)he knows only about voices, and each one may go from the top treble to the bottom bass, on any staff (a voice may span many staves), and (s)he, as a ABC writer, does not want to change the octave pitch each time (s)he'd like to *see* any specific clef on the printed score. This notation would make it easy to correct ABC that was written for a different program than the one you're using. Rather than laboriously changing all the commas in a bass line, you could just insert a "middle=d "or "middle=D," clause in one line (K: or V:) in the header, and it would come out looking good. That is just what I proposed: 'clef=G' or 'clef=g'. May be I did not explain it with clear words? This could be useful even for people who only use treble clef. It's common to see tunes written out in a range that is in the middle of a flute or violin's range, which is an octave high for most human voices. You could add "middle=b" to the tune and get it printed an octave lower, where vocalists are used to reading. Similarly, you [snip] There is a musical notation for that: have a dash line above the staff starting with '8'. In my proposal, this could be done, including the computer to do it by itself... [snip] you map an arbitrary line to an arbitrary note. That would certainly be a possibility, but the question was "Who can do simpler?") When you suggest 'middle=bla', I'd say it's not simpler at all: it asks for more syntax parsing, and more coherence
Re: [abcusers] V: field
Frank Nordberg a skrivas: James Allwright wrote: On Sun 19 Nov 2000 at 11:02PM +0100, Jean-Francois Moine wrote: Also, about playing, it would be nice to have more than one MIDI channel per voice (any idea James? :). If you mean voices should be polyphonic, then you needn't worry - MIDI channels are already polyphonic. I think Jean-Francois meant it the other way round. That it ought to be possible to play the same voice through two or more midi channels simultaneously. Right, I was thinking about organ stuff :). On a pipe organ, the sound may be changed only by adding or removing whole ranges of pipes called 'stops' (when you press a key, one or many pipes play simultaneously). In MIDI, these are the channels. So, in ABC, it would be nice to have such a (dynamic) stop/channel definition. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** | http://moinejf.free.fr/ Pépé Jef| please, on reply, mailto:[EMAIL PROTECTED] |or mailto:[EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: field
James Allwright wrote: On Sun 19 Nov 2000 at 11:02PM +0100, Jean-Francois Moine wrote: Also, about playing, it would be nice to have more than one MIDI channel per voice (any idea James? :). If you mean voices should be polyphonic, then you needn't worry - MIDI channels are already polyphonic. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html I think Jean-Francois meant it the other way round. That it ought to be possible to play the same voice through two or more midi channels simultaneously. Frank Nordberg To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: field
On Tue, 14 Nov 2000, Phil Taylor wrote: James Allwright wrote: When I first introduced the V: field into abc2midi, the syntax was very simple: V:voice number Since then, people have added extra fields after the voice number, which is where the complication arises. Could we all agree on this first bit ? Simple parsers can then just ignore extra fields. When I added the V: field to BarFly I considered that the voice which follows a V: label was a part of the field, so I allowed it to follow on directly after the space which delimits the number. This is nice, because the voices get grouped closely together, and you can align the notes vertically to make it easy to see which notes are playing simultaneously. If you do this, however, you do have to allow inline fields in the bit of the tune on the same line as the V: field. BarFly doesn't require this; you can write the music either on the same line as the V: field or on the following line, but the former makes for compact and readable music, and I would like to retain it as an option. (It's not difficult to program; you just have to treat a space following the voice number as equivalent to a line end.) So then why not use inline V: fields for this case? [V: 1] ab g2 | fe [V: 2] g2 bf | d2 Looks neat and does not require music in a field (which is IMO *very* clumsy). Viele Gruesse, Henning Kiel [EMAIL PROTECTED] To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: field
Henning Kiel wrote So then why not use inline V: fields for this case? [V: 1] ab g2 | fe [V: 2] g2 bf | d2 No real reason except that it takes a couple of extra symbols, and involves placing an inline field at the start of a line, which seems a bit redundant. Looks neat and does not require music in a field (which is IMO *very* clumsy). The trouble is that the music IS a field - for some reason Chris didn't give it a field identifier separate from K:, and that in turn has led to various problems with the order of fields which can precede or follow K:, like P: and M:. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: field
On Tue, 14 Nov 2000, Phil Taylor wrote: John Atchley wrote: On Tue, 14 Nov 2000, Phil Taylor wrote: as an option. (It's not difficult to program; you just have to treat a space following the voice number as equivalent to a line end.) Doing so would blow all the abc with V:1 clef=bass (used by abcm2ps and very common in multi-voice abc files) right out of the water. V:1 clef=bass blows BarFly out of the water! If you want to change clef in BarFly you have to do it in a K: field, so you would write that as V:1 [K:bass] or V:1 [K:clef=bass] or V:1 K:bass etc. That kind of illustrates the point I was making, that "it's not difficult to program" is a bit of an oversimplification ;-) The fact is that we have an awful lot of music out there using both styles, so any solution has to at least offer a chance of getting it right for files written both ways. It seems the way to handle this is to update the standard to permit either method (and to standardize it before we end up with another dozen or so variations) and leave it up to software (probably with user-definable configuration) to decide which syntax is in use for any given file. -- John Atchley -- http://www.guitarnut.com http://www.guitarnuts.com So many guitars, so little time... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: field
Phil Taylor wrote: Would you then expect a K: field in multivoice to affect all voices simultaneously? It's not the case in BarFly, since you can have simultaneous voices playing in different keys. (I haven't actually found any use for this, but it might come in handy if I ever get avant garde.) Yep -- quite a bit of polytonal music (such as that of Charles Ives) uses this a great deal. Currently, as far as I know, all the programs out there treat K: as applying to the current voice only, and I think it would be a good idea to keep it that way. Not doing so would basically make handling more modern music impossible. Also, even in Baroque music, you have clarinets notated (albeit not played) in a different key from C-based instruments. But maybe that's getting into clef transposition -- a kettle of fish I'd rather not plunge into just at the moment. :) - Eric -- ---=---=-=-==-===-=//===//=-===-==-=-=--= - "God is real, unless // Name: // Eric Galluzzo // [EMAIL PROTECTED] declared integer." // WWW: // http://w3.one.net/~eng/ -- Unknown // Work: // Synchrony // Product Engineer ---=-=-==-===-=//===//=-===-==-=-=--= - To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V: field
hi I'd tried many times to un subscribe with no success. Can someone pleazse remove me? Thanks Steph At 21:28 14/11/00 -0500, you wrote: Phil Taylor wrote: Would you then expect a K: field in multivoice to affect all voices simultaneously? It's not the case in BarFly, since you can have simultaneous voices playing in different keys. (I haven't actually found any use for this, but it might come in handy if I ever get avant garde.) Yep -- quite a bit of polytonal music (such as that of Charles Ives) uses this a great deal. Currently, as far as I know, all the programs out there treat K: as applying to the current voice only, and I think it would be a good idea to keep it that way. Not doing so would basically make handling more modern music impossible. Also, even in Baroque music, you have clarinets notated (albeit not played) in a different key from C-based instruments. But maybe that's getting into clef transposition -- a kettle of fish I'd rather not plunge into just at the moment. :) - Eric -- ---=---=-=-==-===-=//===//=-===-==-=-=--= - "God is real, unless // Name: // Eric Galluzzo // [EMAIL PROTECTED] declared integer." // WWW: // http://w3.one.net/~eng/ -- Unknown // Work: // Synchrony // Product Engineer ---=-=-==-===-=//===//=-===-==-=-=--= - To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html The joy of the Lord Jesus Christ is my strength, I will rejoice in him always, for he is my fortress and rock and I can do all things through Christ who gives me strength To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] V: field
On Mon 13 Nov 2000 at 10:42AM +, Phil Taylor wrote: I think the answer to the first part is "sporadically". It is indeed a great lack of the current draft that the V: field is not discussed. The problem is that this is a very complicated extension, and nobody seems to want to sit down and write a draft proposal for it. There are already several mutually-incompatible variants about, which will have to be resolved. When I first introduced the V: field into abc2midi, the syntax was very simple: V:voice number Since then, people have added extra fields after the voice number, which is where the complication arises. Could we all agree on this first bit ? Simple parsers can then just ignore extra fields. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] V:
| Muse has handled V: for long enough that I've forgotten how long | ago I did it. Memory getting weak in old age, eh? Anyhow, this reminds me of something that I started some time back and haven't collected much data for: http://trillian.mit.edu/~jc/music/abc/doc/ABCfeatures.html The Muse entry for V: lines has been duly changed to "Yes". There is also the question about which of the various proposed forms of the V: lines are supported. My table currently lists only the name= and clef= fields. Maybe I should try to dig up a list of all that have been proposed and/or implemented and add them to the table. Another question: How many branches to abc2ps are there now? I'd like to know about any that are available on the Net, and the best URL to download them from. Then there's the problem of putting such a spreadsheet up on a web page. It might get rather wide ... -- Modern GUIs are very well designed, for people with three hands. The real problem has been how slow customers have been to make necessary hardware upgrades to meet the requirements of the software. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
