>: Most of
>: the information fields are for use within a tune header but in
>: addition some may be used in the tune body, or elsewhere in the
>: tune file.
> This is not a widely implemented feature of the abc standard and I
> would personally like it to become deprecated. My reasoning is t
James Allwright writes:
| > They're in the 1.6 standard for other header fields:
| >
| > : Most of
| > : the information fields are for use within a tune header but in
| > : addition some may be used in the tune body, or elsewhere in the
| > : tune file. Those which are allowed elsewhere can
> "James" == James Allwright <[EMAIL PROTECTED]> writes:
[about global header fields]
James> This is not a widely implemented feature of the abc standard and I
James> would personally like it to become deprecated. My reasoning is that
James> if you have global fields, you can't t
On Fri 23 Nov 2001 at 11:24PM +, Jack Campin wrote:
>
> > The extra 'per file definition fields' seems like quite a major
> > extension to ABC to me, I don't think we have anything quite like
> > that at the moment, and I'm not convinced about the need to add it
> > for this.
>
> They're in
Russian words
would work just as well (medleno etc - excuse the wrong font!).
Laurie
- Original Message -
From: James Allwright <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 23, 2001 10:14 AM
Subject: Re: [abcusers] something really simple
> On Thu 2
Hello,
James Allwright wrote:
> Conflicting standards are an unfortunate thing, but I don't think they
> condemn us to forever fudging the issue and not adopting some standard.
> We already have abitrary default tempos fixed into all playback programs,
> so a new set of imperfect tempo settings
Hello,
Bob Archer wrote:
(...)
> It's not uninterpreted text, it's text with a meaning. We already have
> the Q field which provides a computer readable indication of the
> speed usable by player programs. We now have this field to provide
> a textual description for display programs.
(...)
> A p
James Allwright wrote:
> On Thu 22 Nov 2001 at 04:52PM +, Jack Campin wrote:
> > No it isn't. A typical dance tune book will use "reel time" or "waltz
> > tempo" the same way all through. In the Kurdish song book I quoted,
> > the same Italian tempo terms are used over and over again and are
On Thu 22 Nov 2001 at 04:52PM +, Jack Campin wrote:
>
> No it isn't. A typical dance tune book will use "reel time" or "waltz
> tempo" the same way all through. In the Kurdish song book I quoted,
> the same Italian tempo terms are used over and over again and are NEVER
> defined at the begi
Jack Campin wrote:
> The problem is how to use textual descriptions of numerical playback
> speeds in ABC.
So as I said it:
there are two parts in this proposal:
1)displaying textual tempo definitions (the first five lines of Jacks
proposal)
I think its obvious that everybody finds this a good
Jack Campin <[EMAIL PROTECTED]> wrote:
> >In an attempt to wrap up this thread, would the following proposal
> >for a new field meet everyone's requirements ?
> >
> >Field Name: q:playing style
> >Header: Yes
> >Tune Body: No
> >Description: Contains a written non-numerical description of the
> >
>> Unless your "q:" field provides me with a way of DEFINING those strings
>> in a musically intuitive way so that a numerical playback speed can be
>> statically deduced from the musical text (e.g. by a playback program),
>> there is no point in what you're suggesting. There are already about
>>
On Thu 22 Nov 2001 at 12:22AM +, Jack Campin wrote:
>
> That says exactly nothing about the semantics.
>
> Unless your "q:" field provides me with a way of DEFINING those strings
> in a musically intuitive way so that a numerical playback speed can be
> statically deduced from the musical te
On Wed 21 Nov 2001 at 01:41PM -0500, Buddha Buck wrote:
> At 03:40 PM 11-21-2001 +, James Allwright you wrote:
>
> >In an attempt to wrap up this thread, would the following proposal
> >for a new field meet everyone's requirements ?
> >
> >Field Name: q:playing style
> >Header: Yes
> >Tune Bo
>In an attempt to wrap up this thread, would the following proposal
>for a new field meet everyone's requirements ?
>
>Field Name: q:playing style
>Header: Yes
>Tune Body: No
>Description: Contains a written non-numerical description of the
> tune's tempo or "mood".
>
>Examples:
>
>q:Allegro
>q:
At 03:40 PM 11-21-2001 +, James Allwright you wrote:
>In an attempt to wrap up this thread, would the following proposal
>for a new field meet everyone's requirements ?
>
>Field Name: q:playing style
>Header: Yes
>Tune Body: No
Would this make it impossible to transcribe music which is suppo
In an attempt to wrap up this thread, would the following proposal
for a new field meet everyone's requirements ?
Field Name: q:playing style
Header: Yes
Tune Body: No
Description: Contains a written non-numerical description of the
tune's tempo or "mood".
Examples:
q:Allegro
q:Lento
James
John Walsh <[EMAIL PROTECTED]> writes:
> Some programs (abcmus for sure, and judging by other comments in
> this thread, Barfly, probably others too) use the R: and M: fields to
> determine the tempo (and, more, a stress program) which can be modified by
> the user as desired. It's a great
Anselm Lignau writes:
>Yes, but the whole point of Jack's original proposal was for people to
>be able to define the meanings of these terms themselves, in a manner
>appropriate to the music they were working with. The suggestion to
>hard-code a selection of `tempo terms' (a bad one, IMHO) came f
Frank Nordberg wrote:
> My favorite tempo indication is "A little too fast" ;-)
Which beats mine, which is: "So rasch wie möglich"
e.
--
Ewan Macpherson <[EMAIL PROTECTED]>
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Buddha Buck wrote:
>
> I have a songbook at home in which the composer chose a different English
> tempo description for every song -- about 60 all told.
My favorite tempo indication is "A little too fast" ;-)
Frank Nordberg
http://www.musicaviva.com
To subscribe/unsubscribe, point your browser
Simon Wascher <[EMAIL PROTECTED]> writes:
> there are french baroque tempo definitions, german expressionist tempo
> definitions , tempo definitions in all languages of the world which *do*
> have their regional value.
> It would really be extremly rigid to stuck with those oldfashioned
> classi
> ...(at what speed is "Ecumenically"? or
> "Elementally"). ...
Ecumenically would have to be a speed that made everyone happy or at least
that no schism of the church objected to greatly.:-)
Not sure about the other one.
Laurie
To subscribe/unsubscribe, point your browser to: http://ww
At 02:43 PM 11-19-2001 +, James Allwright you wrote:
>On Mon 19 Nov 2001 at 01:34PM -, Laurie Griffiths wrote:
> >
> > Some people (I think it was Frank that started it) say (and I'm putting
> > words into their mouths) "Look, the Q: syntax is all very well for
> > controlling the speed of
James Allwright wrote:
>
> I'm willing to bow to Frank's superior knowledge here.
Thanks :-)
>
> The conclusion is
> that tempo indicators are essentially random text and it is not worth
> our while attempting to codify them so they can be translated into
> numerical meanings.
In other words -
On Mon 19 Nov 2001 at 04:26PM +0100, Frank Nordberg wrote:
>
>
> James Allwright wrote:
> >
> > I think we need to know whether "Allegro" is one of a small set of
> > well-defined tempo descriptors (in which case it would be really nice
> > to have the complete set together with their definitio
(*) I never write in Italian.
- Original Message -
From: James Allwright <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 19, 2001 2:43 PM
Subject: Re: [abcusers] something really simple
> On Mon 19 Nov 2001 at 01:34PM -, Laurie Griffiths wrote:
>
Laurie Griffiths wrote:
>
> James, we're at cross purposes here. In fact I think you are at
> cross-purposes with everyone else.
>
> We know that the existing Q: field works and it's well defined BUT
> Some people (I think it was Frank that started it)
It was Jack, actually.
James Allwrigh
> I belive it is not really neccessary to define the beat of allegro in
> Balkan music (like 3+3+2), I've never heard of such a definition in any
> other music notation context. And for sure it would be an abuse of the
> classical music's tempo word "Allegro".
I just fished out my copy of Maud K
Hello,
[EMAIL PROTECTED] wrote:
> On Mon, 19 Nov 2001, Simon Wascher wrote:
>
> > why if the beat changes with the meter, the meter (M:) isnt the field
> > which defines by its content (I do *not* mean to add an extention to
> > it) what Allegro (~120 beats per minute) means.
>
> However, if t
On Mon, 19 Nov 2001, Simon Wascher wrote:
> why if the beat changes with the meter, the meter (M:) isnt the field
> which defines by its content (I do *not* mean to add an extention to
> it) what Allegro (~120 beats per minute) means.
This has already been discussed. It is possible to take a r
James Allwright wrote:
> > I think we need to know whether "Allegro" is one of a small set of
> well-defined tempo descriptors (in which case it would be really nice
> to have the complete set together with their definitions) or one
> tempo definition in a large and vague set that spans the comple
On Mon 19 Nov 2001 at 01:34PM -, Laurie Griffiths wrote:
>
> Some people (I think it was Frank that started it) say (and I'm putting
> words into their mouths) "Look, the Q: syntax is all very well for
> controlling the speed of a player program, but what I want to be able to do
> is to say '
Hello,
Laurie Griffiths wrote:
> So we find we've begged some questions. OK, so Allegro is 120 per minute,
> but 120 of WHAT per minute?? It then became clear that if you are playing
> in 6/8 it would mean 120 3/8 notes but if you were playing in 2/4 it would
> mean 120 1/4 notes and if you wer
mple" matter of nailing it down and making a
decision!
Laurie
- Original Message -
From: James Allwright <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 19, 2001 9:09 AM
Subject: Re: [abcusers] something really simple
> On Fri 16 Nov 2001 at 04:
On Fri 16 Nov 2001 at 04:20PM -0800, John Walsh wrote:
> I haven't been following closely enough to be sure, but I have the
> impression that the idea of basing the tempo on the L: field has been
> pretty well discarded, except possibly as a legacy from abc 1.6 in the
> (deprecated) Q:120 sy
I haven't had time to follow this discussion closely recently. But I
have the impression this might be of interest at the present stage:
*
Reinlender
C
1/4=160
8
120 1.4
80 0.6
105 1.4
80 0.6
110 1.4
80 0.6
105 1.4
80 0.6
---
For those of you who doesn't know BarFly, this is a BarFly stress
I haven't been following closely enough to be sure, but I have the
impression that the idea of basing the tempo on the L: field has been
pretty well discarded, except possibly as a legacy from abc 1.6 in the
(deprecated) Q:120 syntax. True? I hope so, since it's an unstable
indicator: th
nt: Thursday, November 15, 2001 2:14 PM
Subject: Re: [abcusers] something really simple
> On Wed 14 Nov 2001 at 11:24AM -0500, [EMAIL PROTECTED] wrote:
> > On Tue, 13 Nov 2001, Laurie Griffiths wrote:
> >
> > > I'm not 100% sure what the right default is in the absence of a
&g
> "James" == James Allwright <[EMAIL PROTECTED]> writes:
>> I'd rather stay away from L:. A quick look through some of my collection
>> shows that it would give the wrong beat more often than not.
>>
James> Then presumably you are not using the Q: field as defined.
But we
On Wed 14 Nov 2001 at 11:24AM -0500, [EMAIL PROTECTED] wrote:
> On Tue, 13 Nov 2001, Laurie Griffiths wrote:
>
> > I'm not 100% sure what the right default is in the absence of a
> > "beat=". Is it the L value (explicit or implied)?
Yes. See the 1.6 standard. Q:100 means 100 unit note lengths p
Simon Wascher <[EMAIL PROTECTED]> writes:
> For reasons of scientific quality I need to include as much as possible
> information of the original source within the file, as near to the
> original as possible. So the file should be a representation of the
> playback *and* the the display.
The AB
Hello Anselm,
Now we surely brought it to the point what divides us deeply.
For reasons of scientific quality I need to include as much as possible
information of the original source within the file, as near to the
original as possible. So the file should be a representation of the
playback *and
Simon Wascher <[EMAIL PROTECTED]> writes:
> > The ABC representation of a
> > tune should give as much musical information as is reasonable but should
> > not specify how programs will make use of it.
>
> in certain cases it will have to allow exactly this in the future: For
> example by forcing
On Tue, 13 Nov 2001, Laurie Griffiths wrote:
> I'm not 100% sure what the right default is in the absence of a
> "beat=". Is it the L value (explicit or implied)?
I'd rather stay away from L:. A quick look through some of my collection
shows that it would give the wrong beat more often than no
Hello,
Anselm Lingnau wrote:
> I define `ad-hoc stuff' to be syntax that is used in one particular
> header field, such as `if there is a `-' after the metronome speed in a
> `Q:' field that means that the metronome speed is not supposed to be
> printed'. Why don't we allow a `-' after a composer
Laurie Griffiths <[EMAIL PROTECTED]> writes:
> The problem is that we want something that is completely compatible with
> everything that has gone before and that can be enhanced into the future
> with minimal new kludges. There is a tension between the two.
True. It turns out that most ABC hea
So how might it look using "key=value" and still trying to be easy to parse,
backward compatible, etc. Again I'm going to write examples +explanation
rather than BNF because I feel it helps debate at this stage.
% In file header (ONLY in file header so as to keep BarFly happy)
Q:Allegro con moto
Simon Wascher <[EMAIL PROTECTED]> writes:
> Bring up formal arguments and alternatives.
Well, guess what I have been doing for the last few days?
> As far as I observed the K: and V: field discussions where halted
> whitout a decision on the right syntax. but for me:
>
> Q:3/8=69 display=alle
overcomes my
objections to Anselms scheme (in another post, with luck).
Laurie
- Original Message -
From: Anselm Lingnau <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 11:47 PM
Subject: Re: [abcusers] something really simple
> Laurie Griffiths <
:-) Peace!
Anselm wrote "... So we get a `-' here and a mandatory space delimiter there
..." and actually that's pretty much how I felt about it myself (but I also
thought they were "the lesser evil" - we'll see how it works out, soo with
luck).
Simon wrote "please try to stay at the formal sid
Anselm Lingnau wrote:
>
> Laurie Griffiths <[EMAIL PROTECTED]> writes:
>
> > It's your turn to say what you find unacceptable in the proposal put forward
> > by me and Simon (the two were pretty much identical).
>
> As far as I'm concerned, the main problem with these proposals is that
> the sy
Laurie Griffiths <[EMAIL PROTECTED]> writes:
> It's your turn to say what you find unacceptable in the proposal put forward
> by me and Simon (the two were pretty much identical).
As far as I'm concerned, the main problem with these proposals is that
the syntax they define is pretty much particu
er in those tunes. I'm not 100% sure what the right default is in
the absence of a "beat=". Is it the L value (explicit or implied)?
Laurie
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 6:31 PM
Subject:
There is a complication here that I don't think anyone has addressed. By
defining "Allegro" as 1/4=120, whether this is done in the playback
software or in abc, you are assuming that "Allegro" is always based on a
quarter note beat. Therefore, alla breve allegro, with a half note as the
beat, wo
I have a worry about this definition and use thing. Our band has a book of
music, most of which is dance music (the rest is party pieces for
interludes). I want to spell out the tempo in "steps per minute" but for a
4/4 step-hop hornpipe this is 1/4 (for a step or a hop), for a 4/4 reel this
is
- Original Message -
From: Anselm Lingnau <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 3:00 PM
Subject: Re: [abcusers] something really simple
> Laurie Griffiths <[EMAIL PROTECTED]> writes:
>
> > > Q:1/4=120 note="
> I guess this is a bit like folk music, where the notes that are written
> down and the ones that actually get played are independent of each
> other :-)
Foul! Foul! Referee!! Throw him off the list!! :-)
L.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.ht
Hello,
Phil Taylor wrote:
> I don't see the necessity to specify in the abc what the program should do
> with the data. Surely (as Anselm has pointed out) these are local options
> to be set in a preferences file or command-line switch?
Even if so, it would be very helpfull to find a syntax tha
o: <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 12:40 PM
Subject: Re: [abcusers] something really simple
> Laurie wrote:
>
> >OK, Anselm, let me try.
> >First of all it is NOT complicated to implement. It's pretty easy.
> >Secondly a language or a not
Laurie Griffiths <[EMAIL PROTECTED]> writes:
> > Q:1/4=120 note="Pretty quickly" % [2] explicit tempo with advisory note
>
> OK acceptable but not my preference. "note" is a keyword that I scan for
> (no problem). The use of quotes immediately brings up the question of "what
> if the string i
On Tue 13 Nov 2001 at 08:13AM -0500, Laura Conrad wrote:
> > "Phil" == Phil Taylor <[EMAIL PROTECTED]> writes:
>
>
> Lilypond, which is the printing program I'm actually using these days,
> has a MIDI block and a score block, so the two speeds are actually
> completely independent unless you
> "Phil" == Phil Taylor <[EMAIL PROTECTED]> writes:
Phil> But why would you want to record your proofreading speed in the abc for
Phil> posterity? Surely you just want to override the given tempo using a
Phil> setting local to your program?
I might want to have a global proofrea
Simon wrote:
...
> PS: how do you like my actual proposal for the Q:field ? (besides the
> macro topic)
OK. Acceptable.
Laurie
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
In what lies below, Anselm wrote the bits with > at the start
>...
>The counter-proposal stands:
> Q:1/4=120% [1] explicit tempo specification
OK, No problem, backward compatibility etc.
> Q:1/4=120 note="Pretty quickly" % [2] explicit tempo with advisory note
OK acceptable but not my pr
Laurie wrote:
>OK, Anselm, let me try.
>First of all it is NOT complicated to implement. It's pretty easy.
>Secondly a language or a notation is not to be judged by whether or not you
>can say silly things. (Anyone who judged a natural language by this
>criterion would have to be barking in fac
Simon Wascher <[EMAIL PROTECTED]> writes:
> The problem is that there are situations where it is necessary to have
> part of the tempo indicator displayed and parts not.
>
> Example:
>
> Q:1/4=120 - Allegro % displaying "Allegro" and playing 1/4=120
>
> In your proposal how can this be d
OK, Anselm, let me try.
First of all it is NOT complicated to implement. It's pretty easy.
Secondly a language or a notation is not to be judged by whether or not you
can say silly things. (Anyone who judged a natural language by this
criterion would have to be barking in fact quite out of their
Laura Conrad wrote:
>> "Anselm" == Anselm Lingnau <[EMAIL PROTECTED]> writes:
>
>Anselm> I'm still waiting for you (or anybody) to explain why an
>Anselm> ABC tune should contain one prescribed explicit metronome
>Anselm> speed for display and another, different, prescribed
>An
Hello Anselm,
Anselm Lingnau wrote:
> Simon Wascher <[EMAIL PROTECTED]> writes:
> > Lets say you are right, its completely impossible that someone needs
> > that.
> I'm not claiming that it is impossible for anybody to need this. But if
> this is a sensible proposal then surely there must be an e
>Simon slipped in the words "external macro file".
>No!! I am very much against this. Although it may be convenient for
>writers of ABC it's horrid for readers. It makles it even harder to extract
>a tune and the probability would be very high that we should find orphan
>bits of ABC floating ro
Laura Conrad <[EMAIL PROTECTED]> writes:
> Anselm> I'm still waiting for you (or anybody) to explain why an
> Anselm> ABC tune should contain one prescribed explicit metronome
> Anselm> speed for display and another, different, prescribed
> Anselm> explicit metronome speed for pla
James Allwright wrote:
>
> What programmers cannot do is re-write applications retrospectively.
> Adding new syntax that is incompatible with the old syntax causes
> hassles for everyone who uses abc.
I understand that. In this case the problem would of course be older
programs that can't make s
> "Anselm" == Anselm Lingnau <[EMAIL PROTECTED]> writes:
Anselm> I'm still waiting for you (or anybody) to explain why an
Anselm> ABC tune should contain one prescribed explicit metronome
Anselm> speed for display and another, different, prescribed
Anselm> explicit metronome s
Simon Wascher <[EMAIL PROTECTED]> writes:
> Lets say you are right, its completely impossible that someone needs
> that.
I'm not claiming that it is impossible for anybody to need this. But if
this is a sensible proposal then surely there must be an example of an
application that requires it? O
Hello,
Laurie Griffiths wrote:
>
> Simon slipped in the words "external macro file".
> No!! I am very much against this. Although it may be convenient for
> writers of ABC it's horrid for readers. It makles it even harder to extract
> a tune and the probability would be very high that we shou
Anselm Lingnau wrote:
> Simon Wascher <[EMAIL PROTECTED]> writes:
> > Example
> > X:1
> > Q:n/n=n N/N=N andante
> I think this is much too complicated. I'm still waiting for you (or
> anybody) to explain why an ABC tune should contain one prescribed
> explicit metronome speed for display and anoth
Laurie Griffiths <[EMAIL PROTECTED]> writes:
> No!! I am very much against this. Although it may be convenient for
> writers of ABC it's horrid for readers. It makles it even harder to extract
> a tune and the probability would be very high that we should find orphan
> bits of ABC floating rou
Simon slipped in the words "external macro file".
No!! I am very much against this. Although it may be convenient for
writers of ABC it's horrid for readers. It makles it even harder to extract
a tune and the probability would be very high that we should find orphan
bits of ABC floating round w
Simon Wascher <[EMAIL PROTECTED]> writes:
> Example
> X:1
> Q:n/n=n N/N=N andante
>
> will playback n/n=n and display N/N=N andante
>
> so if a numeral tempo indicator is on the very beginning of such a
> string it must be written a second time for the display.
>
> If no tempo indicator shou
Laurie Griffiths wrote:
>
> Jack, Frank (and other users) even if this isn't ideal, is it acceptable?
That's easy:
Acceptable:
Anything that lets me write abc to display any imaginable tempo
indication and play it back at a sensible speed.
Ideal:
Anything that lets me just write the tempo indi
Hello,
nearer to an optimum than before :o)
( I know I should wait a moment and do it at once)
here, Separator ideas (the "-") and order ideas are integrated.
Syntax for Q field after a definition by Laurie Grifiths (with Lauries
use of the minus!)
(follows after the standard Q:field definit
Simon Wascher <[EMAIL PROTECTED]> writes:
> It is not trivial to
> tell where music ends and side information beginns. And as a transcriber
> of historical sources it is often very important to cover some "side"
> information within the exchangeable file, not just in the printed output
> (for fil
Hello,
Laurie Griffiths wrote:
>
> That would be acceptable.
>
> Actually I proposed that instead of having to write it twice it would be
> done the other way.
> If the text of the displayed tempo is a single minus sign then it has the
> special meaning "display nothing"
> Q:1/4=80 %display "
Hello,
here some sugestions which are, I belive quite near to an optimum.
Syntax for Q field after a definition by Laurie Grifiths.
(after standard Q:field definition)
for setting the tempo, also textual tempo indicarters like "allegro" can
be specified in an external macro file or can be defi
essage -
From: Simon Wascher <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 1:49 PM
Subject: Re: [abcusers] something really simple
Hello Laurie,
I think maybe now we got it:
The golden rule could be:
If there is a n/n=n string right after the colon thi
PROTECTED]>
Sent: Monday, November 12, 2001 11:58 AM
Subject: Re: [abcusers] something really simple
> Simon Wascher wrote:
> >
> > my *exemplary* proposal for a separator was not % but %%display or
> > %display (the second can be ruled out by reason of keeping the standards
&
Hello,
Anselm Lingnau wrote:
> This is purely a presentation issue and does not pertain to the actual
> ABC standard, which should describe the contents of ABC files.
It is simply not true that the abc standard does not contain
presentation issues. Even the question which clef to use is purely
o
On Mon 12 Nov 2001 at 12:58PM +0100, Frank Nordberg wrote:
>
> I know I sometimes expect too much from the programmers. Like so many
> non-programmers I tend to view them as some kind of magicians always
> ready to pull a handful of miracles out of their sleeve.
> If you tell me you can't do it t
Hello Laurie,
I think maybe now we got it:
The golden rule could be:
If there is a n/n=n string right after the colon this will not be
printed if it is followed by any other character.
everething else is printed entirely.
this restricts "playback only" fields to n/n=n what is acceptable, an
Simon Wascher <[EMAIL PROTECTED]> writes:
> there are several reasons for this, most important to me is the
> transcribers request that information given in the source is passed on
> in the abc file.
I don't see the problem there. You put in your `Q:' header whatever the
original source said. I
Simon Wascher wrote:
>
> my *exemplary* proposal for a separator was not % but %%display or
> %display (the second can be ruled out by reason of keeping the standards
> syntax stringent).
OK, now have a look at this:
Example 1
Displayed tempo: Allegro 1/4=120
Playback tempo: 1/4=120
Q:Allegro
I think that I am now in favour of syntax that allows this:
Any lines containing % are meta-comments meaning that they are just me
talking to you about the example and would not be part of the example -
though I guess they'd be legal as comments anyway
Q:1/4=120 Allegro % Outside any header. Def
Hello Anselm,
Anselm Lingnau wrote:
> Q:Allegro "Pretty quick"
> Thus, a notation program could display something along the lines of
> Allegro (Pretty quick)
the problem is that the tempo information may be a compilation of
information for
A) playback and display (that is the acctual stand
Hello,
Phil Taylor wrote:
> Frank Nordberg wrote:
> >Oh, I think that is settled already. One of Simon's arguments was
> >compatibility with older applications, and the only character that would
> >work for that is %.
>
> No! % alone indicates that the rest of the string should be ignored.
> Us
[EMAIL PROTECTED] wrote:
>
> It might not be safe to assume that MIDI is the only way playback can/will
> occur.
Well, yes and no. A non-midi ABC player application should be able to
interpret ABC playback commands even though they are named "MIDI", but I
can agree the phrasing might be a bit co
> The point is that you might want to specify a tempo for a MIDI player,
> but not print it for a human player.
> Or to specify a tempo in quarter notes per minute for a MIDI player
> but with a word like "allegro" for the human.
That's exactly my motivation for wanting this added to BarFly, but
> "Laurie" == Laurie Griffiths <[EMAIL PROTECTED]> writes:
Laurie> I'm not sure if I buy it anyway. Why would one want to have a
playback-only
Laurie> field that did not apply to a human player too? Perhaps an example would
Laurie> clarify?
The point is that you might want to
ct: Re: [abcusers] something really simple
>>>>> "Frank" == Frank Nordberg <[EMAIL PROTECTED]> writes:
Frank>+We'll probably need a way to define playback-only Q: fields
Frank> as well. It's tempting to use the old style "number only&qu
On 3 Nov 2001, Laura Conrad wrote:
> If it's playback only, wouldn't it make sense to put it in a %%MIDI
> line?
It might not be safe to assume that MIDI is the only way playback can/will
occur.
John
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
1 - 100 of 104 matches
Mail list logo
