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
Hello,
John Chambers:
Simon Wascher writes:
| I would like to add:
| [1+3
| and
| [13
(...)
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
'numeral' ending syntax:
1) all letters and obviously: '%', '\'
2) following chars cannot be the *last* char of a ending string (exept
in the proposed text case):
'+', '-', '.', '(', '[', '~', 'space', '_', '^', '=', '{',
In fact the last char in the numeral 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 numeral 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 [1,3
Hello, John Chambers: Well, the [1+3 and [13 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
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)[numeraltext' | | where numeral also could be any of the extentions proposed earlier. There is a serious ambiguity here. Consider something like: [1FooABC 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 [text 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): [textnumeral 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: |:: ... ::|
Hello, there is no reason to reject ::| and :::| notation as far as I see. Additive complementary constructs (intriguing to me) could be: :text| and :numeral| 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 :numeral| construct the numeral 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 :numeraltext| 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] 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 [13 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)[numeraltext' where numeral also could be any of the extentions proposed earlier. Example: abcdefg |1+3 a2bcdefg :|\ [2+4 b2cdefga ||\ [last ending c8 |] Or abcdefg |1+3last 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] 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
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
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
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
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
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, [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
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
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
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] 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
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] 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
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 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, 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
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
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
[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] 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
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: Tune finder, collections, header fields
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
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: 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] 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
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 bA 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
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
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
Re: [abcusers] Advisory accidentals
Hello, John Chambers wrote: Simon Wascher writes: | I usually use #A or bA 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: 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] 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: [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, 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, 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, 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
[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] 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, 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.1ABcd | pos.1efga :| 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
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
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|DmFF EF GF|AE3 z FG|FA2AG Ac|AA2zA AG| w:There lived a lad-y by the North Sea shore. (Lay the bent to the bon-nie broom) Two daught-ers DmF3(E/F/) GF|CE3 z DmD E/F/|CGF EC DmDE|DmD2|] w:were the_ babes she bore (Fa la la la la la la la la la) %Other verses: z A, DE|DmF3(E/F/) GF|AE3 z FG|FA2AG Ac|AA2zA AG| w:As one grew bright as in the sun, (Lay the bent to the bon-nie broom) so coal black DmF3(E/F/) GF|CE3 z DmD E/F/|CGF EC DmDE|DmD2|] 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, [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
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] 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](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 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-tne) 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] 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 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] 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
