On Sat, 2003-07-05 at 19:21, I. Oppenheim wrote:
On Sat, 5 Jul 2003, John Walsh wrote:
My first reaction is that ! is better, since in !ppp! it is
used as a delimiter, and delimiters are tall and skinny, while * is
short and fat.
This is also my fealing. I'd rather make * the
On Sat, 2003-07-05 at 10:37, Phil Taylor wrote:
Eric Galluzzo wrote:
All programs, to my knowledge, that implement the !...! construct
(abcm2ps, jcabc2ps, and abc2midi?) are under active development, to my
knowledge. Therefore, all of them could easily be altered to accept *
as the
on 7/5/03 9:10 PM, John Walsh wrote:
Well, if \ is the symbol for continuation, which tells
the program Don't feel you have to put a linebreak here,
you could have \\ for and I really mean it.
I have to admit I haven't taken the time to fully understand all the ins and
out of the codepages
I've always thought of the %% construct as being for new and
experimental stuff, which is always going to break other programs, so
if the staves command becomes standard I would prefer that it got it's
own field identifier.
I had always thought %% was for commands specific to a particular
Tom Keays wrote:
Perhaps, despite the widespread instances of ! as
line-breaks, it would be better to use * for this -- making * the
equivalent of ! and deprecating ! (if you can deprecate something that
wasn't in the standard to begin with) -- rather than messing with changing
the !...! usage.
From: John Walsh [EMAIL PROTECTED]
Date: Sat, 5 Jul 2003 18:10:28 -0700 (PDT)
Irwin Oppenheim wrote:
So if * serves as the !break! command, what symbol
could we use for the !nobreak! command that was
proposed by Laura?
Well, if \ is the symbol for continuation, which tells
Eric Galluzzo writes:
|
| So: how about that we agree that U:T = trill type notation is
| acceptable, and put into the standard? We could simply state that it is
| a symbol binding, or redefinition, or whatever we want to call it. It
| would apply to player programs as well as
John Chambers wrote:
Eric Galluzzo writes:
|
| So: how about that we agree that U:T = trill type notation is
| acceptable, and put into the standard? We could simply state that it is
| a symbol binding, or redefinition, or whatever we want to call it. It
| would apply to player programs as
Date: Sat, 05 Jul 2003 09:07:33 +0200
From: Bert Van Vreckem [EMAIL PROTECTED]
Jeff Bigler wrote:
I would find it particularly useful to have an explicit linebreak
command that would override the continue all line ends (append '\')
option to the abc2ps-like programs. Usually, I want
On Sun, 6 Jul 2003, Jeff Bigler wrote:
1) Newline continues to signify a linebreak unless preceded by \
This can be overridden by the software. (E.g., the -c option in
abc(m)2ps).
2) An additional explicit linebreak command (e.g., !) signifies a
linebreak that *cannot* be
Saving two chars of typing in a definition doesn't seem to
be a good payoff for eliminating most of the uses of a new
feature.
I agree on that.
Irwin
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Date: Sun, 6 Jul 2003 20:55:33 +0200 (W. Europe Daylight Time)
From: I. Oppenheim [EMAIL PROTECTED]
On Sun, 6 Jul 2003, Jeff Bigler wrote:
1) Newline continues to signify a linebreak unless preceded by \
This can be overridden by the software. (E.g., the -c option in
on 7/6/03 2:55 PM, I. Oppenheim wrote:
If there exists an explicit linebreak command, there is
no reason why a bare newline should continue to imply
a linebreak.
You're getting away from the original intent of abc and one that most of the
musicians in this group, I think, still want to retain
On Sun, 6 Jul 2003, Eric Galluzzo wrote:
In practice, I have found that I usually don't include that many
dynamics on one line, so most Y: lines (at least in my music) would
probably end up looking something like this:
Y: | | * p | | * ( |
That's exactly the reason
on 7/6/03 3:03 PM, Jeff Bigler wrote:
If there exists an explicit linebreak command, there is
no reason why a bare newline should continue to imply
a linebreak.
I can think of two reasons.
a) There's a lot of ABC already in existence that depends on that
assumption.
b) It's nice to
On Sun, 6 Jul 2003, Jeff Bigler wrote:
And a picky semantic point, but one that I think is important. I
believe the continue the current line if there's room command is not
just \, but \ + newline
That is indeed important to remember.
However, we might have to interpret \ + whitespace +
on 7/6/03 3:16 PM, I. Oppenheim wrote:
\\ will be equivalent to !break!
* will be equivalent to !nobreak!
But * is already part of the standard as a right-justified linebreak and
I've seen plenty of tunes that use it. Furthermore, \ is already used as a
continuation so having \\ as a
On Sun, 6 Jul 2003, Tom Keays wrote:
You're getting away from the original intent of abc
i.e., that the abc transcription be HUMAN-readable.
Humans don't require explicit !break! commands if
there is a newline.
That is exactly my point: most ABC users cannot care
less where the exact
on 7/6/03 3:33 PM, I. Oppenheim wrote:
a) There's a lot of ABC already in existence that
depends on that assumption.
As I said already, I seriously doubt that. Tunes for
which the linebreaks are important for some reason or
another, should make them explicit.
No really. Look at all the
On Sunday 06 July 2003 8:33 pm, I. Oppenheim wrote:
a) There's a lot of ABC already in existence that
depends on that assumption.
As I said already, I seriously doubt that. Tunes for
which the linebreaks are important for some reason or
another, should make them explicit.
As Tom says,
Irwin Oppenheim wrote:
1/ Is this definition your own, private proposal, or is
it based on a (preliminary) draft prepared by Guido?
It's my own preliminary proposal. I haven't received anything from
Guido. Of course it has to be modified, but it's a starting point,
because most of it will be
Phil Taylor wrote:
You've still got this back to front. The U: definition does
not replace a wordy annotation with a single letter - it tells
the program what that single letter means. That is not a macro,
nothing is being replaced in the text.
Phil, I've got a question for you, since I've
Tom Keays wrote:
No really. Look at all the Irish tunes on the web that are set in phrases
of four or eight bars so that you can see the patterns in the tunes.
Well in the case of my transcriptions this is not important to me.
Most of them happen to have 4 bars per line in the abc, but that's
In message [EMAIL PROTECTED], Tom Keays
[EMAIL PROTECTED] writes
on 7/6/03 3:16 PM, I. Oppenheim wrote:
\\ will be equivalent to !break!
* will be equivalent to !nobreak!
But * is already part of the standard as a right-justified linebreak and
I've seen plenty of tunes that use it.
Is *that*
on 7/6/03 5:21 PM, Henrik Norbeck wrote:
Phil, I've got a question for you, since I've never tried BarFly myself.
How do you actually treat the macros when it comes to playback
and printing.
m: ~G3=G{A}G{F}G
Is that only for playback? Or do you use it for printing too?
You go to Viewer
On Sun, 6 Jul 2003, Henrik Norbeck wrote:
It's my own preliminary proposal. I haven't received anything from
Guido. Of course it has to be modified, but it's a starting point,
because most of it will be as it is there.
Thank you for your good work.
Well, it's case sensitive. ABNF quoted
I have a need for ABC modules -- something I can embed into my own app
- which can
both play and print/display a single staff in real time.
My proposal is this:
Develop a modular system of core components which can then be used
a) by stand-alone app developers, and
b) by other developers who
On Sun, 6 Jul 2003, Jeff Szuhay wrote:
I'm thinking along the lines of an ABCParse module
which feeds a stream to both ABCPlay module and
ABCView modules.
You're thinking about creating a libabc project? that
would be very cool!
Maybe we could form some group of developers that could
isolate
Historical note: the first versions of abc2mtex used musciTeX---a
music macro package for TeX---which did not automatically justify lines.
You had to explicitly ask it to right-justify, and in order to make this
look right, you had to adjust the note-spacing a bit. It took some work.
I. Oppenheim wrote:
If the ABC community as a whole could provide a
standard complying parser, not every developer that
wishes to use ABC would have to reinvent the wheel
again and again. The current situation is in nobody's
interest.
We're already there: using Henrik's BNF spec, a developer can
Henrik Norbeck wrote:
Phil, I've got a question for you, since I've never tried BarFly myself.
How do you actually treat the macros when it comes to playback
and printing.
m: ~G3=G{A}G{F}G
Is that only for playback? Or do you use it for printing too?
You can enable macros separately for display
The standard can be set to say that !...! is a special symbol, and
developers can programs to read files on that basis UNLESS the
header contains abc2win in which case it is a line break!
Someone tell me that life really could be that simple!
It isn't. I really want mid-line ! linebreaks
| I play a lot of folk dance music which consist of phrases of 8 bars.
| When linebreaks are every 4 or 8 bars, this makes the score more
| readable.
I think that dance musicians usually really like having the phrases
aligned this way, but most other musicians don't see the benefit
(and
[abcm2ps's !...! construct]
So, why not pick a symbol other than ! for the latter usage?
* seems ideal, and quite logical, too: in emails, IRC, etc.,
it is commonly used to boldface or emote something.
My first reaction is that ! is better, since in !ppp! it is
used as a delimiter, and
Usually, I want the program to just decide where to put the line
breaks, with a few rare exceptions.
The solution I'm coming up with on the next release of Music Publisher
is to provide an editing screen where changes can be made to abc file
before use. And including a reflow command for bars
Jack Campin writes:
| Perhaps it might make it clearer why I'm being so insistent about
| this if I explain what most of my time using ABC is spent doing.
| I spend about a full day a week in the National Library of Scotland
| researching things, mostly tunes, which are copied in ABC using a
|
36 matches
Mail list logo
