>We've been over this before, but back when BarFly was the only >application to support both parts and multi-voice playback. So >maybe other implementations have moved on enough to merit a re-run.
In order to understand why BarFly won't do what you want I'll have to explain how it works. The program has two separate parsers for playing and display, and they work quite differently from one another. The play parser runs through the abc ignoring anything that isn't required for playing (e.g. beams). It generates a list of midi codes and times, which can subsequently be assembled into a Quicktime tune or a midi file or whatever. It can't be started or stopped in mid-parse, but it can be instructed not to generate output from some parts of the tune, so you can do Play from Insertion Point or Play Selection. When playing multi-voice tunes it only parses one voice at a time, seeking each V: field with the appropriate voice number and skipping over the other voices. It gets called multiple times to assemble the complete tune for voice 1, then voice 2 etc. until it has the whole thing. When playing a single voice tune with parts it also gets called multiple times, once for each part in the order specified in the header. In this case it parses the whole tune, but suppresses output generated by abc outside of the requested part, and the output is added at the end of the previous list to generate the whole tune. If it has to deal with both multivoice and parts it deals first with voice 1, part A, then voice 1 part B etc. until it has voice 1 complete, then goes on to voice 2 part A. The reason why your example won't work: >X:1 >T:Drink to me only. >T:2 Flutes. >M:6/8 >L:1/8 >Q:3/8=60 >P:ABA >K:A >P:A >[V:1] ccc d2d|(ed)c (Bc)d|(eA)d c2B | HA6 :| >[V:2] AAA B2B|(cB)A (GA)B|(Ac)B A2[EG]|[HC6HA6]:| >% >P:B >[V:1] e|ece a2e|(ec)e e2e | f2e d2c | (c3 B2):| >[V:2] c|cAc c2c|(cA)c c2c | d2c B2A | (A3 G2):| is that when parsing voice 1 part A, when it gets to the end of the first line and encounters [V:2] it skips ahead to find the next [V:1] field. In doing so, it misses the P:B field, since it is not contained within voice 1. In fact, the P:B field is contained only within voice 2, at the end of the first line. The display parser takes exactly two passes through the tune. On the first pass it just determines where the line ends are, and how many symbols are to be drawn on each line. On the second pass it draws each symbol to the screen. If it's single-voice abc there is no internal data structure to represent the music. If it's multi-voice then the output is accumulated into a set of linked lists until it has a complete block of staves, then the horizontal positions of the symbols are adjusted to align them according to their times, and the vertical positions of some symbols are adjusted to avoid conflicts. Each block is then drawn, and the data structure is destroyed ready for the next block. So the display parser reads the complete tune from top to bottom as a human would, and your part labels in the above example work fine because both of them immediately precede the staff where they are to be drawn. The main reason why I did things the way I did was speed. Nobody minds if they tell a computer to play and it takes a second or two before the sound starts, but if you are typing the abc and there's a second or two of dead time after each keystroke you're not going to bother. The program was written to be used on a 25MHz Mac IIci, and it's still usable on that machine. The play parser was written first, and at that time it didn't have to deal with multivoice abc - that was a later modification. Both parsers have their disadvantages. As you've pointed out, the positioning of part fields required to make them play properly is too strict, and doesn't make sense unless you know how the parser works. Likewise, the display parser can only deal with abc where the lines of abc are entered in the order in which they are to be displayed. However, fixing these problems will require a complete re-write, and we're talking about half a million lines of code here (Pascal is a verbose language). Maybe when I get to version 2.0 I'll do it. I'll write a single parser which assembles the whole tune into a data structure, with separate output routines to generate midi or pictures of the staff notation. It will be a lot slower, but by that time even you will be using a machine fast enough. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
