Re: [abcusers] Progress towards a new abc standard is [1,3
Hello,
John Chambers:
> Simon Wascher writes:
> | I would like to add:
> | [1+3
> | and
> | [1&3
(...)
> My current implementation has
> "-,.0123456789" as the legal chars; making it "-,.+&0123456789" is a
> one-line change. (In an earlier discussion, someone also suggested
> including "x", but I don't recall what that meant.)
By the way: '[1+3' and '[13' (thirteen) should be legal but '[13+' ('+'
being the last char, not followed by a number) cannot be legal: its
ambigous with the +CEG+ chord notation. Similar case is '[n-' and '[n.'
[nx .
This leads to a list for all chars that *cannot* be part of the
'' ending syntax:
1) all letters and obviously: '%', '\'
2) following chars cannot be the *last* char of a ending string (exept
in the proposed "" case):
'+', '-', '.', '(', '[', '~', '', '_', '^', '=', '{',
In fact the last char in the ending syntax must be a number.
All other chars would be recognized as part of the following abc text.
More general one could say:
$ a ending begins with a '[' sign followed
$ by any number or by a string of any chars exept letters
$ (and '%' or '\'). The string must end with a number.
I know this is fairly liberal, but thats my weltanschauung.
Simon Wascher - Vienna, Austria
http://members.chello.at/simon.wascher/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is philosophy
Hello, I think the main topic here is about abc format philosophy. Laurie Griffiths: > Why have these alternatives? They add nothing > to the expressiveness of the language. To me a syntax should allow to write everything that does not harm its integrity. It is not the target to tell how a text must be written, but how it must not be written. Any expression a person wants to use should be legal as long as it does not collide with the integrity of the syntax. Even if I would not acctually know a person who wants to use a certain expression I would opt for the right to write that expression as long as it does not break the integrity of the code. Not asking all the time "why should we allow this ?" but "Why not?" and rejection not just being the personal oppinion that it is silly. Its one of the basic freedom rights, this right to do things others may call silly. regards Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
John Chambers: > | [last time > > Yeah; this is useful. But a problem in the past has been that the > discussion of how to do this bogs down as people try to solve all > possible repeat problems. After a while, people get bored trying to > follow the abstrusities, the topic dies, and nothing happens. > > I'd suggest that we first make sure that [1,3 and similar endings are > explicitly legal, so that they'll get implemented and people can use > them. The general case should be a separate discussion. If we delve > into it again, we'll never get anything but first and second endings. > > | `|(spaces, backslashes, linebreakes, tabs)[<"text">' > | > | where also could be any of the extentions proposed earlier. > > There is a serious ambiguity here. Consider something like: > >[1"Foo"ABC Ooops, an euphoric lack of concentration, pardon and thanks for the correction. But anyway ["last time" will work without troubles. But I agree that the votes on [1,3 and on ["" must be separated. regards Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ P.S.:(I know you warned me to go on with this): ["" would work. Not that I really need this :-) . To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
Hello, John Chambers: > Well, the [1+3 and [1&3 cases are silly, Well, to me it is what I write in tadpoles notation, maybe this is an austrian speciality but I understand 1+3 as "first *and* third ending" and 1+3 is a shortcut for this. by the way, I thought we came to the conclusion not to qualify other listmembers postings as "silly". Not every bit of notation I do not share, use or understand is neccessarily silly. :-| Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is [1,3
Hello,
John Chambers wrote:
> (...)
[First and second repeats]
> After several online discussions, I (and probably a few others) have
> implemented the rather trivial extension of allowing any string of
> digits, commas, hyphens and periods to label an ending. This means
> that endings like [1,3 and [1-3 work with a very few abc tools. If
> you use them in your tunes, my Tune Finder will handle them and
> return correct PS or GIF notation.
I agree that [1,3 and [1-3 should be standard. It is easy to separate
this ending stuff from other abc text.
I would like to add:
[1+3
and
[1&3
and
a way of saying for example
[last time
(this can be found in arrangements for traditional tunes)
I want to give it a try:
the standard for combining chords and guitarchords correctly is:
["Order of symbols" from the 1.6 standard]
`Open and close chord symbols, [], should enclose entire note
sequences (except for
guitar chords), i.e. "C"[CEGc]'
since the annotation syntax derivates from the guitarchord syntax I
presume that this is also the legal order for annotations.
What I want to create is a text field that is not an ordinary annotation
but a text that *replaces* (or adds to) the number in the endings
bracket.
The standard for ending brackets is:
["First and second repeats" from the 1.6 standard]
`First and second repeats can be generated with the symbols [1 and
[2, When adjacent to bar lines, these can be shortened to |1 and
:|2 ...'
My Idea is to use the annotation syntax and the first and second ending
(i.e. `repeats') syntax and combine them to textual ending syntax.
On first sight it is clear that `|"last time"' would be accepted by all
programmes but just as ordinary annotation. So such an extention cannot
work with this shortcut.
But with the standards *normal* version using the squarebracket (begin)
as indicator for the special case `first or second ending', no serious
troubles arise:
`["last time"' is non-ambiguous since [" is not legal under any other
circumstances.
(the meaning can be backed by the fact that the squarebracket as ending
indicator is allways preceded by a | character (legally followed by no
other characters than backslashes, spaces, linebreakes, tabs), meaning
never preceded by a letter.
So my proposal is:
$ the numbers in the brackets of a first or second ending
% (may we call these `multiple endings'?)
$ can be replaced by a text in quotes. In this case it
$ does not work to use the shortcut |"text" since this
$ would be interpreted as a guitarchord
Again I do not see any troubles to allow the extention-extention:
`|(spaces, backslashes, linebreakes, tabs)[<"text">'
where also could be any of the extentions proposed earlier.
Example:
abcdefg |1+3 a2bcdefg :|\
[2+4 b2cdefga ||\
["last ending" c8 |]
Or
abcdefg |1+3"last ending" a2bcdefg :|\
[2+4 b2cdefga |]
regards,
Simon Wascher - Vienna, Austria
http://members.chello.at/simon.wascher/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Progress towards a new abc standard is: |:: ... ::|
Hello, there is no reason to reject ::| and :::| notation as far as I see. Additive complementary constructs (intriguing to me) could be: :<"text">| and :| the <"text"> construct would allow to specify freely any text that gives information on the number of repeats. examples: :"repeat this bit as often as you feel like"| :"3 times"| :"(3x)"| :"add one repeatation every time through"| by chance existing programs may accept this '"text"' like any other text in quotes, and only those who have such a feature implemented will recognize a '"text"' within the repeat sign as being a special text for describing the number of repeatations. In extention to this clever playback programms eventually could filter through the :'"text"'| and search for numerals and even numbers in words and use these for playback. in the :| construct the gives the number of repeats, which easily could be interpreted by playback *and* display programs, to do whatever they are programmed to in such a case. examples: :2| % equals :| :3| % play section three times :5| % play section five times As a final extention-extention :<"text">| could be allowed where the numeral defines the number of repeats for playback and the '"text"' is displayed. This may be usefull if the '"text"' does *not* contain computer-readable information, and the transcriber wants to suggest that the section should be repeated by the playback program three or maybe nine times exemplarily. One nice things with these constructions, which could be used paralell to the ':::|' construct , is that they do allow a very user/transcriber orientated approach with very little limitations, as the number of repeats can be choosen free, and alternatively a text which can be identified by programs as repeat-related can be added to extend the possibilities further out. I think such a solution would end discussions on this topic for a long time. Simon Wascher John Chambers wrote: > Jack Campin writes: > | >> Something I've also implemented is the conventional |:: ... ::| > | >> notation that says "three times through". > ... > | In music I've seen that uses this construct, it's represented by > | printing "(3x)" above the staff. A staff-notation generator could > | do whatever it liked with "|:: ... ::|", but I suspect that most > | non-Scandiwegian users would be happier with some such explicit > | representation using honest-to-god numerals. > > Yeah; I've seen that, too. OTOH, I've seen the |::: ... :::| notation > used a fair amount in music from Eastern Europe and the Balkans, and > even musicians who claim not to have seen the notation before always > seem to know what it means without explanation. I don't thing I've > ever seen it used for more than 3 repeats (four times through). It > would get difficult to count. > > One problem with using "(3x)" is that this looks a lot like a strange > chord symbol to software. Maybe it should be "^(3x)". > > | Does any system of notation have a sign for "repeat this bit as often > | as you feel like"? The definitive use of that is in Terry Riley's > | "In C", but it occurs implicitly in quite a few genres. > > In fact, this happens in Scandinavian and German folk dance. It's > usually tied in with a dance that has two different steps that match > the music (e.g., zwiefacher). There are some tunes that are often > played with irregular repeats, to see if the dancers can handle it. A > slightly simpler version, for non-expert dancers, would do something > like an arithmetic progression, playing the phrase N times in the Nth > time through the dance, or something like that. > > All the notation I've seen for this has been idiosyncratic. And often > in German or Swedish or Finnish. > > Some years back, Scientific American published the "Telnet Song" that > had nested for-loops as the repeat indicators. It was a cute song > that described the escape sequences required to back out gracefully > from a chain of telnet connections without leaving any dangling > connections alive on any of the machines. -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tempo
Hello, I was out travellin for one week, and just tried to recapitulate last weeks mail exchange, and must say I cannot follow it completely. But I must add that: [EMAIL PROTECTED] wrote: > > On Sun, 2 Dec 2001, Laurie Griffiths wrote: > > > Q:Allegro -- uses Allegro which must have been already defined. > > Does this mean that a transcriber can't specify a tempo without also > defining it metronomically? I'm not sure I like the idea of *forcing* > them to add information that the composer didn't provide, but I can live > with it. I could *not* live with such a solution. It *must* be possible to use words for describing tempo whithout having to define them in numbers. If the words used for describing a tempo do not match any already defined string of words they simply cannot affect a programms playback (but these words will still affect the musicans playback). Simon Wascher -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple (is: playback of textual tempo indicators)
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 doesn't really seem such a bad > thing. depends. If it is fixed part of a playback program it is a bad thing (as I read is what happens in one program with the R:fields playback information). If it is some default that can be changed by the user within the playback program it is not. And definitely it should *not* be part of the abc format standard, since for some musicans using textual tempo indicators is to *avoid* metronome numbers to sugest that it depends on the circumstances of a performance which tempo is the right one. Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 player program might default to looking at the Q field to get its > tempo, or it could have the tempo specified on the command line, > or it could have a separate "tempo definitions" file (similar to a > stress file) and attempt to interpret the text in the q field (thus > allowing for tempo descriptions such as "A little too fast") > > A display program can choose to display the Q field, the q field, > both or neither depending on what program specific options are set. (...) Just to say, yes I like this. I try to repat it in my own words to see if I got it right: The Q:field defines the playback tempo in ways of numeral definition, unchanged. a new q:field can be used to support `a textual description of the speed of the tune' both fields can be used in the header and the body of a tune. Which of them is displayed and/or used for playback is decided depending on what program specific options are set by the user. the `textual description of the speed of the tune' supported in the q:field can be used by program specific options (whether they are predefined :-( or definable :-) ) or together with a `"tempo definitions" file (similar to a stress file)'. *or* by other mechanisms of tempo definitions, in file headers or tune headers which have not been agreed on so far. Advantages of this proposal if I got it right, are: * 100% backwards compatability in tune files, * textual tempo indicators are allowed without the need to agree on if and how they are interpreted by player programs, which I do belive is a separate topic. Simon -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 NEVER > > defined at the beginning of a tune. There wouldn't be any point in > > tempo terms unless they had an understood meaning in a context wider > > than an individual tune. Today, everybody who has a metronome uses the > > commonest 8 or so Italian terms in the same way to about 1% precision > > because they're engraved on the scale, and I would guess the world > > contains a few million more metronome users than ABC users. > > As someone who doesn't own a metronome, this is new information to me. > If everyone who has a metronome posts these numbers, then maybe we > will find that they all agree and we will have the basis for a useful > standard. Likewise, perhaps you could post a list of military march > tempos. Where pre-existing standards exist, then providing support > for them in abc does seem like a good idea. The problem is, that some classical musicans belive that these italian tempo definitions are clear und unique. Practically there are a few more musicans than metronome users and even within the core of classical music - Mozart, Haydn, Beethoven - there is clear evidence that it is not at all clear what tempo (in absolute metronome numbers - the only thing a computer playback program can make use of) is really meant with those classical italian tempo indicators (just listen to your classical music recordings!). So, there is more than one pre-existing standard for each textual tempo indicator, and therefore it would be counterproductive to fix them unchangeable within a program and even worse to disastrous to fix them within the standard. Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 idea. 2)making these textual tempo definitions executeable for playback as we have seen again and again there is no agreement at all on this part of Jacks proposal (the rest of it). So could we consider to spilt these two things appart and work out how 1) can become an acceptable common agreement (forewards and backwards copatability in tunes and at least partly in programs ? ) Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] how to change L:
Hello, from time to time I come across abc text where I want to change the L: value, to say it more precise the value of one letter in the text, for the whole tune, after it is written. often it is that I want to change a tune from: `a/b/c/d/ ag b2' to `abcd a2g2 b4' Is there a tool that can perform such a change ? there is some idea in my mind of an ideal tool which counts the "noteheads" i.e. the number of characters needed at differen L:values, so it is possible to optimize/minimize the number of characters needed by telling which is the best L: value for a short text (in the short example above, its 14 vs. 12 characters - last but not least this means compressing the tune size about 1/7, often it will be much more). Simon Wascher To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 the note value of the beat is compound (dotted), there is no > whole number that can represent it accurately, so a smaller note value has > to be used. For instance, if the composer intended two beats per measure, > with a dotted-quarter beat, the only accurate way to write it would be > something like 2/2.666... For obvious reasons, we write 6/8 instead. > > The problem is that by doing this, traditional notation breaks its own > rules. 6/8 time seems to imply that there are actually six beats per > measure, and that the eighth note defines the beat. to me as an traditional musican, this is not a broken rule its simply an special rule to dotted rhythms: 3/8 equals one beat. so if I want to write three beats in dotted rhythms I use 6/4 time. One problem is with 5/8 which has two beats (3+2 or 2+3 ; I do not know how to fit this into a classical "allegro" recipe) wheras 5/4 has five beats :-) . And to complicate the > matter further, sometimes this *is* what the composer intended. composers ask for everything and the opposite, composing is mainly a game about establishing rules to break them. > The question at this point seems to be whether we want the standard to get > it right all of the time (define Allegro as 120, define the beat for each > piece); get it wrong only sometimes (define Allegro as 120, guess at the > beat); or get it wrong a great deal of the time (define Allegro as > 1/4=120, even in 6/8, damn the beat). I think in most cases defing allegro to the beat given in the M: field under the presumtion that 3/8 = one beat will be sufficient in 95% of all cases. In other cases the transcriber has to redefine the beat. > > 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. > > This kind of thing happens quite often in newer compositions, usually > implied by the note beaming, but sometimes written out explicitly in the > meter (e.g., 3+2 over 8 instead of 5 over 8). Some notation software > allows this... I believe Finale is one of them. Yes, yes of course, I use this stuff too. What I wanted to say is "I've never heard of a definition for *"allegro"* in 3+3+2 rhytms in any other music notation context (a definition for a correct tempo for *allegro* in 3+3+2 time ). No question compound rhythms *do* exist (and Finale supports them). It seems I did not write too clear. Simon Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 complete > Italian language 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 classical music's set of italian tempo descriptors which have in no way a consistent well defined generally accepted meaning as every musicologist can demonstrate. Simon -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 were playing in 4/4 it would p-r-o-b-a-b-l-y > mean 120 1/2 notes and then there's the Balkan and Turkish stuff i did not participate in this "beat" topic since I do not use any of these classical tempo words in my music (but sometimes others). But, maybe I make an idiot of me by askin such, 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. what Laurie describes above is a clear connection between M:6/8 or M:4/4 or M:2/4 , M:C, M:C| and the "beat" of Q:Allegro. 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". And if ever it will be possible to use 3+3+2/8 in an abc M: field, we can find a way to define allegro under such a M: field. Simon -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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* the the display. Do not say this is *not* the target of abc, there is no such thing as a restriction against display matters anywhere in the standard. Its *your* ideology about abc. For me abc is a way to create compressed, easily exchangeable, freeware, playback active representations of a musical source. Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Looking for ABC transcriber.
Hello, No I do not know about but I am highly interested in the playford file, Buddha Buck wrote: > One of my current projects is to use ABC to generate a dance manual for my > local SCA group -- with the goal that I should be able to integrate into > the manual the score for the dances, the dance steps, and background > information (like a transcription of the dance steps from primary sources, > known lyrics for the songs, etc) into the source files, and be able to both > print out the manual Just out of curiosity how do you integrate music and text ? Do you do it using %%begintext %%endtext and generate a single .ps file ? Simon Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something fairly complicated (Q: field)
Hello, James Allwright wrote: I think what is actually wanted is the ability to write > Q:allegro > because the word "allegro" was the tempo indicator in the original > score. If a player program recognizes this and picks an appropriate > tempo, then all is well. I believe that there are only a finite > number of italian words used to indicate musical tempo, so this > approach should actually be possible. YES BUT: There is a more or less infinite number of tempo indicaters that have been or are used today by composers and other musicans. No troubles if the player program simply uses whatever default if it does not recognize the term. All proposals that use Q:text within a tune loose backwards compatability whith (all?) old programs. All proposals which use "Q:numeral (space?) 'extention of whatever kind' " have better chances that backwards compatability whith (some) old programs is provided. Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
d like to use abc formating for distributing music (filesize, exchangeability, playability & displayability, its freeware) but in this case there are some things that tangent the display. > I keep going back to HTML but it really seems to me that we're about to > make all the mistakes over again that the HTML crowd made a few years > ago. in your statements, please keep in your mind that I do not understand a word about HTML, maybe other listmembers too. Simon -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 syntax they define is pretty much particular to the `Q:' field. So
> we get a `-' here and a mandatory space delimiter there, and in another
please try to stay at the formal side with your postings. You kow that
this is not a fair way to speak about the hard work other people do. Its
not just "here and there" like in "silly idiots". Bring up formal
arguments and alternatives.
The problem is that the Q:field is playback active *and* display active.
It may contain a numeral definition for the programs player *and* text
string for the person who reads it (in that case it does not matter much
*where* the numeral definition is stored, in a definition field, or a
macro file or with the program or inside the actual Q:field).
The same case with the V:, K:, maybe M: .
> ABC standard seems about to be extended in all sorts of directions we
> should instead be aiming for a consistent style of syntax that allows us
> to express these extensions.
Yes.
> For example if we accept the `key=value'
> style of options in fields such as `K:' or `V:' then we should define
> extensions of the `Q:' or `L:' fields in a similar fashion, for
> consistency, instead of giving these fields their own syntax because in
> the short term that seems to be the easier choice and sufficient for
> `everything that is needed'.
So , do we accept the style in which the K: and V: fields are extended,
so are all those draft and program related syntax proposals using the
same style of syntax ?
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=allegro
Q:3/8=69 display="allegro"
both displaying just: allegro
or something similar would be OK to *me* (as I said I do not care much
what SEPARATOR is choosen)
All the discussion just started since it was sugested (and later on
verified) that there would be more user orientated and "natural" ways to
indicate tempo specifications (which only have the disadvantage that it
needs to make use of a extended syntax in cases where a n/n=n *playback*
tempo definition is not being displayed).
> (This is incidentally why I would prefer
> something like `L:1/8 grace="1/32"' to `L:1/8 {1/32}' as proposed in
> Ewan Macpherson's message, even though it may be wordier in the short
> term.) Chances are that it won't be.
This keyword:value syntax *is* wordier, on long an short term, since it
wont shrink by being used. And its neither more natural nor user
orientated. But I will not object if this is common sense.
> I have also tried to illustrate how
> this approach lets us easily introduce further extensions in the future
> -- something that is difficult to do if more ad-hoc stuff is heaped upon
> the layers of ad-hoc stuff introduced in earlier rounds of updates --
> but that doesn't seem to have got through.
You do a lot of ad hoc stuff too, if you define ad hoc stuff as syntax
that is newly introduced into the draft (do not forget: draft is not
standard). the whole keywoard=value syntax is not generally approved,
and whithin that there is no general approval for the quotes as
delimiters.
> The other issue is one that I have expounded upon several times already,
> namely that the ABC standard should as far as possible stick to
> expressing musical content, and leave presentation issues like what kind
> of ancillary ABC information is and isn't printed where and in what
> style to individual ABC-processing software, which is where it belongs
> and how most of this material (such as titles, guitar chords and the
> like) is already being treated.
As pointed out this your argument does not stop the need of a stringent
syntax for this, since it does not much make a difference which part of
a program has to recognize a string.
and if features are not implemented, it may also cause people to include
%%programspecific commands whithin files.
Simon Wascher - Vienna, Austria
http://members.chello.at/simon.wascher/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 that *can* be parsed by a program for *this*. So there is no way passing the fact that the ability of marking the part of the Q: string that is for display is needed for programs to recognize it *also* if its just for a local option. But: I belive it must be possible within the standard for a main purpose: a composer marked the composition with a tempo mark: lentement this should be displayed. The default playback tempo usual programmes choose is to fast and lentement is not defined in the programms internal macros (even if it is it may not be implemented by a person who follows the same music scientific school the transcriber does). So playback tempo must be defined. As it is not original, the transcriber does not want it to be printed with the score. To be precise: it is *purely* for the abc player and *not* for the display. But its not a personal thing that can be left to the local options. So here we are: Q:3/8=20 - lentement in fact this is the only way to make sure the playback tempo is connected to the tune if it is extracted from the file. This will be the case allways when a transcriber wants to make sure that a playback tempo remains with a tune, but a textual tempo header should be displayed. So in all cases where macro scepticers want to use playback active textual tempo indicators. Two more things: 1) examples are for writing a syntax not ony a "what do I personally need" but also testing ojects for the syntax. So the procedere is to think about the weirdest "testing objects" and finding whether the syntax can handle them or not. Sometimes like in the above case, both go together, the testing object and the need. 2) as Guido remarked, one of the disadvantages of the current abc standard is that it did not look far enough ahead and is quite narrow therefore. I belive that it is important that the standeard can coope with examples that are far from our immagination and understanding in terms of "what is this for?" (this is why my original proposal was: 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. because this does not need a special character or something similar at all. Just a "special case" as Laurie called it, the playback only with the minus [or any other single charctrer we choose].) Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 example of an > application that requires it? Obviously if there isn't an actual > requirement for this notation (other than `Simon says so') there is no > need to clutter up the standard with it. Anselm, I posted examples about three times. > > So why bother about its syntax if you cannot imagine someone may need it? > I do bother about the proposed syntax because I want the ABC standard to > stay as simple and straightforward as possible (while still being as > expressive as is reasonable). If this means we have to think more and > harder instead of catering for every whim at a moment's notice then > `tough'. If you *read* the standard I proposed, You will see that in all cases you or Frank asked for this syntax reacts completely straightforward an simple and also in many of the odd examples Laurie gave. In fact it always reacts straitforewardn and simple. > The counter-proposal stands: > > Q:1/4=120% [1] explicit tempo specification > Q:1/4=120 note="Pretty quickly" % [2] explicit tempo with advisory note > Q:Allegro% [3] symbolic tempo specification, metronome >% speed (or range) defined elsewhere > Q:Allegro note="Pretty quickly" % [4] symbolic tempo with advisory note > Q:Allegro 1/4=120% [5] definition of symbolic tempo > Q:Allegro 1/4=120-128% [6] definition of range 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 done ? I only found the solution of using two Q: lines, one definition line and one tempo line but how should this work? It would make a definition line before the X: line mandatory ! *this* is what I call failling of a syntax. Or maybe you repair it by allowing definition *and* playback Q: fields side by side inside a header. again: *this* is really a worst case syntax. having a syntax that allowes such: Q:1/4=120 - Allegro % displaying "Allegro" and playing 1/4=120 is usefull for: simply for those who want to include a program readable but userdefined tempo indicater in a file where "Allegro" should be displayed (for example because just "Allegro" is what the composer indicated). > supposed to do). We don't need special syntax for every single ABC > header field when there is a general pattern that we can apply, like the > `key=value' convention outlined above. Remember : the minus sign only is used in cases where something is *not* printed. so it is additional syntax, not alternative. Yes there should be a unique header expansion syntax (actually there is no agreement on which). I have no problems if quotes are used or minus or pound signs . they are as good or bad as nearly every other separator (and create other limits to the syntax). I might just add that all your examples come from *draft* and till now there is no agreement on whether this will become standard. > > allegro is not more or less musical information or convention than > > 1/4=120 > Wrong. Anselm. Some composers/musicians/transcribers want this some that. Inside an abc tune 1/4=120 is the only way to influence a playback function user/transcriber controled. > > . If implemented, it would, among other things, make it > > > possible to control the tempo of a bunch of tunes without having to > > > change the `Q:' line for every single one, which I find quite appealing. > > You can have this by now by using your playback programes player > > settings ;-) . > > Or using a program that allows active R:fields > > Active `R:' fields are quite another can of worms as long as their > meaning is hard-coded in the player programs (like with abc2midi, In your own words: let these things to the program packages. > Besides, what would you put in the active `R:' fields of, say, Bach's > inventions or Chopin's études so their speed can be controlled? This is slightly off topic, but if you really want to know, I could figure out and send it to you of list. The main question for sure would be to give the playback function of the program I use a definition for the tempo to play (as not to fall to some default) and at the same time display whatever Bach or Chopin sugested as a textual tempo indicator. Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
how to define textual header indicators was: Re: [abcusers] something really simple
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 should find orphan > bits of ABC floating round with macros used but not defined. definable textual tempo indicaters were the start of this topic: Jack Campin wrote on 03Nov01: > Okay: tempi in words. > It ought to be possible to write > >Q:allegro > in a tune header or >[Q:allegro] > in a tune body, and optionally define outside the tune (earlier in > the same file or maybe in a separate settings file) what "allegro" > might mean in numerical terms, with a line like this: > >Q:allegro 1/4=120 and till now nobody objected as far as I remember. "in a separate settings file" very much sounds like "external macro". About yesterday evening (lokal time :-) ) I sugested to separate the play/display and the textual tempo indicater topics into two separate subjects as they are not really related. _Ok lets talk about where to define textual tempo indicaters_ Jacks first proposal was only to allow textual tempo indicaters (no playback, only display or maybe a playback definition whitin the program-package) no playback, only display is what you also get from a tune that is cut of from its macro files. A playback definition within a program is package dependend. After export, same result: no definition, just display and default in action. "earlier in the same file" as Jack also sugested ends up with the same problem at any export from the file, for example by the tunefinder. same result: no definition, just display and default in action. "or maybe in a separate settings file" as I mentioned sounds very much like "external macro file" I personally use the R: fields playback functions whith BarFly and never found them a problem. The text in the R:field has a meaning of its own if the tune is cut of from its macro file and so it would be with tempo indicators. Its true its not standard. So it must undergo discussion anyway. Simon PS: how do you like my actual proposal for the Q:field ? (besides the macro topic) -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 another, different, prescribed > explicit metronome speed for playback, and why this would be preferable > to letting users set their own playback speeds `ad hoc', external to the > ABC representation, with the ABC-provided speed as a (reasonable) default. Anselm you have to decide: you say you find this feature unneccessary. OK. Lets say you are right, its completely impossible that someone needs that. So why bother about its syntax if you cannot imagine someone may need it ? either want it to be easier to use OR say nobody needs it. _the truth about syntax_ It is neccesary to encounter the edges of a choosen syntax to be able if it is stringent, search deeply for the worst cases it produces. This is how a syntax is developed. Every syntax has its dark corners and all we can do is turn the pockets around till we find the least important corner in our proposal to contain the blackest hole of our syntax. So here it is: Q:n/n=n N/N=N andante, dark and sinister but without any meaning in real life. (by the way I wrote more than once that I know what I want to use it for. And discribed it. I can live with the syntax, but I think I found a better one which I posted) Simon Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 definition) for setting the tempo, also textual tempo indicaters like "allegro" can be defined for a whole or part of a file, outside the tune before the tune header, or in an external macro file. Q:1/4=120 Allegro % Outside any header, defines Allegro The first tempo indicator that is identified in a Q:line will be used for playback. Example X:1 Q:andante if "andante" is defined as textual tempo indicator it will be used for playback, if not the default value is used, "andante" is displayed. Example X:1 Q:andante n/n=n if "andante" is defined as textual tempo indicator it will be used for playback, if not n/n=n is used for playback, the whole string is displayed: "andante n/n=n". Example X:1 Q:n/n=n will playback n/n=n and display "n/n=n" Example X:1 Q:n/n=n andante will playback n/n=n and display "n/n=n andante" Only numeral tempo indicators of the n/n=n format are supported in this extended mode. Old versions of setting the tempo like Q:60 cannot be expanded, so Example: X:1 Q:60 Andante will be displayed as: "60 Andante" if "Andante" is predefined as textual tempo indicator playback will use this, if not the default tempo will be used. (Q:60 - Andante would work!) The content of the Q: field is usually displayed by programs entirely but may contain separated playback and display information. To allow playback only information or some additive text for display, the following expanded syntax can be used. In the following example parts of the Q: filed are not displayed: A - (minus symbol) can be used to indicate that the part of the text that comes before it is not displayed. Example X:1 Q:n/n=n - andante will playback n/n=n and display "andante" Example X:1 Q:andante - gehend if "andante" is defined as textual tempo indicator it will be used for playback, otherwise "gehend" if defined, if not the default tempo is used for playback. "gehend" is displayed If no tempo indicator should be displayed but a playback tempo set this can be done using just the "-" after the tempo indicator: Example: X:1 Q:n/n=n - X:1 Q:andante - regards, Simon Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 "1/4=80" and use it for the player program too > Q:1/4=80 - %change the tempo on playback but display nothing here. > Q:1/4=80 dreary % display "dreary", use 1/4=80 for playback. Oh , we can have it the other way round, if the minus sign has the meaning: do not display whats before me. like Q:1/4=80 - dreary % display only "dreary" and use 1/4=80 for playback. If this is nearer to your idea of this I share it at once. Would make: (stated that the first identified active tempo indicator [numeral or textual] applies) Q:1/4=80 %display "1/4=80" and use it for the player program too Q:1/4=80 - %change the tempo on playback but display nothing here. Q:1/4=80 dreary % display "1/4=80 dreary", use 1/4=80 for playback. Q:1/4=80 - dreary % display only "dreary" and use 1/4=80 for playback. if textual tempo signs are defined (macros enabled): Q:adagio %display "adagio" and use it for the player program too Q:adagio - %change the tempo to adagio on playback but display nothing here. Q:adagio dreary % display "adagio dreary", use adagio for playback. Q:adagio - dreary % display only "dreary" and use adagio for playback. if no textual tempo signs are defined (macros disabled), Q:adagio %display "adagio" and use default for the player program Q:adagio - %use default on playback and display nothing here. Q:adagio dreary % display "adagio dreary", use default for playback. Q:adagio - dreary % display only "dreary" and use default for playback. makes for these examples: Q:Allegro ma non troppo 1/4 = 120 %works, either allegro or 1/4=120 Q: Like movement 1 (1/4=110) but slightly slower % will play 1/4=110 Q:Like the first 1/2 1/2=120 % works, will play 1/2=120 Q: Like the first 1/21/2=120 % will use default, is not clear in ascii too Q:Like the 1/4=120 part but a but in 6/8 time 3/8=120 %will play 1/4=120 Q: Like the first 1/2 % will use default Q: Slow then getting quicker the first 1/2 about 80 but by the last 1/4 about 140 %will use default Q: Slow then quicker, 1st 1/2 = 80, last 1/4 = 140 % will use 1/2=80 this is something new: a changing tempo. Wonder which player could handle this. Maybe we can start a new topic on this :o) . Q: Parts A and B =120, C=140 % will use default Simon Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 defined for the whole or part of a file, outside the tune, bevore the tune header. Q:1/4=120 Allegro % Outside any header, defines Allegro The content of the Q: field is usually displayed by programs entirely but may contain separated playback and display information. To allow playback only information or some additive text for display, the following expanded syntax can be used. The first tempo indicator that is defined will be used for playback. Example X:1 Q:andante if "andante" is defined as textual tempo indicator it will be used for playback, if not the default value is used, "andante" is displayed. Example X:1 Q:andante n/n=n if "andante" is defined as textual tempo indicator it will be used for playback, if not n/n=n is used for playback, the whole string is displayed: "andante n/n=n". Example X:1 Q:n/n=n will playback n/n=n and display "n/n=n" In the following example the playback temo is not displayed: If a numeral tempo indicator follows directly after the Q: it will not be displayed if it is followed by other characters Example X:1 Q:n/n=n andante will playback n/n=n and display "andante", similar 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 should be displayed but a playback tempo set this can be done using a "-" after the numeral tempo indicator. Example: X:1 Q:n/n=n - Old versions of setting the tempo like Q:60 cannot be expanded, so Example: X:1 Q:60 Andante will be displayed as: "60 Andante" if "Andante" is predefined as textual tempo indicator playback will use this, if not the default tempo will be used. regards, Simon Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
what should be content of abc files, was: Re: [abcusers] something really simple
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 optical and does not change one bit of the "music". 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 file exchange). This "non musical" information does influence the musicans output and therefore is in a way part of the music. Abc formatting would be worthless to transcribers if it is limited to pure audible phaenonenons. I understand that you are not interested in these aspects of music notation, and I can tell you that I am working hard that you will never come accross those features you do not need, simply do not use them and never read the readme file description on those features. I am very much concerned that simple abc remains simple but in the same time please accept that other people do expand features you never heard of and never will use. simon -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
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 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, and implicates that in one certain case a part of the time string has to be writen twice: Q:n/n=n n/n=n (+ text ad libidum) %(important: the space after Q:n/n=n), displaying: n/n=n (+ text ad libidum) Simon :-) Laurie Griffiths wrote: > > 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. Defines Allegro. No display, just > remember . > Q:3/8=160 Running % Defines Running > > X:12 > Q:Allegro %Display Allegro, play at 1/4=120 > > X:13 > Q:3/8=100 % display either 3/8=100 or preferably symbol>=100 > > Q:Allegro ma non troppo %Display that lot. Play at default rate since there > is nothing recognisable for a player program to use > > Q:Alegro % Same again. Spelling errors are not tolerated! > > Q: Allegro % but the odd space is OK, play 1/4=120 > > Q: running % and so is change of case. Play 3/8=160 > > Q: 3/8=100 - % Special case. A single minus sign means "no display" > > Q:1/4=110Andante % Two points here. Firstly no SEPARATOR character is > required. Secondly if this is between X: (or T: with a missing X: ???) and > the next blank line then it does NOT define Andante for future use, it just > prints it. Any command EITHER defines a symbol OR causes an action, not > both. Outside a header/tune it defines, inside it causes action. In this > case the action is to set the speed to 1/1=110 and print Andante. > > Q:60 Andante %SYNTAX ERROR! Only the preferred form of the tempo syntax > may be used with the new extensions. Deprecated old versions must be > complained about. > > Q: Allegro 1/4=120 % Display that lot, play at default rate. Numbers come > first. > > That last one is probably the most objectionable but I don't see any easy > line between that and Jack's "pull the tempo string out from wherever you > find it". It's an implementor's can of worms and worse - if some programmer > did hack up something that sort of works for some cases it would be a > blasted nightmare. > > Formal syntax can be cooked up easily, but i'm not sure it will aid > discussion at this stage. > PRO: Allows definition and later use (this has its pros and cons but it > seems to be part of abc, even though I personally don't like it) > PRO: Not too hard to implement > PRO: Allows printable version only, allows display version only, allows > both. > CON: More restrictive that Jack's idea > > In order to make progress - I feel that we need an "Approval voting" scheme. > English spelling has never been reformed because although many people agree > that the current version is stupid they can't agree on which of many > alternatives to go with, even though almost any of them would be a great > improvement. So if you reckon that a particular scheme is ACCEPTABLE, even > though you might PREFER a different scheme, (whether slightly different or > very different), please ... > > SAY WHEN YOU FEEL A SCHEME IS ACCEPTABLE whether or not it is ideal. We > have to start collecting YES votes if we are going to go forward. > Unconstrained discussion tends to look like NO votes. > > For instance if you feel that it would be better with £ as a delimiter (that > was an English pound sign) then if you merely say that, then it looks like > you are arguing and not agreeing. If you actually feel that any delimiter > or no delimiter is acceptable, but you have a preference for £ then make > sure you say that. At the risk of repeating myself: We have to start > getting YES votes to go forwards. > > Laurie > > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] blasphemy! A separate project...?
Hello Guido, Guido Gonzato wrote: > Let me tell you the dark side of my ABC point of view: ABC is _very_ nice, > but is _way_ too limited. It was designed with too little goals in mind. As > a real-world musician, I want to tweak current ABC so that it can do my > choral scores reasonably well. As a computer guy, I already have a new > syntax ready that just waits to be put down on paper... > > I let you guess the reasons why I didn't put it down on paper. But if you're > interested, wave your hand at me. I also see the sometimes hurting limits of the abc standard as it is. the problem is that there is a real big pile of content that uses the actuall standard. I looked into my files, and found that the abc files I transcribed are a pile of about 3 MB (plain ASCII). Assuming that other peoples who are listed as large collections at the abc homepage also have big collections besides what is in the net right now we are talking of at least 60 MB of content (another approximation is to multiply the 14000 titles of the www abc index with an single tune size of about 20KB makes 280.000 KB ). So if an entirely new syntax appears how will this syntax interprete this pile ? what are your solutions? will you write an all plattform automatic conversion tool and is it sure that no part of thecontent gets lost in this process? I am honestly interested and my questions are not cynical. But there are serious problems that would be created by a new standard. Simon Wascher - Vienna, Austria PS: this big pile of content is why I belive that bachkwards compatability in files overrules backwards comatability in programs. http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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 standard) B) playback only (not possible in the acctual standard) C) display only (only possible as a really unsatifying hack in the actual standard) D) a chunk for display(only) and a chunk for playback(only) (not possible in the acctual standard) 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. included in the topic is the separated proposal to allow program active textual tempo markers by the use of macros, maybe we can excluse this from the actual discussion since it seems to be quite common sense and does not directly touch the playback/display problem. the core problem is the impossibility of playback only (B) in the actual standard. the second the impossibility to have display only (C) in a way that the text in question is identified as tempo indication (relys on B) too !) the third the desire to have both in one (D), and this in a intuitive clear syntax. There is no way passing the fact that displayed and playback tempo indicaters are two totally different (but related) topics that both should be covered by abc. Leaving the display matters to the display programs alone as you sugest sounds intriguing and covers B) but failes to handle C) and D). The "q:" solution (extra field for displayed tempo indicaters) covers the identification of "display only tempo indicaters" (C) and with the support of an "not display Q: option" in the displaying programs that you sugested all possibilities could be handled. The SEPARATOR in this solution is a "d:" field plus an optional feature in the displaying programs. I do not like this solution much since it relies on program options which are not part of the standards syntax and its very likely that this causes misunderstandings by users, but for my purposes this would work if its covered by abc2ps. I would prefer a syntax that recognises whether Q: field info is for display and playback or just for playback. If so, I belive the just for display information *could* also be recongnised and be included here. If not it can be put into a "q:" field. > Q:Allegro "Pretty quick" > C:[Traditional] I would prefer not to use quotes as Separators as they are very common characters and cant see why they are better than square brackrets. > under the stipulation that a tune would not have a `display speed' > of 1/4=90 and a `playback speed' of 1/4=120, Its likely that exactly this is desired: One metronome number comes with the source and another is used for actuall playback. Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] something really simple
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. > Use a two character string starting with % if necessary, otherwise > there's no way to put a comment in a tempo field. 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). Simon -- Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (was)
Hello, reading all this dynamic messages, I want to ask for a bit of moderation, since things do not get better by breaking down bridges which have to be rebuilt afterwards anyway. Abc as it is is working right now and whether there is a further developement for the standard and/or the programs, abc is of some use for many people. It is true that everybody including me has whishes about extentions to the existing possibilities, but in effect nothing is as important than improoving the actuall programs or new programms to fit to the actuall standard, at least not to loose backwards and cross program file compatibility. regards Simon Wascher To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] writing abc with a MIDI-keyboard
Hello, a friend of mine is used to input music playing his keyboard (music, not computer) and "writing" the music via midi into his noation program. Is there a software that can create abc output directly in this way?: - Write a tune header or use a default tune header then press a key of the piano keyboard and the related character is displayed in abc, press the key longer and you get a longer note a 2 or 3 or 4 is added (an extra menue lets determine the player the strictness of the input)? hoping for a positive answer Simon Wascher - Vienna, Austria http://members.chello.at/simon.wascher/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Gloggauer Liederbuch
H., GBFE! S. Ps:God Bless Facsimile Editions! Simon [EMAIL PROTECTED] wrote: > > On Wed, 24 Oct 2001, Simon Wascher wrote: > > > Baerenreiter does indeed own the copyright on the actuall layout, the > > picture of the print, but never does or did own the musical > > composition itself. > > IANAL, but they do own the copyright on all of the editorial changes they > made, so for all intents and purposes, the music itself is copyrighted. > > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Gloggauer Liederbuch
Hello, Jack Campin wrote: > Also, it's probably still copyright. It was first published complete > in 1936. I can't see anybody working from a facsimile of the MS, as > re-editing would add maybe another couple of years to the time. You'd > need clearance from Barenreiter to code up their edition. (I once > expressed a hope that this was covered by the loss of intellectual > property rights on Third Reich products imposed as war reparations > after WW2, but it seems that only applied to technological stuff like > the design of the Leica, and was short-lived in effect). > > It's "Glogauer", incidentally. nothing that is written something like 1482 can be under copyright restriction right now. Baerenreiter does indeed own the copyright on the actuall layout, the picture of the print, but never does or did own the musical composition itself. Which is, according to the law of the country I live in copyright free since the late fifteensixties ;-) . Yes, its Glogauer. Last time I came across this book is now twelve years ago, and did not remember it correct (what made it hard to get results with a search engine). thanks for all your sugestions, for a start I am happy with "Ich sah einmal den lichten Morgensterne" :-) . regards, Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Gloggauer Liederbuch
Hello, I look for the "Gloggauer Liederbuch", does anyone know if there is an internet source for this renaissance song book ? regards Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics
Hello, if possible please not the ">" and "<" characters, I use them for indicating the positions of the handle of the hurdy gurdy. I would recomend some other not singable standard keyboard character anyway: "@" or"#" or "$" . The Idea to tie it to the L: could have its merits, especially if one could use an L: field directly bevore the w: field like: X:1 L:1/4 M:3/4 K:C abc/a/ | bca | L:1/2 w:left# right# left# Just a sugestion. Simon Wascher - Vienna, Austria Taral wrote: > How about a w: character that means "move to next beat"? e.g. > > w: left> approach> right> together> > > We already have a "move to next measure". (I'm not recommending using > the > symbol, I just couldn't think of anything else at the moment.) We > could even tie it to L: so that the beat specification can be separate > from the meter specification. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] (Forwarded) Converting MIDI to ABC
Frank Nordberg wrote: > Hello, I did some converting a while ago to change finale files to abc. midi2abc was used for this, not on my machine, at a friends. To coope with the problem of positioning barlines (some of te music had changing rhythms) we made midi2abc seeing the files as being in, I think it was 4/2 time so there were not to many barlines to remove - later on I learned to remove all barlines from the abc2midi output - what I got was a quite usefull sequence of letters just that all dotted notes were ill. Also a problem was the mix of keys I had in the original files, or to be precise the ill output this caused in midi2abc. I learned to fix these things with the find and replace function (only usefull if you have big files with a constant note lenght value). So I had to look up the beginn of a new tune, identify the key and the anacrusis, insert all barlines and repeats by hand, supplement all the headers. Some important things: be sure to use te right L: value. Make sure all tunes in one midi source are in one key. All this only works with stupid machine generated midi. Iam not sure how much faster I was using midi2abc than writing it simply again. But I think it was a bit faster. Simon Wascher - Vienna, Austria > John Chambers wrote: (...) > 2. Use a direct midi to abc midi converter. As far as I know midi2abc is > the only one available although I've heard rumours of others as well. > abc2midi does a reasonably good job as long as the midi input is "clean" > (that is no performance data such as time shifting etc) the music isn't > in triple time and there are no dotted rhythms. > Creating optimal input files for abc2midi requires some experimenting > and unconventional solutions, though. > > In any case you can just forget all about batch processing. You will > need some manual editing at some stage no matter how you do it. > > Frank Nordberg > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: DA:
Hello, James Allwright wrote: > > You are right, there is no satisfying solution for it and this is a > > shame. On the other hand it could simply and instantainously be done by > > implementing a DA: = dance field into the header. Since there is no such > > field, it cannot make any existing abc's outdated, and since it is not > > active, I belive it could be used from now on. > Sorry, this won't work. You can only have 1 character before the colon, > otherwise you are going to have lots of parsers complaining. It is a pity if it is that way. And my copy of barfly did not complain on a first try. So its definitely something which the actuall programs rely on ? In my simple mind the rule could also have been: accept (between linebreak linebreak X: and the first K:) as a header what is between a line break and the next colon. I see it: [from the standard:] ...that any line beginning with a letter in the range A-Z and immediately followed by a : is interpreted as a field... ...archive fields do not affect the output at all... - (practically as long as "fields" with two letters are restricted to the header area and use just those letters used in archive fields they could not do any harm. The question then would be if any indexing application would support it. I am willing to change the standard if it does no harm to actuall programs and therefore existing abc files) regards, Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Schiarazula Marazula (was: what's the problem with...)
Hello Frank, are these three accompanying voices really original ? Its just that I wonder about the G,, D, G, in the drone, to my experience as drone based musician G,, G, D would sound more musically - but indeed less "peasant like". At all I would solemly write "drone in G d g obligatory". I know this melody as from the Paix collection via a hungarian book, it is vry popular here with drone based instruments. Simon Wascher - Vienna, Austria Frank Nordberg wrote: > (...) Of course the ungarescha is really a bagpipe piece, so it doesn't really count. > But even so - although Mainerio's dance band arrangements certainly have > many qualities, complex polyphony isn't one of them. > > Frank Nordberg > > ___ > > X:1 > T:Ungarescha > C:Giorgio Mainerio > V:1 Program 1 110 > V:2 Program 2 42 > V:3 Program 3 40 alto > V:4 Program 4 43 bass > M:C| > L:1/4 > K:Gmix > V:1 > GGAG|GDDE/F/|GGAG|D2D2::BBBA/B/| > V:2 > G,4|G,4|G,4|G,4::G,4| > V:3 > D,4|D,4|D,4|D,4::D,4| > V:4 > G,,4|G,,4|G,,4|G,,4::G,,4| > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Tune finder, collections, header fields
> > information in question. > Nobody seems to be using it; whatever usage gets agreed on, it'll > be years before there are enough files containing it for it to be > worthwhile for the Tune Finder to search on it. We are talking about info that cannot be stored propperly in the moment anyway. To start something new always takes its time. I am not an expert but to my expirience it cannot be a big problem to store the content of empty fields in the tune finder. So Lets ask John Chambers about this ? regards Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Tune finder, collections, header fields, was [ Re: [abcusers] alchemical music ]
Hello, Jack Campin wrote: (...) relating to the Tune Finder. The problem is that a typical pair of alternate > titles from that collection is: > T:Appone mulieri super mammas bufonem, ut ablactet eum, et moriatur mulier, sitque >bufo grossus de lacte > (...) This might be worth doing for other instances where people have encoded > entire collections - if the first entry is of the form >X:0 >T:Skye Collection > (...) And if somebody enters "Skye Collection" as a search > string that'll most likely be what they want to happen. noplisnot! If there is a need of searching the tunefinder for the source or book a tune is taken from it would be reasonable to ask for the S: and the B: fields to be included in the tunefinder. Please do not change the way of writing a abc header to bend it to the needs of an peripheral application. The abc format gives advice where to store such info. It will not make things better to establish some primitive dialectinstead. B:bookyes yes archive B:O'Neills S:source yes S:collected in Brittany Maybe it would be a reasonable effort to give some detail information for these fields in the comentary section of the standard. To me B: is the print from which I transcribed and/or a book in which this tune can be found in a similar version (I use "B:from:" to indicate the first and "B:also in:" for the second). S:is the source in the scientific meaning - the manuscript or even the person who carried the tradition. In the Z: field I store info about the transcriber to abc by the way I do not know about te exact use of the "F:" field, can someone show me. Maybe this would be a better place to store the information in question. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Line endings (was: Susato's Danseryes)
Hello Frank, Frank Nordberg wrote: > Simon Wascher wrote: > > I use a freeware Mac editor called BBEdit Lite, which I use a lot for > > editing my abc files anyway, for doing this job. > Oh, I use BBEdit too, but I wasn't aware of that feature since it's > hidden in the preferences settings, rather than in the save dialogue as > in SaintEdit. Its also hidden in the "save as" dialogue: in its options dialogue there is a pop up menu for line breakes: Macintosh/Unix/DOS. Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Susato's Danseryes
Hallo, Frank Nordberg wrote: > Oh well, here's my summary: (...) > 4. P: field (...) > I don't think many ABC applications supports things like > P: Reprise Barfly and abc2ps do accept the P:field in the body as a simple text string above the bar if there is no P:field in the header (BarFly opens a dialog-window if you use a P:field in the header which does not follow the standard, you have to quit this before playback is continued) and I think most other programs will too (please users and authors of other programs, give us a report). > 5. Line terminators > > RJP wrote: > > This file has terminated lines... > > I'm afraid that problem is a bit beyond me. As far as I know, SaintEdit > is the only Macintosh text processor that allows you to specify line > terminators, and I don't fancy opening each and every Musica Viva > document in SaintEdit before uploading. I use a freeware Mac editor called BBEdit Lite, which I use a lot for editing my abc files anyway, for doing this job. > > Any suggestions for solving this? At the long run, the best would be if abc programs themselves would have this editing facilities to specify line terminators and/or can recognize, accept, replace all kinds and combinations of linebreakes. regards Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] which ABC software
Hello Otokar, Laurie is quite right, but maybe it is a help if some people simply tell directly you what programms they are using. About the playing tempo, for a simple solution you maybe know anyway see below. "Kverka, Otakar" wrote: > which ABC software would you recommend for advanced ABC user? > - play at selected speed (a possibility to easily select between standard > and "my" speed would be useful) - perhaps the ABC standard could be modified > to have a line with "my preferred playback speed" . Then just a button to > switch between the "standard speed" and "my speed"... For selecting a playback speed, you can and I think that is right for all programs since it is format standard use a Q:field in the header, the number entered in this field defines the playback speed. standard 1.6: "Q - tempo; can be used to specify the notes per minute, e.g. if the default note length is an eighth note then Q:120 or Q:C=120 is 120 eighth notes per minute. Similarly Q:C3=40 would be 40 dotted quarter notes per minute. An absolute tempo may also be set, e.g. Q:1/8=120 is also 120 eighth notes per minute, irrespective of the default note length." It is easy to have an alternative Q:field behind a "%" sign that is activated just when the "%" is removed, like: Q:90 %Q:120 %my prefered playback speed regards Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Susato's Danseryes
Jack Campin wrote: > >Simon Wascher wrote: > > I would find it much better to write the music voice after voice. It > > is not really possible to read the four voices in parallel in the abc > > text anyway > > Not unless the source is laid out helpfully, but for this sort of > music it can be quite easily. Its a pitty that not all the music is that helpfully :o) (...) > V:1 E/ F/ G G G |G3 F |E C C D |B,2 G,2 |E/ F/ G G G |G3 F |E C C D >|G,2 G,2:| how are you doing with beamed music ? Most the traditional music I am dealing with is made up from 1/8 and 1/16 notes. The beams contain a lot of the rhythmical information. (...) > > and it is complicate to extract parts for playing. > This is a pretty trivial editing task, BarFly has most of this > functionality built in already, and it can't take more than a few > lines of some scripting/patternmatching language to achieve it. I am a user :-) regards Simon Wascher To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: P:field [Re: [abcusers] Susato's Danseryes]
John Chambers wrote: > > Hello, > Simon Wascher schrieb: (...) > | $ Example: P:[Einleitung][1.][1.][2.][2.][1.][Ausgang] John Chambers wrote: > Less messy would be to just use either of: > $ Example: P:Einleitung,1,1,2,2,1,Ausgang > $ Example: P:Einleitung 1 1 2 2 1 Ausgang > > These are both unambiguous and more readable. (The dot after the number was intended to be printed: "1." in the P:field in the body) My intention was a standard that allows empty spaces, commas and other common characters within an active P:field, I thought that squared brackets as separators are the most un-used but commonly known and available characters, which also have the advantage to have a direction, so there is a clear i n b e t w e e n (and in opposit to < > they are not html). Examples: P:second part (why not?) P:Einleitung, auch als Coda regards Simon To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Advisory accidentals
Hello, John Chambers wrote: > Simon Wascher writes: > | I usually use "#"A or "b"A to show editorial accidentals. > One thing to beware of here is that in some > musical circles, an accental above (or below) the note is used to > mean "just this one note". Its the same with me. For me using "#" would mean that I have to write it every time. If it is a general accidental... How would it be to write: X:1 M:none L:1/4 K:G %one # in the source "one # in the source"|[K:D]| (...) > Some people > use parens around accidentals to mean that the accidental is > optional; the note may be played either way. again :-) Simon Wascher To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Susato's Danseryes
Hello, Phil Taylor wrote: > Simon Wascher wrote: > >I would find it much better to write the > >music voice after voice. (...) > I disagree. Writing the abc line by line preserves the original > music layout in the abc, Not necessarily, especially not if the original layout is no score but single parts. and I find it much more readable. I notice, > however that in some of the pieces you have two lines in each voice. > This seems to me to be the worst possible compromise. that is not a compromise, that is a consequence. Since I need eight bars per line in music display, the linebreak follows after the eight bar. Since eight bars are very long and may cause corrupted linebreakes for example in e-mails, I regulary put a backslash after every fourth bar (this also makes the structure of the tune transparent). regards Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
P:field [Re: [abcusers] Susato's Danseryes]
Hello again, Frank Nordberg wrote: > http://www.musicaviva.com/abc/tunes/susato-tielman/susato-1551.abc > My transcriptions raises a few interesting questions regarding > ABC-versions of early music. Should we add barlines? How do we disern > between original and editorial accidentals? etc. etc. etc. > Anybody's views on those question are much apreciated. So are any error > reprots, of course. Why do'nt you use the P:field within the tune body for the "Reprise" text? I know this is not classical standard, but if there is no P: in the header, there is no reason not to use the P:field in the body for something that is in fact exactly in the meaning of "Part". To my personal understanding I always wonder why someone created a field that organizes the playing order and does not allow the usual part and playing order terms to be used within. This is the standard: P - parts; can be used in the header to state the order in which the tune parts are played, i.e. P:ABABCDCD, and then inside the tune to mark each part, i.e. P:A or P:B. In fact, the P: field mixes up two things in an unfortunate way: P: as in part P: as in playing order (of these parts) So my sugestion to an extension of the standard is: $ instead of single letters numbers or words can be used. Within $ the header these words or numbers need to be in [square brackets]. $ Example: P:[Einleitung][1.][1.][2.][2.][1.][Ausgang] $ To enable this the words or numbers in the playing order within $ the header need to equal exactly the words and numbers of the $ P:fields in the body of the tune. $ If there is no P:field in the header of the tune the contents of $ the P:fields within the tune body are just text, and should be $ used for usual terms for marking parts. If my english is not sufficient please correct me, I hope you can get the meaning. regards Simon Wascher -Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Susato's Danseryes
Frank Nordberg wrote: > > Just like to tell everybody at abcusers that I've just posted a complete > ABC edition of Tielman Susato's "Danserye" Hey great, thats really nice. > My transcriptions raises a few interesting questions regarding > ABC-versions of early music. Should we add barlines? How do we disern > between original and editorial accidentals? etc. etc. etc. > Anybody's views on those question are much apreciated. I usually use "#"A or "b"A to show editorial accidentals. About the barlines, I would primarily say no, lets give the source as pure as possible, but maybe for the sake of usability just add a note: no barlines in the source. I would find it much better to write the music voice after voice. It is not really possible to read the four voices in paralell in the abc text anyway and it is complicate to extract parts for playing. I still find that programmers should enable voice after voice input. The way it is here simply mixes up text matters and layout matters (not your fault). Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE: ABC transcrivers ID
Hello,
Richard Robinson wrote:
(...)
> I dunno. Personally, since I need such a numbering scheme, I'm using a
> %%ID: line, on the grounds that it won't conflict with any
> accepted usages; and when I get that sorted out and it reaches my
> web-collection I'll use another such '%%' line for the 'base' collection,
> or maybe (probably) to form a URL. Such a scheme will never be more than
> one person's particular addition unless the writers of the software in use
> choose to incorporate it. Even then there's always "the John Chambers
> Case" - people who read ABC directly and can't even be bothered to include
> an X: line :- but we can't do anything about that :)
I think its quite clear that it is impossible to enforce whatever
numbering scheme to all abc format users, so the only question is if we
can find a solution that is based on an agreement of a large number of
abc collection owners (and programmers) an so reasonable and open that
others join it because they find the agreement sensible.
It could be something like the identification system in librarys,
probably made up the same way (are there librarians out there ?). And
the main problem will still not be solved, that nobody can stop people
from stripping off all this usefull information when copying the source.
Besides this there is a big problem with altered files in general: If I
change the apperance of the abc text - like I do it regulary - "whose"
file is it then, if I correct or alter the abc text - the music - what
happens then ?
Again we could - and should - make up a code of conduct for this cases
but there is no way of enforcing this, just the personal decision to
follow the rules for the sake of a better world ;-) .
An unique ID has to be long: if there are collections which include
large sources ("1001 tunes..." or many tunes of the same kind, one needs
at least four digits to to idenify them within the file or collection,
and if there are more sources or kinds of tunes, at least three digits
for identifying them (better more). If we use letters and numbers for
identfying the "place", "person" or "collection" three digits for this
purpose will not be enough if we do not want people to use names like
"7QX". So, at shortest a ID has to allow at least eleven digits and, if
we want to make these ID's to give further information (person,
collection, area ...), eleven will surely not be enough.
I opt against Zip codes or geographical names in an ID as they lose
their meaning in the same way that URL's do when the person moves.
To avoid double use there has to be a record of ID's which are in use or
had been used in the past (also this record could contain information
about the author like suporting the actuall URL; this record must be at
a "save place" in the net, available for a long period of time).
So, I find this idea interesting, but I think this must be discussed and
planned in long terms.
regards,
Simon Wascher - Vienna, Austria
Example
thats what I got:
X:1
T:Valse à Delsay
R:valse
S:"Culture Populaire et Loisirs", Poitou
M:3/4
L:1/8
K:G
D2 |GDB,DGD|BDB,DGD|B2 ADFA|G2 B2 D2 |
GDB,DGD|BDB,DGD|B2 ADFA|1 G4 :|2 G3
|: DGB|d2 dedc|B2 GDGD|c2 ADAD|B2 GDGB|
d2 dedc|B2 GDGD|c2 ADAD|1 G3:|2 G4 ||
thats what I made up for me, and passed on for playing purposes:
X:2
T:Valse à Delsay (adaptiert fuer sack-pfeife)
R:valse
S:"Culture Populaire et Loisirs", PoitouZ
Z:original abc transcription by Stephan Steiner
N:adaptiert by Simon Wascher
M:3/4
L:1/8
K:G
D2 |\
BGDGBG | dGDGBG | d2 cFAc | B2 d2 D2 |\
BGDGBG | dGDGBG | d2 cFAc |1 B4 :|\
[2 B3 ||
|: DGB |\
d2 dedc | B2 GDGD | c2 ADAD | B2 GDGB |
d2 dedc | B2 GDGD | c2 ADAD |1 G3:|\
[2 G4 ||
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] German H as an alternative to B
Hello, Frank Nordberg wrote: > John Chambers wrote: > > (...) But on the whole, bad notation tends to die out > > and better notation tends to spread. > > I've got a bad feeling this pure Darwinistic view is a bit too simple. > Just look at the state of various computer standards... as I see it, the five line seven note-names twelve halfstep note system is evidence for the "survival of the practice". It did not survive because it is the best but simply because peolpe who got used to it (for example practiced sight reading for years) did not want to give it up when they reached its limits, so they glued another extention onto its edge and another and another. There were hundreds of attempts of designing a more intelligent and more general notation system, but practically none survived (do you know the notation system by Josef Matthias Hauer ?). Simon Wascher To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] German H as an alternative to B
Hello, do not get e wrong, I am not speaking for abc dialects, but for peripheral programs which can be used as input interface or for editing purposes. The abc notation text would not be changed from this. It would be a bit like writing html directly or writing html via a supporting programming tool. Simon John Chambers wrote: > Simon Wascher schrieb: (..) > | But following the line of things like H, do re mi, etc. isnt'n it the > | advantage of computers to be able to translate between the differnt > | languages in no time? Maybe we shold have more than one eye on > | peripheral programms which interprete from language to language via abc > | format? Why not having program versions of an abc programms which > | includes all these things like an B/H/si substitution. The abc text > | itself must not be tangented, but the usability would be more > | international. > > The main practical problem is that the computer needs to know what > dialect it is dealing with. We've had the suggestion that all abc > tunes should start with something like: > %abc ... > > The ... would be extra information to identify the dialect. This sort > of suggestion is easy to make, of course. But organizing a list of > recognizable words for the ... part isn't easy, and getting people > (and software) to use them correctly is even more difficult. We are > faced with a user population that can't even bother to write "X:1" at > the start of a tune. How are we going to get them to put two extra > lines at the start? And note that few musicians will ever understand > the concept of ABC dialects. Whatever my favorite ABC tool produces > is ABC, and all the rest are wrong, you know. > > There's also an implementation problem. I could very easily write a > pair of translators in perl to go between standard ABC and the "H" > notation. I'd even give them away for free. Then a line like >%abc 2.1 German > could be recognized and would invoke the appropriate translator. > > But this doesn't suffice. As others have pointed out, perl doesn't > come installed on most commercial systems, although it may be > available. If it's not installed, few users will ever install it. > Some other language? Which one? There is no universally-available > programming language. Java might come close, but it's not much closer > than perl, and has some serious compatibility problems (and has a > library that still can't even handle time zones ;-). > > Also, as others have pointed out, the idea of a little plugin program > to do such translations is only easy on unix-like systems. On other > OSs, there is a strong preference for large, monolithic applications. > So you can't just take someone else's little translator script and > plug it in; you have to write your own version as a subroutine in > every ABC program. This takes a lot of programmer time, which means > that on non-unix systems most translators would never be included. > > One thing I'm considering in a future version of my Tune Finder is > support for such translators and other filters. We recently had a > macro expander posted, and I'll probably use it as a prototype for > such a filter. Maybe I will write a "German" filter, to have a second > example. Then if I can get a few people to add "German" to their %abc > line, we can see how well it works. > > I wonder what a French version of ABC would look like? I've also seen > a traditional notation from India that is "alphabetic", in the sense > that it uses the Hindi/Sanskrit writing system. Unicode is rapidly > coming online in the unix environment. Maybe we could write filters > to translate between Indian notation and ABC. Then, due to the great > demand, all the fancy ABC GUI tools would have to incorporate it ... > > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] German H as an alternative to B
Hello, I think you are right with the rejection of the H notation, but at the same time, you should be aware of a lot of anglizisms in abc notation format. Before thinking about abc formatting as an universal standard there are some hurdles to take :o) : As someone mentioned it is stil derivated from stone age five-line/tewelve-key notation and its all english in the moment. I still disbelive in abc as an universal music language, I prefer it as notation system for traditional music based on european classical traditions. And practically spoken there is no german speaking (or any other language exept english) site to promote abc format, no text on abc in the whole net exept english. But following the line of things like H, do re mi, etc. isnt'n it the advantage of computers to be able to translate between the differnt languages in no time? Maybe we shold have more than one eye on peripheral programms which interprete from language to language via abc format? Why not having program versions of an abc programms which includes all these things like an B/H/si substitution. The abc text itself must not be tangented, but the usability would be more international. Simon Wascher - Vienna, Austria John Chambers wrote: (...) > There are some extensions that should be added to abc to make it > handle some kinds of music that it can't handle well yet. But some > notation we should simply refuse to support. Instead, we should try > to make abc into a more consistent and universal notation. The > difference isn't always obvious, of course, and it's worthwhile to > discuss such things. The German "H" notation is probably a good > example to put in the "rejected" list, with the comment that we have > an opportunity to kill off what is really just bad notation (even > within the tradition that developed it). > (...) > (OTOH, it might be worthwhile to discuss similar situations where we > want preprocessors to translate between ABC and other notations. If > we can keep ABC's syntax sufficiently simple that such translators > can be written easily, we will make ABC into a more useful universal > notation. Various tablatures come to mind which, despite the constant > problems with their narrow usability, are very practical to some > musicians. If we can encourage such notations to be stored in ABC and > generated "on the fly" by translators, we will go a long way toward > bringing their users into the wider community.) > > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] German H as an alternative to B
Hello, Here in vienna there is a guy who wrote a javascript that makes it possible to write abc with h and does an automatic replacement to b in the abc text. I am abit in a hurry in the moment but maybe someone on the list remembers the posting. About the H in the chords, I think a "german" program version is possible, it could be added to programs that when ever transposing chords, H and h in the chord are treated like B and b, the problem in fact would be the treatment of the german B and b but an maybe all acceptable compromise would be to accept the _B and _b for the german B and b in "german" abc notation (better to me than _H and h). Whithin the music body H is interpreted by abc programs as fermata, so simply accepting H as a substitute for B cannot work that easy. Simon Wascher - Vienna, Austria Laurenz Wiskott wrote: > > Dear abcusers, > > in German notation we use an H instead of a B, so that the C-Scale becomes > C D E F G A H c, and a B instead of a Bb, so that the F-Scale becomes F G A > B c d e f. (I know it is not logical, but it has developed that way.) > > I therefore would like to suggest that in abc-format H and h become valid > alternatives for B and b, respectively, in indicating the pitch of a note > and the accompaniment chords. To avoid confusion, however, a German B, > must then be indicated as Hb (or _H) and not as B. > > Well, this suggestion is not so essential for the notes, since after > applying abc2ps or so, there is no difference in any case. For the chords, > however, one cannot write B instead of H in German notation, because that > would mean Bb in international notation. Using Hb (German) instead of B > (German) would be a bit strange but consistent. I know I can write > whatever I want as the accompaniment chords, but if the tune shall be > played by a program it becomes important. > > An alternative might be to use only B and no H and introduce something like > a German flag that tells interpreting programs to replace all occurences of > B in the accompaniment chords by H. However, I am afraid that half of the > programs will not care about the flag and still print B, and those that > care might replace all occurences of B, even if not appropriate. This > solution seems to be more complicated to implement. But it would have the > advantage that one could use B in German notation instead of Bb in > international notation. > > What do you think? > > Best regards, Laurenz Wiskott. > > -- > Dr. Laurenz Wiskott, Innovationskolleg Theoretische Biologie, Berlin > http://itb.biologie.hu-berlin.de/~wiskott/ > [EMAIL PROTECTED] > > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] net-friendly information
Hello, isn't this information "O'Neill's 1001" etc. exactly what one would expect to be the content of the "B:" Field ? I see the advantages of an super-file-index-number, but why not simply ad an URL like JC's tunefinder does ? I think nobody can change habits of usin messie X: but it cannot be to complicate to count the number of X: fields and create a "virtual" X: number and even if there is no X. field to count the numbers of tune headers. If things get too messie nothing can help. the output could be a F: field containing the URL/file adress, the "virtual X:" number and the date and time of creation. (Barfly 1.30 dislikes text after the X: number, [%if it is not comented out]) hoping to add something usefull, Simon Wascher John Chambers wrote: (...) > O'Neill numbered the tunes in his > books, and that number is the obvious X index. But if it wouldn't > bother any software, it would be useful if I could augment it along > the lines of: > > X:123 "O'Neill's 1001" > T:Young Francis Mooney > ... > > X:123 "O'Neill's 1850" > T:Old Truagh > ... > > X:123 "O'Neill's Waifs" > T:Jackson's Silver Mines To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] maintaining the sources dealing with traditional music
Hello John, Thanks a lot! give you a big hug for this quick and good response! regards :-) Simon Wascher John Chambers wrote: (...) > However, I can do something simple in the meantime: I just changed > the way that the tune is converted, which is done by abc2ps. I added > the -n option, so that all the header information is now printed. > This will make the output wordier, and I expect some people will > complain. But it may help with your problem. Try it and see if it's > acceptable. If it is, I'll leave it this way, and ignore complaints > from people who don't want all this extra stuff.. (...) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] maintaining the sources dealing with traditional music
Hello, just now I tried arround with Johns your tune-finder, because I wanted to recomend it to some german folk-mailing list. And I found that there is a problem that from my point is very serious: Much of the music on my site is from traditional music archives and can be used for free, is without any copyright troubles beside that it must be distributed only with its original source, the archive in question, usually content of the S: field in my tune headers. Sometimes there is no S: field, since my source is a publication by those archives and so the content is in the B: field. In the GIF's PNG's PDF and I supose also in the EPS and PS files which the tunefinder supports, neither the B: nor the S: field contents are included. So the crucial information is not passed on, especially if someone does a printout. In my PS printouts I substitute the "B:" and "S:" with "C:book:" and C:source" I am not sure what to do now. I do not want to remove the files, but there must be a change in the way they appear in the public. Maybe it works to replace all "B:" and "S:" with "C:book:" and C:source:", but I also do not know whether multiple C: fields are commonly supported. I write this to the mailing list and not directly to John since I am sure the tune-finder is not the only troublemaker. I also belive strongly that in our discussions on copyright-composers/rights dealing with traditional music must also mean discussion on maintaining the sources. One first attempt could be to support the original URL and, if given in the abc tune header, mail adress with every printout and whith every copying from file to file, but print tends to be passed on to non netties so a real support of the "B:" and "S:" contents is needed. regards Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] accents and other signs
Hello, Eric Galluzzo wrote: > On 17 Jul 2001 20:17:43 +0100, Phil Taylor wrote: > > So, if you want the letter Q to signify the inverted fermata you write: > > U: Q = invertedfermata > > No exclamation marks required. > > This is great, and really quite elegant; however, it means that the > number of symbols permitted in a piece will be quite small. In > particular, I frequently use a lot of dynamics in my pieces (...) which takes care of twelve of the available nineteen symbols right > there. If I have a segno and D.S. in my piece, that's two more > (fourteen total); if I further need wedges, tenuto (legato) marks, > fermatas, mordents and trills, that's already up to nineteen, even with > the most commonly used symbols. (...) > Another thing to consider is that various people are considering using R > for repeat bar, Z for whole-bar rest (Z4 for four bars' rest), X for > whole silent bar, etc. This seems very useful, and it cuts down the > number of available symbols to sixteen. to me, abc notation format was created to fit the needs of "european" traditional music. I use it because other "classical" music notation programs as Finale fail in supporting multi-tune files with short, eight to thirty-two bar tunes and especially using abc2ps and a .fmt file give a nice and easiely done output for my traditional music compilations, and even the instumental tutor with mixed music and text passages I am preparing in the moment. I think abc notation format does not need to be the "better Finale" supporting all the classical notation specials. On the other hand, why not adding an extra mechanism for those who deserve it (ask me, they would be better up using "Finale" or something similar), as long as this does not interfere with the existing abc format, so for example extending the "Chord" i.e. "_text" mechanism is no god idea at al since it may interfere with existing abc files in the web. the same with using the * character since it is used in some abc interpreting programs. And I hope these extentions do not blow up the size of and slow down the speed of the programs which support them. > > I really like the U: mechanism, but I don't think that it's enough: I > think that we need to be able to specify each symbol longhand as well. > I don't personally care whether we use ! ! or ` ` or * * or what, but I > think it would really be handy. > Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Shingly Beach...s
Jon McNamara wrote: > >Part 1.1Type: Plain Text (text/plain) >Encoding: quoted-printable I don't know how good the ABC is - I can play these in ABCMUS but not in ABC2WIN - so something is strange somewhere - if anyone knows what I'm doing wrong - I love to know! (...) THe display below seems to be double spaced ... again I don't know why! Simon: I think a double spaced abc text cannot work at all since an empty line marks the end of a tune in abc format, for getting it working maybe just remove the empty lines. Jon McNamara wrote: (...) X:1 T:Shingly Beach C:Tom Andeson M:4/4 L:1/8 Q:1/4=120 %Tempo K:G %!STAVE 0 'Piano 1' @ %!INSTR 'Piano 1 [Ch1]' 0 0 @ M:4/4 %Meter L:1/8 % K:G z7 D |G4 c4 |Bd cA F2 D2 |G2 Bd E2 Ac | D2 FA C2 FA | (...) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Hello, Anselm Lingnau wrote: > > Bryan Creer <[EMAIL PROTECTED]> writes: > > Great idea. I might use this for cross fingering on English concertina and > > perhaps I could adapt it to indicate forked F on the oboe. > > I expect lots of other people could come up with ideas for how to use it for > > their chosen instrument. > That's right, but then when you receive an ABC file you need a way to > figure out (...) We would > probably need to put in a header saying > %%fingering concertina > or some such, and software might have the option of including the > fingering only if it was desired. (...) Why changing the standards for every personal need every time! there are really good tools within the actual standards to express all those things. Just to mention the "N:" field where one can include all kinds of usefull and other info about the tune or the weather at transcribing time, the "P:" field which if not used in the header for playing order is just a string of text above a line of music, the "%" character which excludes text from being recognized by abc-programs so again can be used to add whatever one wants to write down. In abc2ps a text or block of text can be added using "%%text" and "%%begintext" plus "%%endtext". In fact if one really needs to get all info into the printed music or just a good looking screen display simpy use abc2ps and (and a .ps viewer and maybe a .fmt file) or something alike. If it is just to get the info ino the abc-file use "N:" or "P:" or "W:" or "w:" or "Guitarchords" or simlpy "%". I hope this was not to mercyless, I still look foreward to every usefull addition to the standards. Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software
Hello,
I use w: lines to include extra information with the notes and I use the
guitar chord "" signs too ("pos.1" is about the position of the crank
and the numbers represent the fingers of the left hand 4=little
1=index). To use "w:" for the fingering makes sense for my purpose
because normally there is a finger to every note.
examlpe:
X:1
M:none
L:1/4
K:C
"pos.1"ABcd | "pos.1"efga :|
w:4 3 2 1 4 3 2 1
Simon Wascher
[EMAIL PROTECTED] wrote:
> Laurie Griffiths said -
>> Muse uses ; to include fingering hints in ABC.
>> i.e. a3;4 means play the a on the 4th string (probably
>> at the 12th fret for guitar).
> Great idea. I might use this for cross fingering on English concertina and
> perhaps I could adapt it to indicate forked F on the oboe.
> I expect lots of other people could come up with ideas for how to use it for
> their chosen instrument.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
AW: [abcusers] Does anybody kow this ballad?
Hello Frank, This is one of my favorite ballads on Julie Murphys "black Mountais revisited" album, when I am back home I will see if there is any source given cu Simon > > Von: Frank Nordberg <[EMAIL PROTECTED]> > Datum: 2001/06/20 Wed PM 12:26:10 CEST > An: abcusers <[EMAIL PROTECTED]> > Betreff: [abcusers] Does anybody kow this ballad? > > Perhaps a little digression from all the serious talk recently. A few > weeks ago I suddenly realized that the title track of Pentangle's Cruel > Sister is the same (rather grotesque) story as "Harpen", one of the best > known Norwegian medieval ballads. > > Obviously, neither Pentangle's version nor the "official" Norwegian are > originals - Pentangle's is clearly late 16th Century, while the ones you > find in Norwegian collections are even more recent. Also, the ballad > seems to have some stylistic traits that suggest it's neither British > nor Norwegian originally. > > Does anybody have any information about the ballad? > > Frank Nordberg > > --- > > Here's the Pentangle ballad. My stone disk player is a bit unreliable at > the moment, so I had to write down the music from memory, but I think I > got it right. > > Oh, and by the way - this one is sure to get messed up in the e mail. > But I couldn't find *any* way to get the words through in a way that > abc2ps could figure out :-( > > X:1 > T:Cruel sister > C:anon. > O:Scotland? > N:Based on Pentangle's recording (written down from memory) > Z:Transcribed by Frank Nordberg - http://www.musicaviva.com > M:3/4 > L:1/8 > Q:1/4=88 > K:Dm > %Verses 1 and 3: > z A, DE|"Dm"F>F EF GF|"A"E3 z FG|"F"A2AG A w:There lived a lad-y by the North Sea shore. (Lay the bent to the > bon-nie broom) Two daught-ers > "Dm"F3(E/F/) GF|"C"E3 z "Dm"D E/F/|"C"GF EE|"Dm"D2|] > w:were the_ babes she bore (Fa la la la la la la la la la) > %Other verses: > z A, DE|"Dm"F3(E/F/) GF|"A"E3 z FG|"F"A2AG A w:As one grew bright as in the sun, (Lay the bent to the bon-nie broom) > so coal black > "Dm"F3(E/F/) GF|"C"E3 z "Dm"D E/F/|"C"GF EE|"Dm"D2|] > w:grew the_ oth-er one. (Fa la la la la la la la la la) > W: > W:There lived a lady by the North Sea shore. > W: Lay the bent to the bonnie broom > W:Two daughters were the babes she bore. > W: Fa la la la la la la la la la > W: > W:As one grew bright as in the sun, > W:so coal black grew the other one. > W: > W:A knight came riding to the lady's door. > W:He'd travelled far to be their wooer. > W: > W:He courted one with gloves and rings, > W:but loved the other above all things. > W: > W:Oh sister will you go with me > W:to watch the ships sail on the sea? > W: > W:She took her sister by the hand > W:and led her down to the North Sea strand. > W: > W:And as they stood on the windy shore, > W:the dark girl threw her sister o'er. > W: > W:Sometimes she sank, sometimes she swam, > W:crying "sister, reach to me your hand. > W: > W:Oh sister, sister let me live, > W:and all that's mine I'll surely give." > W: > W:"It's your truelove I'll have and more, > W:but thou shalt never come ashore." > W: > W:And there she floated like a swan. > W:The salt sea bore her body on. > W: > W:Two minstrels walked along the strand > W:and saw the maiden float to land. > W: > W:They made a harp of her breast bone > W:whose sound would melt a heart of stone. > W: > W:They took three locks of her yellow hair > W:and with them strung the harp so rare. > W: > W:They went into her father's hall > W:to play the harp before them all. > W: > W:But as they laid it on a stone, > W:the harp began to play alone. > W: > W:The first string sang a doleful sound; > W:The bride her younger sister drwoned. > W: > W:The second string as that they tried, > W:in terror sits the black-haired bride. > W: > W:The third string sang beneath their bow, > W:and surely now her tears will flow. > > --- > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html > To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Re: Page set-up in abc4mac
Hello, [EMAIL PROTECTED] wrote: (...)> So I tried it. I can't get it to work. I fed the following abc > through abc4mac: > X:1 > E:lw 360 % 5 inches > T:Line width test 360 in header > M:C > K:C > CDEF GABc|CDEF GABc|CDEF GABc|CDEF GABc|] > X:2 > T:Line width test 360 in music > M:C > K:C > E:lw 360 % 5 inches > CDEF GABc|CDEF GABc|CDEF GABc|CDEF GABc|] (...) > I displayed the resulting ps file in MacGSView at 100% size. All > four "tunes" appeared identical and had a staff width of 493 pt > (6.85 inches). This, unfortunately, is not close enough to 6.5" > to satisfy the needs of my project. (...) > Any other ideas? Or does anybody see what I did wrong? somewhere in the context of pseudocomments with abc2ps I read that a pseudocomment (wich is maybe another solution to your problem if this is working in abc4mac) if applying to a certain tune has to be AFTER the T:field. Probably an E:field like this has to be part of the header meaning before the first K:field. At least this is a version which you did not try. try: %%staffwidth 6.50in X:1 T:Line width test 360 in header M:C K:C CDEF GABc|CDEF GABc|CDEF GABc|CDEF GABc|] this works with my version of abc2ps (used cm since I have no inch ruler). I tried your examples wit it and got no result too. ?:-| CU Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Page set-up in abc4mac
Hello,
John Chambers wrote:
(...)
> I did put together a start on a document a while ago:
>http://trillian.mit.edu/~jc/music/abc/doc/abc2ps_fmt.html (...)
Just these days I tried to figure out the meaning of all these .fmt
parameters.
Alltogether I still do not but would like to know the function of the
following parameters: maxshrink, indexfont, writehistory, parskipfac,
lineskipfac, auquality,
An I really would like to understand the mechanism behind those two
strictness parameters.
Here are my clues to some of these parameters which have no written
explanation in your file:
breakeall yes : the continuation characters ("\") are ignored
musicspace : I am not sure but I think if there is a P:field this is the
space between the C:field and the P: field
partsfont : font definition for the content of the P:field
strictness : I got the idea this is about notespacing the relation
between the space a long note takes and the space a short note
takes, but I do not know how this exactly works
sysstaffsep : If more than one staff is used here the space inbetween
the two staffs is set
systemsep : space between two staff systems
My acctual problem with formating are overfull barlines, how can I force
the music tighter together? (not changing the scale or staffwidth) I
hope someone out there knows the answer. and last but not least:Are
there possibilities to change the size, thickness, design of flaggs
beams, dots, noteheads, ... aem ... ALL :o)
Simon Wascher - Vienna, Austria
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: Page set-up in abc4mac
Hello, [EMAIL PROTECTED] wrote: > >I need to produce high resolution staff notation from abc files > >on a Mac, and it needs to be no more than 6.5 inches wide. here is not a perfect solution but a simple one: I use Barfly for doing such things: by changing output size and staff width one can achive any desired size and resolution of output. First put printer page size to lets say 50% (for better resolution) then put the page dimensions in the viewer preferences menu to custom, with page width to the desired width for your output. Export as pict. import the pict into the text or layout program you want to use. (on old word 5.1 one cannot change the size of the pict, but the size of the whole page can be enlarged to coope with those picts.) Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] intonation back to ABC
Hello, Laura Conrad wrote: (...) It should also drag this > discussion on intonation back to a discussion of ABC. I now use Barfly for some time and found that the implemented "Just intonation" choisse in the menue does (on my computer) not produce the scale I expected, so I would like to know what scale is this (a natural scale?). On the other hand it made me dream about a menue feature: A dialog field is opened which gives the opportunity to customize the scale. The user can define the intonation for each of the twelve notes for example by entering a number between 1. and 2. Two alternatives should be given: 1) Absolut pitch: in this mode like in an tempered system these numbers aply fixed to the note (name) in question. So if the tonal center is moved (the K: field changes) you get a different coulor within the scale. 2) Relative pitch: in this mode the basic note allways moves to the tonal center, meaning according to the K:field. I do understand nothing about programming so I cannot even get an idea how complicate it is to implement such a feature but I love to dream. Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers](nearly)OT intonation - Fomula for determining a half step in
Hello John, It seems that together with the drone (I am hurdy gurdy player), the beat notes produced by the tempered fifth (and secund) are so strong that I missjudged the distance between perfect and equaly tempered fifth since I never worked on the math for tempered scales. I think the given G# is not the one I use wich is the seventh of A (11,25:8 is 1.40625). (to D). The D# which I use is the seventh of E (8,4375:8 is 1,0546875). SW John Walsh wrote: > reversed. Here is the table someone posted to the UP list. (Made up, I > am sure, with a hand calculator, not a tuner on a set of real pipes.) > Anyway, the second is reasonably close and the third is not, as you say, > but the fifth on the other hand is quite close. (There's an interesting > choice for the G#: the two possibilities differ by 35 cents.) > > NoteJust Ratio (to D)Equal tempered fraction Difference in cents > ---- - > D 1:1 1.00 0 > D# 16:151.0595+12 > E 9:8 1.1225+4 > Fnat6:5 1.1892+16 (!) > F# 5:4 1.2599-14 > G 4:3 1.3348-2 > G# 7:5 or 10:7 1.4142-17 or +18 > A 3:2 1.4983+2 > A# 8:5 1.5874+14 > B 5:3 1.6818-16 > Cnat9:5 1.7818+18 > C# 15:8 1.8878-12 > D 2:1 2.0 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] intonation - Fomula for determining a half step in
Phil Taylor wrote: > > That's a very dissonant interval (G#) so it probably doesn't matter > which you choose. If you want to modulate to the A then G# is the third of the dominant chord and therefore important and so it does matter. Best choisse is the third of E then. You also have a choice for the C natural, which > is much less dissonant. Instead of 9:5 you could use 16:9 which > comes out much closer to the equal tempered fraction (a couple of > cents flat). Need to do some careful listening tests to see which > sounds better. On the hurdygurdy I have the advantage to intonate the lower and push the key up to the higher :-) Simon Wascher To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] intonation - Fomula for determining a half step inMgHz...
hello, I wrote: > >consecutive fifths wich are about just intonation and divide the > >divergence between 12 just intonated fifths and the octave between the > >other fifths. As I remember, this specific system also includes a > >correction for the thirds. > Phil Taylor wrote: > I stand corrected. However, if the system used involved distributing > the accumulated error from twelve perfect fifths among all the notes, > the result will surely be an equally-tempered scale, even though it's > mathematical basis is different? I think I was not quite clear in my writing. what I wanted to describe is a intonation system based on 12 fifths which are from two (or more) different sizes. All 12 together have the same size as in an equal temperament but inside there are bigger and smaller fifths what makes it possible to have perfect fifths (and thirds) in favorised keys and such that are not so good at the far end of the circle of fifths. In case of Werckmeister the circle of the fifths is "closed" not only because thelve fifths equal the octave but also because all fifths are of musically usable size. For example there are no fifths which are to big, what would sound very bad (there are tonal systems wich include such fifths, meaning that one cannot play in all keys, but in the range of four or five keys these tuning systems sound very brilliant - these systems are very usefull for music from the sixtenth and sevententh century europe). So the kind of tunings people like Werckmeister worked out made it possible to play music like the "welltempered piano" because all the scales starting from all 12 (piano) keys are well sounding and even better, each has an individual coulor because of their different distance to the more brilliant center of tonalities arround these four or five perfect fifths. for music which does not use a 12 key (piano) keyboard there is no real need to use those intonation compromises. The color (intonation) of every interval, step or harmony can be choosen more freely and the A bevore the modulation must not be the same as after . Typical example: The A wich is the sixth of C is lower in many just intonation systems than the A as secund of G if C and G are common to and a perfect fifth in both keys. For computer generated music it should be possible to give up the equal tempered intonation and to calculate the intonation outgoing from the tonic center, maybe even when using a twelve key piano keyboard for input. Back to abc and traditional music this would for example mean that the K: signature should influence the intonation. Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] intonation - Fomula for determining a half step inMgHz...
Hello Phil, Phil Taylor wrote: > However, if the system used involved distributing > the accumulated error from twelve perfect fifths among all the notes, > the result will surely be an equally-tempered scale, even though it's > mathematical basis is different? 'xcuse I think I got the point of your question just in the second reading: The twelve fifths not only cumulate to meet the octav (more precise: five octaves) but also represent each by each one single note on the keyboard: B-E-A-D-G-C-F-Bb(=A#)-Eb(=D#)-Ab(=G#)-Db(=C#)-Gb(=F#)-Cb(=B*) , so making them smaller or larger means to change these notes (their equation on the keyboard) Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] intonation - Fomula for determining a half step in MgHz...
Hello, > John Walsh wrote: > > In fact, the even tempered scale hasn't completely taken over. The > uilleann pipes are usually tuned against the drones, and I imagine that is > also true of the highland pipes and other instruments like the vielle > which have drones. (...) To my understanding, there are two groups of tuning systems which both are forming the basis of western music: 1) tempered intonation scales Including everything from pythagorean to equal tempered. In this system some or all intervals are made gradually imperfect to open a wider range of chromatic changes more "playable" scales on a twelve key instrument (like the piano). The common idea starts at one specific point of the musical system: dealing with the difference between the octave and the accumulation of twelve fifths. The dominance of the twelve keys per octave instrument, which is in fact one of the major reasons for this kind of tonal system, has historical reasons not entirely musical. These tempered scales, in their notation system, note names, temper relations, even the twelve tone system of semi tones still refer to the other group of scale intonations the 2) just intonation scales (I do not really know if this is the right term in english the german term is "Skalen mit reiner Intonation") In this intonation the scale is assembled out of "perfect" simple ratio intervals the specific characteristic of a scale based on the relations of the used numbers. As an example two common scales of this type: the scale used by the Alphorn which just uses the harmonics of one basic note is constructed on the numbers 7 :8 :9 :10:11:12:13 b :c :d :e :f :g :a as one can see these numbers differ strongly against equal temperament. It is used today by traditional music, singers, fiddle players, not just Alphorn players! in many european regions. The scale most drone based instruments use (not just those): 24:27:30:32:36:40:45 c :d :e :f :g :a :b this proportions are based on the ratios of only three numbers, the first three indivisible numbers 2,3,5. This makes the scale more usefull for music which contains harmonies because there are less beat-notes (ger:interferenz-töne) than in the alphorn scale wich includes ratios of many numbers such as 7:11 >(...)This effectively means that they are in some kind of just tuning: > the ratio of the frequency of each note to the drone frequency is a simple > fraction with fairly low denominator. (...) It's close to the even tempered scale >for the fifth > and third, not so close with the second, for instance. (15-17 cents I disagree strongly! the just third is quite far from the equal tempered. and the fifth is really different too. > not so close with the second, for instance. In fact in those just intonation scales I know the perfect second is a very stable nearly consonant sound, seen as fifth of the fifth. Laura Conrad wrote: > > >>>>> "Phil" == Phil Taylor <[EMAIL PROTECTED]> writes: > > Phil> Yes and no. the expression "well-tempered" comes from the > Phil> title of Bach's two volumes of preludes and fugues. (...) > No, I think most people these days believe that Bach's Well-tempered > keyboard was not equal tempered. as far as I know it was well tempered following a system developed by a man called werckmeister. In systems like this you chose a number of consecutive fifths wich are about just intonation and divide the divergence between 12 just intonated fifths and the octave between the other fifths. As I remember, this specific system also includes a correction for the thirds. Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] small fragments?
John Chambers wrote: > I fed these URLs to my searcher to see if there were any that (...)> The following didn't turn up any ABC at all. Anyone know about > any of them, maybe a better URL to find the tunes? (...) The following is mine, > http://members.teleweb.at/simon.wascher/ better is: http://members.chello.at/simon.wascher/ the abc files can be found via internal links from http://members.chello.at/simon.wascher/homepage_abc.htm the abc files are text files each of them containing music for one dance form about 50 to 150 tunes per file. Since I was not able to update my homepage for some month some dance-forms are stil not posted. > http://www.fff.at/fff/dance/ I know this site, it deals with traditional dance, as far as I know, it contains no abc files but surely links to sites which contain abc files. Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Tune archive updated
Hello, Frank Nordberg wrote: (...) > This reminds me, btw. I forgot to list the contributors in my last message:(...) > Any corrections and additions to the URL list? Yes indeed. this URL is still working but the provider company was bought and so they changed all URS from "members.teleweb.at" to "members.chello.at" ( by the way what did you post from my stuff ? I could not recive your mail then and am curious :-) ) Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] to post or not to post?
Hello, Cindy wrote: > (...) Maybe I wasnt clear in stating that I was only interested in different >people's reason for not wanting their music posted (...) I was simply trying to get >a broader picture. So, I put a lot of music to the net which is in a way "public domain" because it is material from public folk music archives. The problem is that these archives allow publishing for free but only if the archive is mentioned in the publication together with the music. So when someone copies an abc file and removes the sometimes extensive notes about the source in the header of the tune or at the beginning of the file this is a violation of the rules which permit the free accsess to the archives. At the long term this may cause a change in the open policy of these archives, and cause a negative attitude against the internet. Second, the material from these archives is all traditional and it is illegal to put this music material under copyright. If the information about the origin of the music material gets lost, it may happen that someone tries, intended or by error, to put copyright on this music. Again in the long run this may cause a more repressive policy by these archives to prevent such illegal copyrighting. So: Allways make propper copyright and source notes to any abc you post and never remove such information from a tune header. Simon Wascher - Vienna, Austria To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
