[abcusers] Ted Merrill's suggestions

2000-11-19 Thread Jack Campin

What Ted is suggesting is more or less what the Cornell Synthesiser
Generator was designed for; give it a lexis and an attribute grammar
and it'll build you a lexer, parser and structure editor.  (I once
supervised a student implementing an analogue of the CSG in a higher-
order persistent programming language; it worked but you had to be
rather patient waiting for the lexer optimizer to do its thing, and
the GUI primitives available for the editor were a bit spartan).

I am not too sure how much I'd like to work with ABC in a structure
editor.  I've only used two of those, loved one (Steven Vickers' Forth
for the Z80-based Jupiter Ace) and hated the other (a Dutch Pascal-
meets-Logo programming language called ABC with a horrendously self-
righteous Dijkstroid built-in methodology that made restructuring
your code a nightmare).

Is the CSG still around?  Anybody else out there used it?

=== http://www.purr.demon.co.uk/jack/ ===


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



Re: [abcusers] accidentals in ()

2000-11-19 Thread John Walsh

Laura Conrad writes:

 John seems that some people here are saying that in some cases cautionary
 John accidentals ARE musically significant.  

No, I think what we're saying is that cautionary accidentals are easy
to confuse with editorial accidentals, which *are* musically
significant. 

In my case, it's one of the things that makes lilypond easier to use
for my purposes than ABC -- I'm not willing to enter editorial
accidentals into my transcriptions unless I can distinguish them from
the ones in my sources.  


Let's see if I understand the problem.  There seem to be several
different forms of accidentals, such as editorial accidentals and
cautionary accidentals, which are played differently, but are the same on
sheet music.  (Or conversely, there are forms, e.g. ordinary and
cautionary, which are played the same way but appear differently on sheet
music.)  We would like to have all of these kinds in abc.  But we don't
have a great amount of unclaimed notation to spare.

 To me, this would seem to be a good place for user-defined
symbols. If there were a construct, say !accidentals_in_prens! built into
abc, one could use the U: field to assign it to one of the free
characters H--Z. That is, one could write, say, 
U:P=!accidental_in_prens!
for instance, and then, whenever such an accidental came up, just
write P before it. 

 The advantage here is that something like !accidental_in_prens!
only appears in the headers and doesn't need as compact a notation as
something which appears in the abc: it only uses existing notation
in the tune body. If one wants to distinguish between cautionary and
editorial accidentals (which I gather are similar on sheet music) one
can also define U:Q=!accidental_in_prens! and then write Q before
the editorial accidentals, P before the cautionary accidentals, and
thereby preserve the difference in the abc source. (The difference in
playback can be taken care of in the m: field.) 

 The same thing could be done for optional notes mentioned earlier
in this thread, which are sometimes written in parentheses. That is, one
could build in something like !note_in_prens! and assign it a letter
in the U: field.

I haven't checked, but I think this can already be done in
abc2mtex by writing a couple of musictex macros.  It is certainly the
first thing I'd try if I needed it.

 HmmmI foresee someone objecting that if we have something as
clumsy as !accidental_in_prens! around, people will use it in the body of
the tune instead of the header. I doubt it'll happen often, but one could
avoid it entirely by decreeing that commands enclosed by, say, double
bangs, e.g. !!foo!!, can only be used in headers, and not in the tune
body, and use that convention for these additional commands.

Cheers,
John Walsh

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