Jack Campin wrote: >> Each voice is a completely separate tune, so they can have different >> default note lengths (common), metres (rarely) and even keys. Not >> sure about tempo though, since all the voices have to play together. > >I've never been able to predict exactly what BarFly will do with such >constructs, so I've generally written them using the explicit [..] >notation: [V:1 L:1/8] etc. A bit verbose, unreadable on anything less >than a twenty-inch monitor, but semantically harmless.
Got to put them in separate square brackets, too, so it has to be [V:1][L:1/8] or V:1 L:1/8 (which is even more unreadable). >But your decision that "each voice is a completely separate tune" is >not implied in any way by the original standard and makes ABC simply >unusable for many purposes. Neither the original standard nor any subsequent draft even mentions multivoice abc, let alone the way in which P: fields interact with V:, so we're out on the bleeding edge here. Do any programs other than BarFly even attempt to deal with part- order playing in multivoice abc? abc2midi is the only likely candidate, I think. >I wanted to transcribe some Klezmer tunes >from the Manchester Klezmer site: I can't do it using BarFly. Some >are in forms like ABACA and in two voices. There is no way to write >that in BarFly without copying part A out three times: you don't let >the part construct name sections of *music*, only segments of a single >voice. I don't want to be responsible for ABC written so redundantly, >so I'm not doing the transcriptions until BarFly's semantics for P: is >changed to handle it. Of course you don't have to write part A out three times; what you do have to do is make sure that the P: field appears in the corresponding place in both voices, like this: P:ABACA K:D [V:1][P:A] abcd abcd |] [P:B] ABCD ABCD |] [P:C] DCBA DCBA |] [V:2][P:A] cdba cdba |] [P:B] DCBA DCBA |] [P:C] dcba dcba |] >What ought to happen is that any section delimited by a P: line should >behave like a separate tune, except that when it gets played is controlled >by the P: line in the header, and what follows the P: on that line may >be in a different typestyle from the contents of a T: line. > >Practically, I use that semantics all the time when assembling or >disassembling sets of monophonic tunes: interchange T: and P: and >you're nearly done. BarFly's present semantics makes that impossible >for anything with more than one voice. > >And I can't think of *any* music that's more easily notated by making >V: global to P:. There is a more general problem here, in that most fields can be either global or local within multivoice abc, except that we need a way of marking them out as one or the other. I've made fields within the tune local only, which can cause some confusion. I get queries from users which say "Why doesn't this work": M:4/4 K:C [V:1] ... [V:2] ... M:3/4 K:G [V:1] ... [V:2] ... (What happens is that the key and metre changes only appear in the second voice) You have to remember that when the tune is being parsed for playing, the program reads the whole of voice 1 first, then the whole of voice 2. On the first pass, it doesn't see the in-tune fields at all, because they follow on from voice 2. One solution would be to introduce a marker for regions of the tune where everything is considered to be global. You could reserve voice number zero for this purpose: M:4/4 K:C [V:1] ... [V:2] ... [V:0] M:3/4 K:G [V:1] ... [V:2] ... or perhaps make it V:G. It's a seriously difficult parsing problem, whatever you do. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
