Re: Diatonic notation system

[Hans Aberg]

On 9 Dec 2008, at 06:09, Graham Breed wrote:


Are you on board with the regular mapping paradigm?  I may as well
promote it while I'm here.

http://x31eq.com/paradigm.html


I looked a bit at it, the section "The Core Paradigm". The model I  
indicated
also chooses some generators, but in addition reflects the notion  
of scale
degrees that the Western musical notation system brings out, which  
in its

turn relies on an underlying empiric principle, also in the case when
augmented with intermediate pitches as in Persian and Arab music:


Scale degrees work fine in the paradigm.  They're one possible
generator.  I give the western scale in terms of those scale degrees.


It is necessary to have those scale degrees, and letters for pitch  
representatives of them for the system for the notation system I  
describe to work.



What's "empiric"?


As far as I know, that is how the music happens to be structured, but  
I do not an underlying principle for it.


Given intervals x (resp. y) in a two (resp. three) generator model  
x = p m +
q M (resp. y = p m + q M + r n), define a scale degree deg x = p +  
q (resp.
deg y = p + q + r). Empirically, melodic development normally  
takes place

between different scale degrees, also on say chromatically altered
ornaments. This is also true in the Persian dastgahs, using Farhat's
description. If one alters scale degrees, melodic development  
still normally
takes place between different scale degrees, as on a parallel,  
altered

scale. In the Western notation system, one achieves this by simply
minimizing the amount of temporary accidentals, if the notes are  
not too

chromatically dense, which is very intuitive.


That's partly because the harmony works that way.


Well, CPP harmony is a Western thing. There is some harmony based on  
4ths and 5ths.


Now, the construction on the link above seems to ignore those  
scale degrees.
If one defines a scale from say an octave P8 and a perfect fifth  
P5, then
scale degrees can be defined by setting deg P8 = 7, deg P5 = 4,  
and then
work it out for other combinations. This gives deg M = deg (2 P5 -  
P8) = 2
deg P5 - deg P8 = 1, deg m = deg (P4 - 2 M) = deg (P8 - P5 - 2M) =  
7 - 4 - 2

= 1.


How does it ignore them?  You saw the generators as part of the  
core paradigm.


I just mean it is not enough to define generators: they must also  
have scale degrees. Different choice of scale degrees for the same  
choice of generators imply a different musical treatment, and will  
get a different musical notation.


Then, in addition, to get an (extended) Western notation system,  
one must
define pitches A B C D E F G ... of scale degrees 0, 1, .., (n-1),  
where n

is the number of scale degrees in what is called an "octave".


Yes.



So then that is it. If one wants to have an intermediate pitch  
described a neutral n, then one needs one symbol to go from m to n  
which raises with the amount n - m, and a symbol to go from M to n  
which lowers with M - m. The sum of these intervals is M - m, the  
amount that sharps and flats alter.


For example, the Turkish AUE notation system
  http://en.wikipedia.org/wiki/Makam#Intervals
uses two neutrals of 5 and 8 commas. This will generate 2 pairs of  
symbols, the 4 that are used.


The Persian Farhat system, interpreted in E53, uses one neutral n of  
6 commas. One suggestion is that it is the rational interval 27/25.  
Since this interval is well approximated in E36, I made an  
interpetation in that, to work with E12 instruments.


  Hans




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Hans Aberg]

On 9 Dec 2008, at 02:29, Graham Breed wrote:

Also, I made keyboard map, which I have used in Scala playing in  
mainly

E31
for the last couple of months:
 A#  B#  Cx  Dx  Ex
 A   B   C#  D#  E#  Fx  Gx  Ax  Bx
  Bb  C   D   E   F#  G#  A#  B#
Cb  Db  Eb  F   G   A   B   C'# D'#
  Dbb Ebb Fb  Gb  Ab  Bb  C'  D'  E'
It will them work in any such generalized diatonic system.


You mean you have a keyboard mapped like this, or you use a virtual
keyboard in Scala?

Anyway, it'll only work in a system with a single spiral of fifths
(singly positive or negative in Wilson's terminology).  No good for
miracle or magic temperaments.


The link  you gave says:
 Miracle scales can be described as subsets of either 31, 41, or  
72 note

equal
 temperament. For example, the 21 note "blackjack" scale looks  
like this:

 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 /31
 1 3 1 3 1 3 1 3 1 3 1 3 1 3 1 3 1 3 1 3 1 /41
 2 5 2 5 2 5 2 5 2 5 2 5 2 5 2 5 2 5 2 5 2 /72
So the m M-model will work, and also the keyboard layout above, if  
adding
more note names. One must give those names in Scala, but the  
vectoring is

the same.


So the layout you gave won't work because it doesn't have enough note
names.  You need to add note names and move the existing ones around,
making it a different layout, and implying a different notation.


Right, but the underlying vectoring in terms of m and M is the same -  
the problems appear by defining it in terms of notation system, a  
limitation of Scala, and easier to understand for those just working  
with the traditional diatonic system.


There is a practical problem: it is nice to have the octaves  
level. And

having a lot m's makes the keyboard span short.


That's why I prefer square keys for miracle.


The layout is alto optimized for fingering. There is a mirror reverse  
version for E31 here

  http://www.huygens-fokker.org/instrumenten/fokkerorgel.html
but then I think it will be difficult when passing the thumb under  
the hand. Similarly, for chords, they should match the natural  
curving of the hand.


In addition, ideally, the key board should be rotated, so that the  
octaves are level.


I think the buttons of the Roland virtual accordions would be ideal.

  Hans




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

tex and texstr backend now removed

[Werner LEMBERG]

I've completed the removal of the tex and texstr backends.  Please
update the Spanish and French translations!


Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: tex and texstr backend now removed

[Francisco Vila]

2008/12/9 Werner LEMBERG <[EMAIL PROTECTED]>:
>
> I've completed the removal of the tex and texstr backends.  Please
> update the Spanish and French translations!

Done, thanks.

-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Hans Aberg]

On 9 Dec 2008, at 05:00, Graham Breed wrote:


To get it to sound right, you multiply by 6.  If accidentals and
transpositions don't work you may need to define a different grid  
from
them.  The worst is that you need one init file to define the  
notation

-- so that the accidentals are distinct where you want them to be --
and another init file to define the true pitches.


When I fiddled around with it, intermediate pitches were always  
computed

against those six M, so there will always 2 m to the M, or E12.


No, because Lilypond also preserves the number of scale steps.  At
least, it should.


I attach what I wrote for E36. There seems to be two systems, but  
they keep the ratio M/m = 2.


The difference to E53 is probably small, but it is still a fix,  
and not the

real thing.


Yes, when it comes to the MIDI output, if you think E53 is "the real
thing" for Turkish music.


E53 has narrow m's which makes it approximate 5th 3/2 well. That is  
what give it sound characteristics. Multiples of 12 don't do that.


I was then thinking about letting M, m being rational numbers,  
with 1 = the

octave, but that then only admits n-equal temperaments.


No.  It allows anything you like because you can make the rationals
arbitrarily precise.


One must be able to change the M/m ratio - without that, increasing  
approximation does not help.


Then I made the diatonic key map, and used it for active playing,  
led me to
think it right. And it is simpler to store integers than rational  
numbers in

a computer.


Don't worry.  Lilypond is quite capable of storing rational numbers.


It is much faster to compute fixed size integral types, regardless if  
you think it necessary.


The m M model I gave, I think makes the most of the Western  
notation system

- it is what it actually notates. And it focuseS on musical function,
writing notes, not pitches, the latter that can vary with  
interpretation.


Exactly the same way Lilypond's model does.


Only that is seems fixed to E12 or E24 when defining key signatures.


Even if the pitch specifications were accurate,
they'd have to be converted to pitch bends.


Even this may not work correctly, because a pitch bend may require  
change in
tone color (timbre). When playing say E31 in Scala, I noticed on  
some sound

patches changing erratic in timbre.


I was short changing MIDI a bit.  You could use single note retuning
messages from the MIDI Tuning Standard.  Scala can do this and some
synthesizers do support it.  Lilypond, however, uses pitch bends.


If the sound patch can handle it. It is possible in Timidity, though.


Then all kinds of
problems come in.  Most of the time it's simpler to talk of "half
steps" and program the synthesizer to do the tuning.


So therefore I think that MIDI is not a suitable format for a  
microtonal
output, leading to the idea of an intermediate formate that can  
preserve the

original diatonic structure.


If you don't think MIDI's suitable, quit bugging the Lilypond
developers about their MIDI output.  You could learn to parse the
Lilypond format.  Or develop your own format and process it to make
Lilypond one of the intermediates.  What makes you think some other
format (which you haven't begun to specify) would be magically easier
to work with?


I already discussed those options with Manuel Op de Coul - too  
complicated.


Csound is probably much better - though I could not get it working  
on Mac OS

X. :-)


Csound is lousy for representing staff notation because it does rhythm
differently.

What are your problems?  I did some work on this for Tiger and I still
have a spare machine running it that I can test on.  There's a call
for testers on the Csound list.  That's the proper place to discuss
this.


I don't remember, must try again some time.


Is there a way of using the
Lilypond parser and writing different output?  If you have  
patches to

make Lilypond do what you want that's something you could show the
developers.


Once one has written a MIDI file, then the information needed for  
retuning
is lost, as one needs to know the underlying diatonic structure,  
and the
difference between frequency and pitch bend. Also, there is the  
problem of

scale stretch on inharmonic instruments, like plucked strings.


That doesn't answer my question.

Scale stretch is not a problem here.  You can apply scale stretch to
the MIDI output.


If retuned, E12 enharmonic equivalences no longer apply. So one must  
first decide which sharps and flats to use, which only works if notes  
like F# and Gb both appear.



But I think LilyPond should make its own format that optimizes the
information that can the Western notation notation system  
produces. Also
SCala tend to treat scales as pitches. So therefore it might to  
convert to

Scala files from another format.


Yes, Lilypond has its own format already.  It does what you want.


So then just write it. Direct processing .ly files is too complictaed.

I think there are at l

Re: Translation string problem

[Francisco Vila]

2008/12/8 Jean-Charles Malahieude <[EMAIL PROTECTED]>:
> I think a warning would be useful, even for the English users, mentioning
> that this use of the autochange command *needs* the staves to be called "up"
> and "down".

I agree.

> Therefore I also removed the relevant lines in the pot and po files (on my
> working copy of git) in order to have them untranslated.
> #. Documentation/user/keyboards.itely:264 (context id)
> #. Documentation/user/keyboards.itely:273 (context id)
>
> but with no success.

As pot and po files are auto-generated, you'll have to do this
continuously. The only way I see is to warn this in some place and try
to remember it. We could also get rid of the @lilypond block and live
with only an @example which is freely translated on the sources, but
we'll lose the graphical example.

-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Hans Aberg]

On 9 Dec 2008, at 03:13, Graham Breed wrote:


So it might be better to write an intermediate sound file with the
diatonic
structure. Then it can be used to return the output without  
having to

recompile the typeset output.


What's an "intermediate sound file"?


The idea is, instead of writing MIDI directly, LilyPond writes an  
other file
with the diatonic information. Then this file is used to convert  
to MIDI or

some other sound format, like Scala file, without bothering about the
typeset output.


Lilypond code is already semantic markup for music.  Your intermediate
file would end up looking a lot like the original.


If that would be the case, it would be not point, right?

The format should be such that it can be sued by sound generating  
programs.


Yes, but the the one who wants to listen to the file may want a  
different

tuning than the one who wrote it.


So they use a different init file, or change a few numbers in the
standard init file.  Lilypond caters for this by having init files and
allowing scheme expressions in them.


If you add capabilities of handling anything else than multiples of 12.


Something is needed to indicate the notation system. I think it would
suffice to write it above or before the key signature. This way also
specific tunings can be called for, if needed.


When a musician's reading the notation, they're not looking above or
before the key signature.  They're looking at the notes.  So the notes
should look different to remind the musician that they should sound
different.  Otherwise it can get confusing as you switch between
systems.


That is not how it is done in current Western musical notation with  
respect to tuning, which has been in use from around 1600. But you  
can always invent something new.


And key signatures make the notes sound different.

But it is obviously a matter of notational taste.




If people want to invent their own symbols, perhaps LilyPond should
accommodate it. /but from the point of view of the m M model, it  
is just a

change of symbols.


Right, and currently arbitrary symbols don't work.


I noticed that.


In terms of this link
 http://en.wikipedia.org/wiki/Regular_temperament
the key map works with any two generator system, if one can  
compute the

equivalents of m an M.

It just displays the notes
   . ---> M
\/
 \  /  #, b
  v
   m
The letters then belong to the notation system, not the underlying  
diatonic

system.


No, the key map needs to change for different choices of your p and  
q. For full generality you need to allow p and q to be specified, at

least one tuning parameter, the nominals in terms of p and q, and the
size of # and b in terms of p and q.  That would work but it's
obviously not what Lilypond does now.  But Lilypond would work fine
for meantone, etc., if there were a better way of setting the tuning
of the nominals.  I'm afraid changing the number of nominals is not
going to be easy.  But ignoring the octaves will work fine as a kludge
for the few of us who actually want more than 7 nominals.


Then I am not sure what a two generator system is: is it not just the  
generated Abelian group?


The diagram above makes it is easy to compute transpositions, as  
they are

merely translations.


No transpositions in this system should break in Lilypond.  Do you
have examples where they do?


I am not sure what you refer to here. The system I indicate will  
always work
in with transpositions if one has two generators m and M. It does  
not work
in a system where one uses in effect more generators than m M, but  
still

uses the same notation system.


No, your system will not always work, as I've said, because diesis
shifts introduce more equivalences.  What example do you have where
Lilypond's transpositions don't work?


Then you will to give a reference what intervals are produced by a  
say a two generator system.


One example is Just intonation. The major seconds between C-D and  
D-E. But
here the tradition is to just forget about it, temper the  
difference out. -

I do not know about any specifically Just intonation music.


You what? Elsie Hamilton, Harry Partch, Lou Harrison, Terry
Riley, La Monte Young, Kraig Grady, Toby Twining, Greg Schiemer, all
passed you by?  You don't know about the hexachords Willaert
supposedly used to get just intonation performances?  And yet you're
happy to tell the Lilypond developers how they should implement their
microtonal support!


So how do they notate if a say piece in C major modulates to D major?

The accidentals are just symbols for passing between different  
combinations
of p m + q M. So if one wants to notate Just intonation exactly,  
one has to
introduce more accidentals, either as intermediate pitches using  
neutral
seconds. Or if one wants to give D = 9/8, E = 5/4 relative C,  
introduce
sharps and flats of different sizes. I haven't thought of the  
latter much.


Yes.  Hence Sagittal, HEWM, Extended Helmholtz-Ell

Re: Diatonic notation system

[Hans Aberg]

On 9 Dec 2008, at 11:57, Graham Breed wrote:
The format should be such that it can be sued by sound generating  
programs.


Do you have a patch?


Then I would not need to mention it here as an idea, would I.


When a musician's reading the notation, they're not looking above or
before the key signature.  They're looking at the notes.  So the  
notes

should look different to remind the musician that they should sound
different.  Otherwise it can get confusing as you switch between
systems.


That is not how it is done in current Western musical notation  
with respect
to tuning, which has been in use from around 1600. But you can  
always invent

something new.


No Western musical notation I know of includes a specification of  
the tuning.


Right, the notes look the same, though performed differently.


And key signatures make the notes sound different.


Yes, and it's a classic cause of errors in performance, despite the
key being reinforced by the music.


If you don't know how to read them.


But it is obviously a matter of notational taste.


No.  Some systems really are easier to learn and use than others.


Well, the Western notation system is not an easy to learn system.


Then I am not sure what a two generator system is: is it not just the
generated Abelian group?


It is.


OK. Thanks.


 Elsie Hamilton, Harry Partch, Lou Harrison, Terry
Riley, La Monte Young, Kraig Grady, Toby Twining, Greg Schiemer, all
passed you by?  You don't know about the hexachords Willaert
supposedly used to get just intonation performances?  And yet you're
happy to tell the Lilypond developers how they should implement  
their

microtonal support!


So how do they notate if a say piece in C major modulates to D major?


They always, or even generally, write in major keys.  Willaert, in
particular, was writing before major keys were defined.  But let's
assume they'd notate it as just intonation.


But the question is how to notate a change a key from C to D.



Yes.  Hence Sagittal, HEWM, Extended Helmholtz-Ellis, and Johnston's
notation.  They won't work with your system. They will work for
printing with the current Lilypond system and third-party fonts.   
They
would work for MIDI if Lilypond allowed the tuning of the  
nominals to

be specified ... and MIDI didn't suck quite so much.


What do you mean here. In Sagittal
 The Sagittal notation uses a conventional staff on which the  
natural notes

are in a
single series of fifths, with sharps and flats (and doubles thereof)
indicating tones that
are members of that same series, regardless of the particular  
tonal system

being
notated2.  Therefore, if the notation is used for just intonation,  
these

notes will indicate a Pythagorean tuning.

That is what my system does.


No, your system, at least as you describe it, only has two generators.
 Sagittal allows for systems with any number of generators.


No, the first two m M are used generate the staff system and sharps  
and flats.


Then one add a suitable number of neutrals n_1, ..., n_k to get the  
intermediate pitches.


For example, putting n = M3 - M gives an accidental suitable for Just  
relative Pythagorean.



If it now can produce other than multiple of 12.


Do you have evidence that it ever didn't work?


I attached file, you can try to tweak it into proper E53 if you like.


That file plainly isn't for a western notation system.


It is for Arab music.


Abstract m M surely does.


How can it possibly do so?  Tell me!  C to Db is M.  C to the diesis
above C# is M.  How does abstract m and M distinguish M from M?


C to C# is M - m, C to Db is m.

C to an E31 above C#, can be described as a double flat. double  
sharp, or by adding a neutral second, all having different musical  
function.



So, Lilypond being a notation program, you aren't worried about the
pitch fine-tuning?  It already does what you want.


I wasn't able to get E53.


You said you weren't worried about pitch fine-tuning.


I want to be able to produce the right output with narrow m's.


Ozan Yarman and Nail Yavuzoğlu mentions the problems they perceive.


And Ozan plainly does not say that somebody else's system would be  
better.


One a of the paper makes a comparison of three different system.

Otherwise, I know roughly how new translations can be done. And it  
is very
hard to translate E53 back to intervals letters, especially in the  
presence

of variable scale degrees.


What does this have to do with Lilypond?


It would then be easy to typeset.

But anyway, such a letter system can be used for notating without  
tying to a
tuning like E53. But translation back is difficult - try that on  
those that

Scala lists.


So the model doesn't describe the right tuning.  The goal is to notate
the correct tuning.


Which fails, because one can use different tunings.

Of course it does!  C-D is 9 steps, D-E is 8 steps, if C-E is to  
be a

pure major third.


E53, in Scala is the Pythagorean notation system. The one you  
i

Re: Diatonic notation system

[Hans Aberg]

On 9 Dec 2008, at 12:50, Graham Breed wrote:


How can it possibly do so?  Tell me!  C to Db is M.  C to the diesis
above C# is M.  How does abstract m and M distinguish M from M?


Sorry, that should be m and m.  C-Db is m and C-C# plus a diesis is m.
 So the goal is to distinguish m from m.


I answered, but here again:

C to Db is m, C to to C# is M - m, and C to C# plus a E31 tonestep  
can be described as double-flats, double sharps or by adding a  
neutral second. Those three different possibilities have different  
musical function, that ill show up if the intonation is changed.


  Hans




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[till Rettig]

Hi,

thanks for report, I didn't check on it. What if we use for this particular 
case @c KEEP LY and put the
up and down there. So other instantiations with the same name get translated 
correctly, where it doesn*t harm.

till
 Original-Nachricht 
Datum: Tue, 9 Dec 2008 11:08:05 +0100
Von: "Francisco Vila" <[EMAIL PROTECTED]>
An: "Jean-Charles Malahieude" <[EMAIL PROTECTED]>
CC: lilypond-devel 
Betreff: Re: Translation string problem

2008/12/8 Jean-Charles Malahieude <[EMAIL PROTECTED]>:
> I think a warning would be useful, even for the English users, mentioning
> that this use of the autochange command *needs* the staves to be called "up"
> and "down".

I agree.

> Therefore I also removed the relevant lines in the pot and po files (on my
> working copy of git) in order to have them untranslated.
> #. Documentation/user/keyboards.itely:264 (context id)
> #. Documentation/user/keyboards.itely:273 (context id)
>
> but with no success.

As pot and po files are auto-generated, you'll have to do this
continuously. The only way I see is to warn this in some place and try
to remember it. We could also get rid of the @lilypond block and live
with only an @example which is freely translated on the sources, but
we'll lose the graphical example.

-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Hans Aberg]

On 9 Dec 2008, at 13:26, Graham Breed wrote:


No, because Lilypond also preserves the number of scale steps.  At
least, it should.


I attach what I wrote for E36. There seems to be two systems, but  
they keep

the ratio M/m = 2.


Where are the transpositions?


I attach an example file.

I think it is the commented out part (long time ago), which for some  
reason only works with E24. Therefore, the keys must be written  
explicitly.


Let me know how to do E53.


Yes.  That would be chromatic transposition.  I can't see a way to
specify it in Lilypond.  So what does Lilypond actually do?


Do not know.


Then why are you asking for changes on the developer list?


I have not asked for changes, have I?

First compute the scale degree p + q, and compute the octave and  
note

name
by dividing by 7: octave is the fraction, remainder the note  
name. Then
subtract octave and note name from p m + q M; the result is of  
the form
 (-r)m + r M, where r if > 0 is the number of sharps, and if <  
0, the

number
of flats is -r.


Or it could do what it already does.


So what does it do. Does it generalize?


It records a nominal and a rational alteration.  It generalizes to
different alterations.


But that is tied to E12, right?

Yes, so change the init file.  Why are we going around in circles  
here?


Perhaps you are stuck to the same idea, and repeating.


I'm stuck with that idea because it works.


In certain primitive settings.


Then don't use E24 for Arabic music.


You already do.

  Hans



bayati36.ly
Description: Binary data



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Graham Breed]

2008/12/9 Hans Aberg <[EMAIL PROTECTED]>:
> On 9 Dec 2008, at 03:13, Graham Breed wrote:

>> Lilypond code is already semantic markup for music.  Your intermediate
>> file would end up looking a lot like the original.
>
> If that would be the case, it would be not point, right?

Right.

> The format should be such that it can be sued by sound generating programs.

Do you have a patch?

>> When a musician's reading the notation, they're not looking above or
>> before the key signature.  They're looking at the notes.  So the notes
>> should look different to remind the musician that they should sound
>> different.  Otherwise it can get confusing as you switch between
>> systems.
>
> That is not how it is done in current Western musical notation with respect
> to tuning, which has been in use from around 1600. But you can always invent
> something new.

No Western musical notation I know of includes a specification of the tuning.

> And key signatures make the notes sound different.

Yes, and it's a classic cause of errors in performance, despite the
key being reinforced by the music.

> But it is obviously a matter of notational taste.

No.  Some systems really are easier to learn and use than others.

> Then I am not sure what a two generator system is: is it not just the
> generated Abelian group?

It is.

>> No, your system will not always work, as I've said, because diesis
>> shifts introduce more equivalences.  What example do you have where
>> Lilypond's transpositions don't work?
>
> Then you will to give a reference what intervals are produced by a say a two
> generator system.

You know about M and m.  Why do you need a reference?

>>> One example is Just intonation. The major seconds between C-D and D-E.
>>> But
>>> here the tradition is to just forget about it, temper the difference out.
>>> -
>>> I do not know about any specifically Just intonation music.
>>
>> You what? Elsie Hamilton, Harry Partch, Lou Harrison, Terry
>> Riley, La Monte Young, Kraig Grady, Toby Twining, Greg Schiemer, all
>> passed you by?  You don't know about the hexachords Willaert
>> supposedly used to get just intonation performances?  And yet you're
>> happy to tell the Lilypond developers how they should implement their
>> microtonal support!
>
> So how do they notate if a say piece in C major modulates to D major?

They always, or even generally, write in major keys.  Willaert, in
particular, was writing before major keys were defined.  But let's
assume they'd notate it as just intonation.

>> Yes.  Hence Sagittal, HEWM, Extended Helmholtz-Ellis, and Johnston's
>> notation.  They won't work with your system. They will work for
>> printing with the current Lilypond system and third-party fonts.  They
>> would work for MIDI if Lilypond allowed the tuning of the nominals to
>> be specified ... and MIDI didn't suck quite so much.
>
> What do you mean here. In Sagittal
>  The Sagittal notation uses a conventional staff on which the natural notes
> are in a
> single series of fifths, with sharps and flats (and doubles thereof)
> indicating tones that
> are members of that same series, regardless of the particular tonal system
> being
> notated2.  Therefore, if the notation is used for just intonation, these
> notes will indicate a Pythagorean tuning.
>
> That is what my system does.

No, your system, at least as you describe it, only has two generators.
 Sagittal allows for systems with any number of generators.

>> Okay, I know how to transpose.  What I'm asking is why it doesn't work
>> for you in Lilypond.  The way Lilypond does it looks fine to me.
>
> If it now can produce other than multiple of 12.

Do you have evidence that it ever didn't work?

>>> Right, But I think that is the limitation of the Western notation system.
>>> And normally, I think one tempers it out, performing in a diatonic
>>> system.
>>
>> That's what Lilypond does.  You should be quite happy with Lilypond as it
>> is.
>
> It did not work when I tried it - see the file I attached. I was quite
> unhappy - I gave up.

That file plainly isn't for a western notation system.

 And there are plenty of cases where the same pitch can be
 written different ways for a rank 2 tuning.  Like a meantone notation
 with a new symbol for "diesis" shifts (1 step of 31, 50, 43, etc).
 You could write Db as the diesis above C# and you want it to stay like
 that.
>>>
>>> Those are E31 enharmonic equivalents. A true meantone might use M =
>>> sqrt(5/4).
>>
>> They're equivalents in either E19, E31, E43, E50, and so on.  The
>> tuning doesn't matter.
>
> If know LilyPond can handle it. But ET's are just tuning intermediates for
> the music, not describing the musical intent.

That's right.

>>> If you introduce enharmonic equivalents, or specific symbols for
>>> tonesteps,
>>> then it is tied to that tuning, and it cannot be retuned without lifting
>>> it
>>> to the diatonic structure.
>>
>> No.  In this case the equivalents (call them enharmon

Re: Diatonic notation system

[Graham Breed]

2008/12/9 Hans Aberg <[EMAIL PROTECTED]>:
> On 9 Dec 2008, at 11:57, Graham Breed wrote:
>>>
>>> The format should be such that it can be sued by sound generating
>>> programs.
>>
>> Do you have a patch?
>
> Then I would not need to mention it here as an idea, would I.

Fine, you've mentioned it.

>>> And key signatures make the notes sound different.
>>
>> Yes, and it's a classic cause of errors in performance, despite the
>> key being reinforced by the music.
>
> If you don't know how to read them.

Even if you know how to read them you are likely to make mistakes.

>> They always, or even generally, write in major keys.  Willaert, in
>> particular, was writing before major keys were defined.  But let's
>> assume they'd notate it as just intonation.
>
> But the question is how to notate a change a key from C to D.

Write different notes?

>> No, your system, at least as you describe it, only has two generators.
>>  Sagittal allows for systems with any number of generators.
>
> No, the first two m M are used generate the staff system and sharps and
> flats.
>
> Then one add a suitable number of neutrals n_1, ..., n_k to get the
> intermediate pitches.
>
> For example, putting n = M3 - M gives an accidental suitable for Just
> relative Pythagorean.

Sorry, I was wrong.  You do have more generators.

>>> If it now can produce other than multiple of 12.
>>
>> Do you have evidence that it ever didn't work?
>
> I attached file, you can try to tweak it into proper E53 if you like.

What does E53 have to with anything?  We were talking about correct
transposition.

>> How can it possibly do so?  Tell me!  C to Db is m.  C to the diesis
>> above C# is m.  How does abstract m and M distinguish m from m?
[corrected]
>
> C to C# is M - m, C to Db is m.
>
> C to an E31 above C#, can be described as a double flat. double sharp, or by
> adding a neutral second, all having different musical function.

No, not an E31.  An enharmonic diesis.  m is not a double flat.
2(m-M) would be a double flat.  m is not a double sharp.  2(M-m) would
be a double sharp.  Adding a neutral second to what?  m is not a
neutral second.  m is, in fact, m.  How does abstract m and M
distinguish it from m?

 So, Lilypond being a notation program, you aren't worried about the
 pitch fine-tuning?  It already does what you want.
>>>
>>> I wasn't able to get E53.
>>
>> You said you weren't worried about pitch fine-tuning.
>
> I want to be able to produce the right output with narrow m's.

Then are you or are you not worried about pitch fine-tuning?

>>> Otherwise, I know roughly how new translations can be done. And it is
>>> very
>>> hard to translate E53 back to intervals letters, especially in the
>>> presence
>>> of variable scale degrees.
>>
>> What does this have to do with Lilypond?
>
> It would then be easy to typeset.

Typeset what?  How does Lilypond make it difficult to typeset anything?

 Of course it does!  C-D is 9 steps, D-E is 8 steps, if C-E is to be a
 pure major third.
>>>
>>> E53, in Scala is the Pythagorean notation system. The one you indicate
>>> would
>>> have to be given a different name.
>>
>> It doesn't matter how you notate it.  The music will have two
>> semitones of different sizes.
>
> But i want to find out how you want to notate it: as E53 with intermediate
> pitches or a system where the note names have different interval values.

I'm not writing it.  If I did I'd probably use Pythagorean notation
with a comma accidental.  But I might use Erv Wilson's duodecimally
positive notation.


   Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Hans Aberg]

On 9 Dec 2008, at 13:42, Graham Breed wrote:

And key signatures make the notes sound different.


Yes, and it's a classic cause of errors in performance, despite the
key being reinforced by the music.


If you don't know how to read them.


Even if you know how to read them you are likely to make mistakes.


Not using key signatures will not solve that problem.


They always, or even generally, write in major keys.  Willaert, in
particular, was writing before major keys were defined.  But let's
assume they'd notate it as just intonation.


But the question is how to notate a change a key from C to D.


Write different notes?


Rather which accidentals do you use?

No, the first two m M are used generate the staff system and  
sharps and

flats.

Then one add a suitable number of neutrals n_1, ..., n_k to get the
intermediate pitches.

For example, putting n = M3 - M gives an accidental suitable for Just
relative Pythagorean.


Sorry, I was wrong.  You do have more generators.


Only that I give them variable names, and consider the linear algebra  
they generate.





If it now can produce other than multiple of 12.


Do you have evidence that it ever didn't work?


I attached file, you can try to tweak it into proper E53 if you like.


What does E53 have to with anything?  We were talking about correct
transposition.


If transposition calls for say a comma below an m, and that m is  
computed not against E53, but E12, I think there might be an error. I  
leave it to you figure out. By contrast, if it is in E53, then I know  
it is right, and I do not have to do that exercise.



C to C# is M - m, C to Db is m.

C to an E31 above C#, can be described as a double flat. double  
sharp, or by

adding a neutral second, all having different musical function.


No, not an E31.  An enharmonic diesis.


Since the name diesis has many uses, you will have to elaborate.


m is not a double flat.
2(m-M) would be a double flat.  m is not a double sharp.  2(M-m) would
be a double sharp.


In E31m these are 4 tonesteps, so the difference with M is one E31  
tonestep.



Adding a neutral second to what?  m is not a
neutral second.  m is, in fact, m.  How does abstract m and M
distinguish it from m?


If you want to have the tonestep between Db and D, that is a neutral  
second, generating a symbol for an intermediate pitch.


But i want to find out how you want to notate it: as E53 with  
intermediate
pitches or a system where the note names have different interval  
values.


I'm not writing it.  If I did I'd probably use Pythagorean notation
with a comma accidental.


So that would then work with the method I gave.

  Hans




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Francisco Vila]

2008/12/9 Francisco Vila <[EMAIL PROTECTED]>:
> 2008/12/9 till Rettig <[EMAIL PROTECTED]>:
>> Hi,
>>
>> thanks for report, I didn't check on it. What if we use for this particular 
>> case @c KEEP LY and put the
>> up and down there. So other instantiations with the same name get translated 
>> correctly, where it doesn*t harm.
>
> Yes, let's use @c KEEP LY, a good solution.

I've done this adding a comment:

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=6d7edb962644c9b657f88d8bfe5b480494996f94


-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Francisco Vila]

2008/12/9 till Rettig <[EMAIL PROTECTED]>:
> Hi,
>
> thanks for report, I didn't check on it. What if we use for this particular 
> case @c KEEP LY and put the
> up and down there. So other instantiations with the same name get translated 
> correctly, where it doesn*t harm.

Yes, let's use @c KEEP LY, a good solution.

-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Trevor Daniels]

Francisco Vila wrote Tuesday, December 09, 2008 10:08 AM



2008/12/8 Jean-Charles Malahieude <[EMAIL PROTECTED]>:

I think a warning would be useful, even for the English users, mentioning
that this use of the autochange command *needs* the staves to be called 
"up"

and "down".


I agree.

Therefore I also removed the relevant lines in the pot and po files (on 
my

working copy of git) in order to have them untranslated.
#. Documentation/user/keyboards.itely:264 (context id)
#. Documentation/user/keyboards.itely:273 (context id)

but with no success.


As pot and po files are auto-generated, you'll have to do this
continuously. The only way I see is to warn this in some place and try
to remember it. We could also get rid of the @lilypond block and live
with only an @example which is freely translated on the sources, but
we'll lose the graphical example.


I've already added an @warning about this, but this is really intended
for users, not translators.  Do you think this is enough?

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Graham Breed]

2008/12/9 Hans Aberg <[EMAIL PROTECTED]>:
> On 9 Dec 2008, at 05:00, Graham Breed wrote:

>> No, because Lilypond also preserves the number of scale steps.  At
>> least, it should.
>
> I attach what I wrote for E36. There seems to be two systems, but they keep
> the ratio M/m = 2.

Where are the transpositions?

> It is much faster to compute fixed size integral types, regardless if you
> think it necessary.

Premature optimization is the root of all evil.

>>> The m M model I gave, I think makes the most of the Western notation
>>> system
>>> - it is what it actually notates. And it focuseS on musical function,
>>> writing notes, not pitches, the latter that can vary with interpretation.
>>
>> Exactly the same way Lilypond's model does.
>
> Only that is seems fixed to E12 or E24 when defining key signatures.

Now all of a sudden key signatures are the problem?

>> If you don't think MIDI's suitable, quit bugging the Lilypond
>> developers about their MIDI output.  You could learn to parse the
>> Lilypond format.  Or develop your own format and process it to make
>> Lilypond one of the intermediates.  What makes you think some other
>> format (which you haven't begun to specify) would be magically easier
>> to work with?
>
> I already discussed those options with Manuel Op de Coul - too complicated.

Yes, it's complicated.  And the solution is, to save you parsing
Lilypond files, Lilypond has to do exactly what you want, even if you
can't specify it.

 Is there a way of using the
 Lilypond parser and writing different output?  If you have 
> If retuned, E12 enharmonic equivalences no longer apply. So one must first
> decide which sharps and flats to use, which only works if notes like F# and
> Gb both appear.

That still doesn't answer my question.

>>> Finally, one can notate in E12, just minimizing the number of accidentals
>>> needed, so it is different going up and down.
>>
>> Yes.  That would be chromatic transposition.  I can't see a way to
>> specify it in Lilypond.  So what does Lilypond actually do?
>
> Do not know.

Then why are you asking for changes on the developer list?

>>> First compute the scale degree p + q, and compute the octave and note
>>> name
>>> by dividing by 7: octave is the fraction, remainder the note name. Then
>>> subtract octave and note name from p m + q M; the result is of the form
>>>  (-r)m + r M, where r if > 0 is the number of sharps, and if < 0, the
>>> number
>>> of flats is -r.
>>
>> Or it could do what it already does.
>
> So what does it do. Does it generalize?

It records a nominal and a rational alteration.  It generalizes to
different alterations.

> Music may do enharmonic equivalence as a notational simplification, too, in
> which case m and M need not be known. There will be a small jump in the
> music, but performers will cope with that. Even dedicated E12 music may
> actually be performed in something else - somebody measured up that some
> Shoenberg piece was actually performed in Pythagorean tuning.

You brought up enharmonic equivalences.  You said it's an example of M
and m needing to be known.  And you were right.  C# and Db are only
equivalent when M=2m.

 That's why you have init files.  Supply a different init file, or
 alter the tuning specifications.
>>>
>>> The notation does normally tell what the tuning should be, so one would
>>> want
>>> to retune it, even if the typeset output is the same. Think of an archive
>>> with Medieval tunes - as it is now, they MIDI files will be in E12. But
>>> in
>>> those times one used E53. And if set in E53, they may not work with
>>> instruments in E12.
>>
>> Yes, so change the init file.  Why are we going around in circles here?
>
> Perhaps you are stuck to the same idea, and repeating.

I'm stuck with that idea because it works.

>>> The problem is what the official version are. If the official version
>>> sets a
>>> specific tuning, then it is not possible to change that.
>>
>> Yes, it is possible to change it, by changing the init file.
>
> If you have the original .ly file.

How is it Lilypond's business if you don't?

>>> Sorry, typo: if the sound output is in E12, then it cannot be retuned
>>> without the underlying diatonic structure.
>>
>> So don't retune the sound output.  Retune the Lilypond input.
>
> The all tuning capabilities lies on LilyPond.

If you're going to use Lilypond, Lilypond is pretty important.

> That is not how it is in Arab music. It uses symbols from E24, but there is
> no general agreement what tuning to use. The LilyPond model is flawed,
> though possible to tweak.

Then don't use E24 for Arabic music.


 Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Graham Breed]

I wrote:
> How can it possibly do so?  Tell me!  C to Db is M.  C to the diesis
> above C# is M.  How does abstract m and M distinguish M from M?

Sorry, that should be m and m.  C-Db is m and C-C# plus a diesis is m.
 So the goal is to distinguish m from m.


 Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: problems with ly:font-load

[Werner LEMBERG]

> > However, it shouldn't be to hard to add functions
> > `ly:font-config-register-directory' and
> > `ly:font-config-register-file' (using FcConfigAppFontAddFile) to
> > lilypond.
> 
> That would be awesome; [...]

I've just added ly:font-config-add-directory and
ly:font-config-add-font.  Please test.


Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: problems with ly:font-load

[Valentin Villenave]

2008/12/9 Werner LEMBERG <[EMAIL PROTECTED]>:

> I've just added ly:font-config-add-directory and
> ly:font-config-add-font.  Please test.

Yeepee! I'm compiling right away.

Cheers,
Valentin


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Jean-Charles Malahieude]

Le 09.12.2008 13:49, Francisco Vila disait :

2008/12/9 till Rettig:

Hi,

thanks for report, I didn't check on it. What if we use for this particular 
case @c KEEP LY and put the
up and down there. So other instantiations with the same name get translated 
correctly, where it doesn*t harm.


Yes, let's use @c KEEP LY, a good solution.



I should have thought about it...




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: problems with ly:font-load

[Werner LEMBERG]

> > I've just added ly:font-config-add-directory and
> > ly:font-config-add-font.  Please test.
> 
> Yeepee! I'm compiling right away.

Just a warning: I got crashes with fontconfig 2.4.1; if you experience
the same you should try version 2.6.0.


Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Jean-Charles Malahieude]

Le 09.12.2008 13:05, Trevor Daniels disait :



Francisco Vila wrote Tuesday, December 09, 2008 10:08 AM



2008/12/8 Jean-Charles Malahieude:
I think a warning would be useful, even for the English users, 
mentioning
that this use of the autochange command *needs* the staves to be 
called "up"

and "down".


I agree.

 [...]
As pot and po files are auto-generated, you'll have to do this
continuously. The only way I see is to warn this in some place and try
to remember it. We could also get rid of the @lilypond block and live
with only an @example which is freely translated on the sources, but
we'll lose the graphical example.


I've already added an @warning about this, but this is really intended
for users, not translators.  Do you think this is enough?

Trevor



I would have done it, since those context names seem to be really 
mandatory for the command to work.


Cheers,
Jean-Charles

ps: sorry, I did not notice it would have been better with a cropped png 
enclosure.




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Full measure rests

[Carl D. Sorensen]

This following discussion comes from the -user list.  Reinhold appears to
have identified a case where current LilyPond behavior doesn't match Read's
conventions.

This leads to two questions:

1) Should LilyPond be adjusted to match Read's conventions (Reinhold has
identified how it should be changed, at least to eliminate the breve
symbol)?

2) Should there be an option added to allow the user to switch between
current LilyPond behavior and the behavior recommended by Read?

I bring this up because I didn't want it to get lost on the -user list.

Thanks,

Carl

From: Reinhold Kainhofer  kainhofer.com>
Subject: Re: Again: Whole Bar Rests and Unmetered Music
Newsgroups: gmane.comp.gnu.lilypond.bugs, gmane.comp.gnu.lilypond.general
Date: 2008-12-06 13:36:01 GMT (3 days, 4 hours and 49 minutes ago)

Am Samstag, 6. Dezember 2008 14:02:04 schrieb Dmytro O. Redchuk:
>   Please, can anybody answer me:
>   1. Shouldn't whole bar rest be semibreve (whole) rest for any actual
> time except 4/2?

Gardner Read says about whole-measure rests (p.98):
"Although the whole rest literally signifies only the value of a hole note,
it 
now commonly serves as the symbol for any completely silent measure,
regardless of the meter or time-signature. Formerly, it served for all
measure 
values except 4/2, this rest being indicated by a sign borrowed from the
breve 
symbol of thirteenth- and fourteenth-century music. But today the whole rest
stands for any empty measure -- for all meters from a theoretical 8/2 to a
3/16. For a 2/16 (1/8) or smaller silent bar, an actual eighth (or smaller)
rest would be used."

>   2. How can i tell lilypond to "draw" whole rest instead of breve
> (double)?

You can't, since it's hardcoded to use a breve rest for ALL measure lengths
>=2 (i.e. >= 4/2)...
>From multi-measure-rest-engraver.cc (lines 218-221):

  SCM sml = get_property ("measureLength");
  Rational ml = (unsmob_moment (sml)) ? unsmob_moment (sml)->main_part_
:
   Rational (1);
  if (ml >= Rational (2))
last_rest_->set_property ("use-breve-rest", SCM_BOOL_T);

So, apparently, this "violates" the convention Read describes in two ways:
-) breve should only be used for ml == Rational(2) (if at all!)
-) For ml < Rational (3, 16) a rest of appropriate duration should be used
instead of the semibreve

Cheers,
Reinhold



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Snippet formatting in the Glossary

[Neil Puttock]

Hi everybody,

I've tweaked the examples for `Clef' in the Glossary, and they seem to
be the only examples which use [quote].  Shouldn't this apply to all
the snippets?

Cheers,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Re: order of alterations in Staff.keySignature for general keysignatures

[Neil Puttock]

2008/11/30 Reinhold Kainhofer <[EMAIL PROTECTED]>:

> So, here's the patch:
> http://codereview.appspot.com/8686
>
> Any idea if this is the correct way to solve the problem that you have to
> enter non-standard key signatures in reverse order?

I'm not sure, but it seems to be a harmless change.

It certainly makes using 'padding-pairs more intuitive, since the
ordering will now match:

[from key-signature-padding.ly]

{
  \override Staff.KeySignature #'padding-pairs
= #'((("accidentals.flat" .
"accidentals.sharp.slashslash.stemstemstem") . 0.5))
\set Staff.keySignature = #`((2 . ,SEMI-FLAT)  (6 .
,THREE-Q-SHARP) (4 . ,FLAT))
  e2
}

{
  \override Staff.KeySignature #'padding-pairs
= #'((("accidentals.flat" .
"accidentals.sharp.slashslash.stemstemstem") . 0.5))
\set Staff.keySignature = #`((4 . ,FLAT) (6 . ,THREE-Q-SHARP) (2 .
,SEMI-FLAT))
  e2
}

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Francisco Vila]

2008/12/9 Francisco Vila <[EMAIL PROTECTED]>:
>> Yes, let's use @c KEEP LY, a good solution.
>
> I've done this adding a comment:
>
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=6d7edb962644c9b657f88d8bfe5b480494996f94

I am doing something badly, as the verbatim output insists on being
translated despite of the KEEP LY. What are your results?

-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Jean-Charles Malahieude]

Le 09.12.2008 21:55, Francisco Vila disait :

2008/12/9 Francisco Vila:

Yes, let's use @c KEEP LY, a good solution.

I've done this adding a comment:

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=6d7edb962644c9b657f88d8bfe5b480494996f94


I am doing something badly, as the verbatim output insists on being
translated despite of the KEEP LY. What are your results?



I've found an "intermediate" way, which consists in doubling the snippet:

1) it becomes an @example
2) the @lilypond loses its verbatim option

The only nuisance is that we then obtain two frames: one for the 
"example" and one for the "image". We might add a simple sentence 
between them in order to "make the linkage".


Cheers,
Jean-Charles



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: major feature request (tablature)

[demery]

> But LilyPond already has an extensive code and data structures base.  To use
> data structures or code that are not compatible with the LilyPond paradigm
> is not wise.

What is wise is to bow to the users expectations, not twist their mind.

User of tablature is thinking of where to put the fingers, which is
a stream of

{ [flag], {fretlist} }

for italian and french notations, with the fretlist ordered by course
and a stream of

{ [flag], {fretCoursePolyphony-row1, -row2, -row3, ... }

for german, with course implied by the fretglyph encoding.

> I see nothing in this tablature that can't be done in LilyPond.  I also see
> that this tablature is much more beautiful than the current LilyPond
> tablature, and can see why you want to improve the LilyPond output.  Thanks
> for sharing the vision.

YW, please notice that besides the form differences, there have been a
number of fonts used historically, I have made replicas using
Fontographer, and will be tweaking them to serve Ly use.

> Adding the extra offset from the glyphs automatically should be a relatively
> easy thing to do in LilyPond, and might make an excellent way for you to get
> started on creating the features you want.  Looking at this output, I
> suspect that the glyphs have been offset to put them in the spaces of the
> tab

yes, I see where that could leave the stems mispositioned as they are. 
The fellow doing that illo has gone on to correct the 1 and 3 lines flags.

Once I get the docs unrolled from their tar balls... (chicken n egg
problem, libraries dont have untar utillities n frown on installs on their
virus-free machines...).

> (which is what the most common popular music

say it, Mel Bay editions :-).  I have a couple for banjo.

>>> it would seem to me to be more robust to enter fret, course, and
>>> duration.  

right, I was distracted by thoughts of german tab (ugly stuff that).

> You might consider that if you run into difficulty, if you're using the
> standard parser

yes, i see that, and it could work well for 6-course lute tab and cittern
tab (4-6 course instrument); but there will be aspects of the notation
which simply wont have equivalent data, so maybe in stages.

> If you leave the parser alone and write Scheme code

a clue to where 'scheme' code is described would be welcome, unique to Ly?
elsewhere?; in the doc package I have?, somewhere online?

> I'll look forward to seeing how you choose to move forward on this.   I
> think it will increase LilyPond's appeal as the premier music engraving
> software.

priced right I think is the major claim to fame you can honestly make, its
got a ways to go before the other is clear to all.
-- 
Dana Emery




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Francisco Vila]

2008/12/9 Jean-Charles Malahieude <[EMAIL PROTECTED]>:
> Le 09.12.2008 21:55, Francisco Vila disait :
>>
>> 2008/12/9 Francisco Vila:

 Yes, let's use @c KEEP LY, a good solution.
>>>
>>> I've done this adding a comment:
>>>
>>>
>>> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=6d7edb962644c9b657f88d8bfe5b480494996f94
>>
>> I am doing something badly, as the verbatim output insists on being
>> translated despite of the KEEP LY. What are your results?
>>
>
> I've found an "intermediate" way, which consists in doubling the snippet:
>
> 1) it becomes an @example
> 2) the @lilypond loses its verbatim option
>
> The only nuisance is that we then obtain two frames: one for the "example"
> and one for the "image". We might add a simple sentence between them in
> order to "make the linkage".

That is easy, but I still don't understand why a KEEPt snippet suffers
an undesired translation. The image link points to the real (kept)
code, which is what should appear shown as verbatim.

Maybe when John finds the time he could fix it.

Trevor, I think the idea from Jean-Charles would serve now and forever
in any case. Could you compose it, including the glue paragraph?

-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PATCH: Arrowed accidentals for microtone notation

[Maximilian Albert]

2008/12/9 Werner LEMBERG <[EMAIL PROTECTED]>:
>
>> [...] I managed to find a workaround and hope that the attached
>> patches finally fix all the issues.
>
> Still a buglet: The stemwidth of the down arrow in the
> `natural.arrowboth' glyph is too thick if compared to the other
> arrowed natural signs.  Everything else looks fine.

Finally one with an instantaneous fix. :-) Indeed I used to check for
up- XOR down-arrow before I added the accidentals with arrows in both
direction. The attached version of the patches corrects this.

BTW, your hint about quick font creation and especially using
Ctrl+brackets to switch between consecutive glyphs in fontforge was
priceless. Thanks for that and for continuing support and detailed
investigations!

Max


patch_arrowed_accidentals.tar.gz
Description: GNU Zip compressed data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[John Mandereau]

Le mardi 09 décembre 2008 à 22:50 +0100, Jean-Charles Malahieude a
écrit :
> Le 09.12.2008 21:55, Francisco Vila disait :
> > I am doing something badly, as the verbatim output insists on being
> > translated despite of the KEEP LY.

This was to be expected, as lilypond-book translates whatever variable
and context names it finds in the messages catalog.


> I've found an "intermediate" way, which consists in doubling the snippet:
> 
> 1) it becomes an @example
> 2) the @lilypond loses its verbatim option

Yes, but don't forget the "@c KEEP LY".

> The only nuisance is that we then obtain two frames: one for the 
> "example" and one for the "image". We might add a simple sentence 
> between them in order to "make the linkage".

Well done, unless ly input is really parsed there is no other solution.

Cheers,
John



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[John Mandereau]

Le mercredi 10 décembre 2008 à 00:38 +0100, Francisco Vila a écrit :
> That is easy, but I still don't understand why a KEEPt snippet suffers
> an undesired translation.

"KEEP LY" was initially designed to be recognized by snippet-update.py
and no other program, but it is quite easy to make lilypond-book
recognize it if needed.


>  The image link points to the real (kept)
> code, which is what should appear shown as verbatim.

The real code is never translated anyway.

Cheers,
John



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: major feature request (tablature)

[Carl D. Sorensen]

On 12/9/08 4:37 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:

>> But LilyPond already has an extensive code and data structures base.  To use
>> data structures or code that are not compatible with the LilyPond paradigm
>> is not wise.
> 
> What is wise is to bow to the users expectations, not twist their mind.

You're confusing users with developers.  Code and data structures are
developer-only items.

Input is the user item.

Input can be defined to be practically anything.

Code and data structures should be compatible with existing LilyPond code
and data structures.

> 
> User of tablature is thinking of where to put the fingers, which is
> a stream of
> 
> { [flag], {fretlist} }
> 
> for italian and french notations, with the fretlist ordered by course
> and a stream of
> 
> { [flag], {fretCoursePolyphony-row1, -row2, -row3, ... }
> 
> for german, with course implied by the fretglyph encoding.

Why isn't "where to put the fingers" a string, fret pair?  That's what it
seems to me.  Then a duration would be added as well.

> 
> Once I get the docs unrolled from their tar balls... (chicken n egg
> problem, libraries dont have untar utillities n frown on installs on their
> virus-free machines...).

You don't need to pull a tar ball!  Each of the docs is available as a PDF
or a single page HTML.  You can download them directly to your USB drive.

> 
>> (which is what the most common popular music
> 
> say it, Mel Bay editions :-).  I have a couple for banjo.
> 

Actually, the largest collection of tabs I find nowadays for popular music
are created in ASCII format on the internet.

>> You might consider that if you run into difficulty, if you're using the
>> standard parser
> 
> yes, i see that, and it could work well for 6-course lute tab and cittern
> tab (4-6 course instrument); but there will be aspects of the notation
> which simply wont have equivalent data, so maybe in stages.

Won't every note you want to put on a tab have a pitch, a duration, a string
(or course), and a fret number?

Right now, LilyPond has the built-in functionality to, given a pitch, a set
of string tunings, and a desired string, automatically calculate a fret.

LilyPond has the built in functionality to have the input file contain a
pitch, a duration, and a string indication.

This means that with current LilyPond input and computation functionality,
you can obtain a string, fret, and duration to be used to place on a
tablature staff.  No programming is needed at all to obtain the critical
data necessary for your output algorithm.  This simplifies your work; you
simply need to focus on how your algorithm will take the fundamental data
(string, fret, duration, and optional finger) and place it on the tablature
staff.

It doesn't matter if the Klingon astroZither has 37 strings of various
pitches, with 15 of them being used only open.  LilyPond can create an entry
for each note played on any of the strings.  No special input needed
(although it may be desirable, and perhaps should be done later for
convenience).  You can be in complete control of the output without adding
any new input features.

> 
>> If you leave the parser alone and write Scheme code
> 
> a clue to where 'scheme' code is described would be welcome, unique to Ly?
> elsewhere?; in the doc package I have?, somewhere online?
> 

The first thing you will do is add the Scheme code to the LilyPond input
file.  Eventually, once it's debugged, it can be added to the LilyPond
distribution.

Since you put 'scheme' in single quotes, I suspect you don't know about
Scheme programming.  Scheme is a Lisp-like programming language.  A
particular dialect of Scheme, Guile, serves as the LilyPond application
extension language.  If you don't know how to program in Scheme, you'll need
to get up to speed on this in order to work with LilyPond.  The book I
learned Scheme from (back in 1985) was Structure and Interpretation of
Computer Programs, which is available on line at
.  You can also check
out the Guile Reference Manual at
.
 

>> I'll look forward to seeing how you choose to move forward on this.   I
>> think it will increase LilyPond's appeal as the premier music engraving
>> software.
> 
> priced right I think is the major claim to fame you can honestly make, its
> got a ways to go before the other is clear to all.

I guess I don't need to make it clear to all.

The input format is text based (which I consider to be a great plus).
The untweaked output is superior to any other notation program I've used.
The source is open, so I can add any feature I want.

For me, it's the best available.  YMMV.

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Carl D. Sorensen]

On 12/9/08 4:38 PM, "Francisco Vila" <[EMAIL PROTECTED]> wrote:

> 2008/12/9 Jean-Charles Malahieude <[EMAIL PROTECTED]>:
>> Le 09.12.2008 21:55, Francisco Vila disait :
>>> 
>>> 2008/12/9 Francisco Vila:
> 
> Yes, let's use @c KEEP LY, a good solution.
 
 I've done this adding a comment:
 
 
 http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=6d7edb962
 644c9b657f88d8bfe5b480494996f94
>>> 
>>> I am doing something badly, as the verbatim output insists on being
>>> translated despite of the KEEP LY. What are your results?
>>> 
>> 
>> I've found an "intermediate" way, which consists in doubling the snippet:
>> 
>> 1) it becomes an @example
>> 2) the @lilypond loses its verbatim option
>> 
>> The only nuisance is that we then obtain two frames: one for the "example"
>> and one for the "image". We might add a simple sentence between them in
>> order to "make the linkage".
> 
> That is easy, but I still don't understand why a KEEPt snippet suffers
> an undesired translation. The image link points to the real (kept)
> code, which is what should appear shown as verbatim.
> 
> Maybe when John finds the time he could fix it.
> 
> Trevor, I think the idea from Jean-Charles would serve now and forever
> in any case. Could you compose it, including the glue paragraph?

Oh, I hope we can find another way.  I hate the thought of keeping
@example around, and having to make sure that the code is the same in both
the @example piece and the @lilypond piece.

Thanks,


Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Graham Percival]

On Tue, Dec 09, 2008 at 10:50:38PM +0100, Jean-Charles Malahieude wrote:
> I've found an "intermediate" way, which consists in doubling the snippet:
>
> 1) it becomes an @example
> 2) the @lilypond loses its verbatim option

Sweet Mao no.  That's horrible.  We should *NOT* do this.

Can't somebody hack the python translation stuff to avoid this?
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[John Mandereau]

Le mardi 09 décembre 2008 à 16:38 -0800, Graham Percival a écrit :
> Sweet Mao no.  That's horrible.  We should *NOT* do this.
> 
> Can't somebody hack the python translation stuff to avoid this?

Already sold, but not before next night :-P

John



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Francisco Vila]

2008/12/10 Graham Percival <[EMAIL PROTECTED]>:
> On Tue, Dec 09, 2008 at 10:50:38PM +0100, Jean-Charles Malahieude wrote:
>> I've found an "intermediate" way, which consists in doubling the snippet:
>>
>> 1) it becomes an @example
>> 2) the @lilypond loses its verbatim option
>
> Sweet Mao no.  That's horrible.  We should *NOT* do this.

This hack would be advertised in a @c omment and not used anywhere
else, only here.

There are already examples of dirty things that are warned in comments
and that translators and editors must observe carefully. @c keep this
that way, @c don't do that, etc.
-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Graham Percival]

On Wed, Dec 10, 2008 at 01:47:29AM +0100, Francisco Vila wrote:
> 2008/12/10 Graham Percival <[EMAIL PROTECTED]>:
> > Sweet Mao no.  That's horrible.  We should *NOT* do this.
> 
> This hack would be advertised in a @c omment and not used anywhere
> else, only here.

In one (1) single example?
... *sigh* ok, I guess.

> There are already examples of dirty things that are warned in comments
> and that translators and editors must observe carefully. @c keep this
> that way, @c don't do that, etc.

Those should be kept to an absolute minimum, though.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Francisco Vila]

2008/12/10 Graham Percival <[EMAIL PROTECTED]>:
> On Wed, Dec 10, 2008 at 01:47:29AM +0100, Francisco Vila wrote:
>> 2008/12/10 Graham Percival <[EMAIL PROTECTED]>:
>> > Sweet Mao no.  That's horrible.  We should *NOT* do this.
>>
>> This hack would be advertised in a @c omment and not used anywhere
>> else, only here.
>
> In one (1) single example?

Yes, because the problem is that explicitly created staves have to be
given English names 'up' and 'down' if they are to be used for the
autochange feature. This is illustrated with a single example in NR
2.2.1 after the warning Trevor wrote yesterday.
-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Malformed g++ flags

[Han-Wen Nienhuys]

On Sun, Dec 7, 2008 at 8:29 PM, John Mandereau <[EMAIL PROTECTED]> wrote:
> Hello,
>
> With current Git master C++ flags are incorrect on my system:
>
> cp -p /home/lilydev/git/lily/master/config.hh out/config.hh
> rm -f ./out/all-font-metrics.dep;
> DEPENDENCIES_OUTPUT="./out/all-font-metrics.dep ./out/all-font-metrics.o" g++ 
> -c -Woverloaded-virtual  -I/usr/include/python2.5 -I/usr/include/python2.5 
> -fno-strict-aliasing -g -pipe,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector --param=ssp-buffer-size=4 -fPIC  -DHAVE_CONFIG_H  -DNDEBUG 
> -I./include -I./out -I../flower/include -I../flower/./out -I../flower/include 
>  -O2 -finline-functions -g -pipe -pthread -I/usr/include/freetype2   
> -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 
> -I/usr/lib64/glib-2.0/include   -Wno-pmf-conversions  -W -Wall -Wconversion 
> -o out/all-font-metrics.o all-font-metrics.cc
> g++: unrecognized option '-pipe,-D_FORTIFY_SOURCE=2'
>
>
> The following patch fixes it for me; is it OK to apply?

LGTM

-- 
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Translation string problem

[Carl D. Sorensen]

On 12/9/08 6:12 PM, "Francisco Vila" <[EMAIL PROTECTED]> wrote:

> 2008/12/10 Graham Percival <[EMAIL PROTECTED]>:
>> On Wed, Dec 10, 2008 at 01:47:29AM +0100, Francisco Vila wrote:
>>> 2008/12/10 Graham Percival <[EMAIL PROTECTED]>:
 Sweet Mao no.  That's horrible.  We should *NOT* do this.
>>> 
>>> This hack would be advertised in a @c omment and not used anywhere
>>> else, only here.
>> 
>> In one (1) single example?
> 
> Yes, because the problem is that explicitly created staves have to be
> given English names 'up' and 'down' if they are to be used for the
> autochange feature. This is illustrated with a single example in NR
> 2.2.1 after the warning Trevor wrote yesterday.

Seems to me that to avoid this problem we should never have LilyPond names
that are standard English words.

I think we should change the defined names "up" and "down" to "upperStaff"
and "lowerStaff" or something like that.  Those names would be less
confusing than "up" and "down", and wouldn't be subject to translation,
because they're not English words.

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)

[Han-Wen Nienhuys]

On Sun, Dec 7, 2008 at 5:34 PM, Maximilian Albert
<[EMAIL PROTECTED]> wrote:
> Hi Neil,
>
> thanks a lot for your further very helpful ideas. Attached is a patch
> for a new approach which implements your suggestion to define a new
> property. It's called 'shifted-towards-stem and can take any real
> value, where 0.0 means to keep the default position (centered on the
> note-head) and 1.0 means centered on the stem (intermediate values are
> of course possible). I also added a check whether the grob in question
> actually possesses a stem, so it works well for skips, too (perhaps
> there is a more Lilypond-ish way of doing things but as far as I could
> test, it works).

Some random comments:

- have a look at scm/script.scm to set defaults just for staccato.
- "shifted" suggests a boolean property.  toward-stem-shift ?
- do not use 'pos' - it's the name for vertical offsets in half staffspace.
- use explicit type checks (ie. number? rather than (not null?))
-(if (equal? dir1 dir2) can move to before the stem-pos init
- add a regtest. Should be short, with a short doc string explaining
the functionality.




-- 
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PATCH: Arrowed accidentals for microtone notation

[Werner LEMBERG]

> > Still a buglet: The stemwidth of the down arrow in the
> > `natural.arrowboth' glyph is too thick if compared to the other
> > arrowed natural signs.  Everything else looks fine.
> 
> Finally one with an instantaneous fix. :-) Indeed I used to check
> for up- XOR down-arrow before I added the accidentals with arrows in
> both direction. The attached version of the patches corrects this.

Hehe, it's still not perfect.  Sorry for being a PITA :-)  Compile
with

  FONTFORGE=foo mf2pt1 --rounding=0.0001 feta20

and magnify into the connection point between the down-arrow and the
vertical bar: The `natural.arrowdown' glyph correctly extends the
vertical bar outlines into exactly the same direction, while the
`natural.arrowboth' extends the stem into a slightly different
direction, which is not correct.

Additionally, the upper left point of the lower horizontal bar `jumps'
if compared between natural glyphs with and without an up-arrow.  The
same is true for the lower right point of the upper horizontal bar for
glyphs with and without a down-arrow.


Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: major feature request (tablature)

[demery]

On Tue, Dec 9, 2008, "Carl D. Sorensen" <[EMAIL PROTECTED]> said:
> On 12/9/08 4:37 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>

> You're confusing users with developers.  Code and data structures are
> developer-only items.

yes, but the data structures my code needs are tablature-oriented, not
staff-oriented; for a straight printout I need pretty much what the user
entered.  For a translation to staff, or to another tab form I need that
same data.

> Code and data structures should be compatible with existing LilyPond code
> and data structures.

compatible, yes, equivalent, I think not; but I have to take a peek at
what you have, and that should be pretty soon, the untar utility is
downloading now.

Maybe I could have gotten more smaller stuff, but the tarball is what I
saw, it came down in minutes and is there, so no biggie.

>> User of tablature is thinking of where to put the fingers, which is
>> a stream of
>> 
>> { [flag], {fretlist} }
>> 
>> for italian and french notations, with the fretlist ordered by course
>> and a stream of
>> 
>> { [flag], {fretCoursePolyphony-row1, -row2, -row3, ... }
>> 
>> for german, with course implied by the fretglyph encoding.
> 
> Why isn't "where to put the fingers" a string, fret pair?  That's what it
> seems to me.  Then a duration would be added as well.

dur is given or implied by flag or most recent flag.  It is handy to
seperate the optional glyph from its implicit duration, I do that in my
application, dont know if the like is done in Ly; cant see why it would
be, except perhaps for intermediate notes of a ligatured note in mensural
notation.

German tab is peculiar, unlike french and italian which use a short
alphabet to label the frets, german uses a much extended alphabet to label
all the intersections of fret and course.  A single row of german tab
glyphs can do a drunken walk over the whole fretboard.

>> yes, i see that, and it could work well for 6-course lute tab and cittern
>> tab (4-6 course instrument); but there will be aspects of the notation
>> which simply wont have equivalent data, so maybe in stages.
> 
> Won't every note you want to put on a tab have a pitch, a duration, a string
> (or course), and a fret number?

yes, but there is more than notes to be displayed.  Fingering markup was
used historically, much the same way it is now, pedantically.  RH marks
ims with one, two, three dots.  LH marks with small letters or small
numerals so as to contrast with the fretglyphs.

> Right now, LilyPond has the built-in functionality to, given a pitch, a set
> of string tunings, and a desired string, automatically calculate a fret.

n, that makes german tab unpossible.  

My assumption was that C++ was involved (as it is for me), the data
belonged to a tabStaff object, and it could interpret the glyphs as it
needed to.  When asked for midi it would cycle thru the several rows
looking up the display glyphs to get {fret,course} for italian or french
it cycles thru the courses (rows) and looks in a shorter list of fret
labels.

german tab is nasty evil vile stuff to play from, transliterate, do pretty
much anything with except feed it to a computer (both the vast extended
alphabet and the fraktur fonts used by its printers offend every sense of
most players) "bad even for dwarfs"; but without support for it there is
no way to get it transliterated into users preference of italian or
french.

The row content in german tab is arbitrary, not limited to one course as
is french or italian or modern guitar; german mixes all the courses on
each of its display rows.  Knowing where the glyph is on the instrument
doesnt tell which of the rows of german tab polyphony it belongs to,
leaving no way to display it.  A mapping table associates each glyph to
the pertinent data of {course, fret}  I think it is good to allow the user
to define seperate fonts and encodings for input glyphs and display
glyphs, that would be

  inputGlyph associates to {outputGlyph, string, fret}

Yes, this implies that each tabStaff needs mapping tables (there would be
defaults, I use asciiTab defaults, not pretty, but sometimes what you want
for email or whatever).

> The first thing you will do is add the Scheme code to the LilyPond input
> file.  Eventually, once it's debugged, it can be added to the LilyPond
> distribution.
> 
> Since you put 'scheme' in single quotes, I suspect you don't know about
> Scheme programming.  Scheme is a Lisp-like programming language.

()()((()))()()(((  

I hope not, that kinda stuff leaves me with a headache, thank the gods for
programming editors with () balancing.

-- 
Dana Emery





___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: major feature request (tablature)

[Werner LEMBERG]

> > Since you put 'scheme' in single quotes, I suspect you don't know
> > about Scheme programming.  Scheme is a Lisp-like programming
> > language.
> 
> ()()((()))()()(((  
> 
> I hope not, that kinda stuff leaves me with a headache, thank the
> gods for programming editors with () balancing.

Much more important is proper indenting.  Scheme's parentheses are
rather easy to handle if you write code like this during development:

  (foo
(bla
 ...
 bla
)
  )

and fold it later to

  (foo
(bla
 ...
 bla))


   Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Graham Breed]

2008/12/9 Hans Aberg <[EMAIL PROTECTED]>:
> On 9 Dec 2008, at 13:42, Graham Breed wrote:
>
> And key signatures make the notes sound different.

 Yes, and it's a classic cause of errors in performance, despite the
 key being reinforced by the music.
>>>
>>> If you don't know how to read them.
>>
>> Even if you know how to read them you are likely to make mistakes.
>
> Not using key signatures will not solve that problem.

I didn't say anything about not using them -- although, as it happens,
they are trouble in microtonal music.  What I said is that they lead
to confusion.  The main point is that learning contradictory meanings
for existing symbols has a higher cognitive load than learning new
symbols.

 They always, or even generally, write in major keys.  Willaert, in
 particular, was writing before major keys were defined.  But let's
 assume they'd notate it as just intonation.
>>>
>>> But the question is how to notate a change a key from C to D.
>>
>> Write different notes?
>
> Rather which accidentals do you use?

It depends on what system you use, doesn't it?

Incidentally, JI notations won't usually work with the Lilypond model
because it only allows a single glyph for each alteration.  Pure
sagittal can still go a long way though.

> If transposition calls for say a comma below an m, and that m is computed
> not against E53, but E12, I think there might be an error. I leave it to you
> figure out. By contrast, if it is in E53, then I know it is right, and I do
> not have to do that exercise.

Transpositions aren't "computed against" any equal temperament.  If
you transpose by a comma, then a comma will be added or subtracted
from the previous alterations.  The resulting alterations will be
calculated according to the grid you specified.  If you defined
accidentals for them, those accidentals will be shown.  Maybe there's
an error -- if you find it, report it as a bug.

The difficult case is the most common one where a transposition moves
from one scale degree to another.  In this case it can be separated
into a "microtonal transposition" -- specified according to the
alterations -- and a "diatonic transposition" -- where Lilypond will
use chromatic scale steps.  A diatonic transposition will only lead to
a change of alteration of M-m.  (I hope this is obvious.)  Lilypond
will identify this interval as a "half step" and add or subtract 1/2
from the alterations.  As long as you defined your alterations so that
M-m=1/2 then all will be well.

>>> C to C# is M - m, C to Db is m.
>>>
>>> C to an E31 above C#, can be described as a double flat. double sharp, or
>>> by
>>> adding a neutral second, all having different musical function.
>>
>> No, not an E31.  An enharmonic diesis.
>
> Since the name diesis has many uses, you will have to elaborate.

Since even the name "enharmonic diesis" has more then one use even in
a meantone context, I did elaborate.  I got the definition wrong
though, because I said it was 1 step from 50.  It should be 2 steps so
maybe that's what confused you.  It's 1 step from 19, 31, 43, 55, and
so on adding 12 each time.  In M and m it would be 2m-M I think.

>> m is not a double flat.
>> 2(m-M) would be a double flat.  m is not a double sharp.  2(M-m) would
>> be a double sharp.
>
> In E31m these are 4 tonesteps, so the difference with M is one E31 tonestep.

Yes, but I wasn't talking about E31, and the interval I was talking
about is 3 steps from E31.

>> Adding a neutral second to what?  m is not a
>> neutral second.  m is, in fact, m.  How does abstract m and M
>> distinguish it from m?
>
> If you want to have the tonestep between Db and D, that is a neutral second,
> generating a symbol for an intermediate pitch.

That's true, but nothing to do with what I was talking about.

>>> But i want to find out how you want to notate it: as E53 with
>>> intermediate
>>> pitches or a system where the note names have different interval values.
>>
>> I'm not writing it.  If I did I'd probably use Pythagorean notation
>> with a comma accidental.
>
> So that would then work with the method I gave.

I didn't say it wouldn't.  But, in fact, it wouldn't.  Your
Pythagorean notation would make the comma below E indistinguishable
from Fb.


  Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Diatonic notation system

[Graham Breed]

2008/12/9 Hans Aberg <[EMAIL PROTECTED]>:
> On 9 Dec 2008, at 13:26, Graham Breed wrote:
>
> I attach an example file.

I don't see any transpositions.

> I think it is the commented out part (long time ago), which for some reason
> only works with E24. Therefore, the keys must be written explicitly.

There's a key signature specification which does look like a bug to
me.  I get the same result in 2.11.65.  Have you reported it as a bug?

Some other things from your comments:

The maqamGlyphs list needed ratios because it's quoted, and so the
accidental lookup wasn't doing the correct match against the quoted
pair.  I'm not sure exactly what the right hand side of a variable
assignment is, but this seems to work:

maqamGlyphs = #(list
   (cons FLATFLAT "accidentals.flatflat")
   (cons FLATHALFFLAT "accidentals.mirroredflat.flat")
   (cons FLAT "accidentals.flat")
   (cons HALFFLAT "accidentals.mirroredflat")
   (cons NATURAL "accidentals.natural")
   (cons HALFSHARP "accidentals.sharp.slashslash.stem")
   (cons SHARP "accidentals.sharp")
   (cons SHARPHALFSHARP "accidentals.sharp.slashslash.stemstemstem")
   (cons SHARPSHARP "accidentals.doublesharp")
   )

You say:

%{ Causes error in lilypond/current/scm/lily-library.scm:135:5:
  In procedure ly:book-process in expression (process-procedure book paper ...)
  Wrong type (expecting exact integer): -5/3
%}

I don't see this error.  Looks like a bug's been fixed.

> Let me know how to do E53.

I'll look into it.

 Yes.  That would be chromatic transposition.  I can't see a way to
 specify it in Lilypond.  So what does Lilypond actually do?
>>>
>>> Do not know.
>>
>> Then why are you asking for changes on the developer list?
>
> I have not asked for changes, have I?

What is the purpose of your being on the development list?

>> It records a nominal and a rational alteration.  It generalizes to
>> different alterations.
>
> But that is tied to E12, right?

No!

 Yes, so change the init file.  Why are we going around in circles here?
>>>
>>> Perhaps you are stuck to the same idea, and repeating.
>>
>> I'm stuck with that idea because it works.
>
> In certain primitive settings.

In what settings doesn't it work?

>> Then don't use E24 for Arabic music.
>
> You already do.

I didn't think I used either Arabic music or E24 but I'll yield to
your superior insight.


   Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel