Anselm Lingnau wrote:

>Phil Taylor wrote:
>
>> BarFly's macro processor does take lengths.  You have to write
>> a separate macro for each length of note.  The reason for this
>> is that an ornament which sounds right on a half note is often
>> wrong on an eighth.
>
>I'm confused now. Suppose I had definitions for `Mn' and `Mn2'. What
>would happen (a) for `Mc' (b) for `Mc2' (c) for `Mc4' in the body of
>a tune? The interesting point is whether the `n' includes a length or
>not.

(a) and (b) will expand, (c) will not, since there is no macro definition
for that length. 'n' does not itself include the length, but the length
(if any) is part of the target string.

>> What the current Barfly version
>> does when it encounters a macro on a note with an accidental is to place
>> the accidental on the first ocurrence of the principal note in the
>> expansion. [...]
>>
>> BarFly doesn't do this; rather it expands the macros in reverse order
>> to the order in which the definitions are listed.

Actually, thinking about this some more, it would be possible to sort
the macro definitions into order before expanding them, provided that
you used a sort algorithm which is guaranteed not to change the order
of elements which are the same size.  Since the list of macros to be
expanded is never going to be very big you could just use a simple bubble
sort.

>I've put a version of abcmac which is fixed in these two respects on my
>web page at `http://anselm.our-isp.org/abcmac/abcmac'.
>
>> Maybe we can get abc2midi to process the Goldberg Variations?
>
>We could try ...
>

If there's the possibility of other programs handling the macros, I'll
fix the V: fields to be inline once I release the next version of
BarFly (the current version won't work with that syntax).  The postscript
programs will still only be able to display it with the ornaments
written out in full, which is highly illegible.

I wasn't able to test the script, unfortunately.  I had installed a new
hard drive in my machine and simply copied all my stuff over to it.
MacPerl has got itself into a fankle and can't find its libraries
any more (perl5lib not found in @IN), despite the fact that perl5lib
is certainly there, and the correct pathname is in the preferences.
I downloaded and installed a new version which comes as a single
standalone application, with all the libraries compiled in, and that
didn't work either, objecting to 'strict', right at the beginning of
the script.  Us Mac users don't have a lot of fun with perl.  Every
time I try to use it I end up concluding that it would be quicker
to write a program in C or Pascal to do the job.

Phil Taylor


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Reply via email to