targeting specific context ID's from within \layout?
% Feel free to compile the whole message...
%
% Is there a way to target a specific context (eg. one of
% several Staff contexts) from within the \layout block?
% Here's one case (of many) where I think this would be
% useful:
\version "2.13.34"
%% music for the individual parts:
violin = { c''1 }
cello = { \clef bass c1 }
pianoRH = { c''1 }
pianoLH = { \clef bass c1 }
%% the full score:
fullScore = <<
\new Staff = "violin staff" { \violin }
\new Staff = "cello staff" { \cello }
\new PianoStaff = "piano staves" <<
\new Staff = "piano RH staff" { \pianoRH }
\new Staff = "piano LH staff" { \pianoLH }
>>
>>
%% now some layout styles:
smallStaff = \with {
fontSize = #-3
\override StaffSymbol #'staff-space = #(magstep -3)
\override StaffSymbol #'thickness = #(magstep -3)
}
layoutStyleA = \layout {
\context {
\Staff
\smallStaff
}
}
% Okay, so this is already possible---a score with totally
% separate content and style:
\score {
\fullScore
\layout {
\layoutStyleA
}
}
% but I'd like to be able to target individual contexts from
% within the \layout block:
%{
layoutStyleB = \layout {
\context {
\Staff = "violin staff"
\smallStaff
}
\context {
\Staff = "cello staff"
\smallStaff
}
}
\score {
\fullScore
\layout {
\layoutStyleB
}
}
%}
% Yes, I know I can use individual \with blocks within my
% fullScore definition that refer to generic variables that
% I can define differently in other files for use with
% \include:
%{
\include "style_a.ily"
%\include "style_b.ily"
<<
\new Staff = "violin staff"
\with { \violinStyles } { \violin }
\new Staff = "cello staff"
\with { \celloStyles } { \cello }
% etc...
>>
%}
% But it seems that being able to target contexts by their
% specific ID name would be a lot more flexible (or at least
% easier), especially when a lot of different instruments
% are involved. This would keep the musical content of the
% \score block cleaner; that is to say, content and style
% would be truly separate, which I think is a good thing.
% Is there a way?
%
% Thanks.
% - Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: Doc: LM 3.2: Entering voices in the correct order.
Graham Percival wrote: > Could you stick the next version of this patch on Reitveld? I > think there's enough interest, and enough opinions on it, that > this would be worthwhile. I've not changed anything since last post, but here it is: http://codereview.appspot.com/2226045/ - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add a way to override the part-combination decision
Am Montag, 20. September 2010, um 20:25:30 schrieb Han-Wen Nienhuys: > On Mon, Sep 20, 2010 at 3:07 PM, Reinhold Kainhofer > > My only problem now is that when I add definitions like (so that one can > > also force other types than the pre-defined ones): > > > I am not sure. The warning comes from generic code in translator.cc. > Since the partcombiner passes music through translation twice (once to > determine the split list, once to do the actual typesetting), it may > be helpful to figure out if this comes from the first or the second > run. Without looking more closely I'd suspect that somehow two > different force events are delivered to the same context in the second > pass. Sigh, okay, the problem was that I thought it would be appropriate for the PartCombineForceEvent to be in the event-class part-combine-event, too. Unfortunately, the UnisonoEvent etc. are added by the part-combiner and the PartCombineForceEvent survives the part-combiner, too. Now, the Part_combine_engraver listens to all part-combine-events and really receives two (one UnisonoEvent and one PartCombineForceEvent), triggering an error in the listen_part_combine call, where ASSIGN_ONCE is used... Removed PartCombineForceEvent from the part-combine-event class now. > > And the other small issue I have: Is there any way to let a > > music-function take a symbol (the forced part-combine strategy) or ##f > > (to revert to automatic part-combination) as argument? That would let me > > combine the partcombineAutomatic and partcombineApart etc. definitions > > to one single definition. > > I guess you could create a type predicate symbol-or-false? that > accepts either a symbol or false. I thought that would be seen as quite some hack, so I tried to find out if there is any other way. But weighing defining of such a function against code duplication, the function definition wins ;-) Am Montag, 20. September 2010, um 21:11:57 schrieb Neil Puttock: > On 20 September 2010 19:07, Reinhold Kainhofer wrote: > > Okay, I have now changed the code to use a new PartCombineForceEvent (had > > to add a dummy translator listener to the part-combine engraver to > > silence lilypond) > > Adding the event to `unlistened-music-event-classes' will silence it > without having to add a listener. Ah, thanks, I missed that (I grepped for some other events to see how they are handled without a listener, but I neglected to check the second hit in the define-event-classes.scm file). New patch is up now, which has included all comments and fixed all problems: http://codereview.appspot.com/1698054 Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Possible fix for #372. (issue2228042)
Reviewers: carl.d.sorensen_gmail.com, Message: On 2010/09/19 08:29:23, Carl wrote: As currently implemented, this patch fails when \partial is called in the middle of a measure. I'm not sure \partial *should* work when called in the middle of a measure, but we have plenty of history on -user where it is called in the middle of a measure. I see two options here: -) keep the patch as it is, but warn the user (and do nothing) -) warn the user, but set measurePosition as you suggest to retain the current behaviour I don't mind which we choose, though the former's simpler. I've put the code that duplicates the previous behavior in the comments below. Thanks. P.S. How should one handle a code variant when doing reviews on Rietveld? Should we create a new issue? Should we show alternate code in comments? I think creating a new issue is overkill, unless the changes are significant. I'm happy with code changes in comments. Cheers, Neil Description: Possible fix for #372. Please review this at http://codereview.appspot.com/2228042/ Affected files: M input/regression/display-lily-tests.ly A lily/partial-iterator.cc M scm/define-music-display-methods.scm M scm/define-music-properties.scm M scm/define-music-types.scm M scm/ly-syntax-constructors.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Web: Easier editing: Add link to Abjad website.
On Mon, Sep 20, 2010 at 9:34 PM, Mark Polesky wrote: > Graham Percival wrote: >>> -...@subheading Other programs can export LilyPond code >>> +...@subheading Other programs that can export LilyPond code >> >> This makes it sound as though the previous programs can >> export lilypond code. Only Denemo falls into that >> category; all the other programs are text editor-types. >> >> Could you just omit this change? > > How about just "Programs that can export LilyPond code"? If > you don't like that I'll just keep the old version. That's fine. >> Hmm. I know that the current entry for Strasheela uses >> @qq, but I'd rather avoid that. Could you omit the @qq, >> or if you want to totally play by copyright law, ask >> Trevor (off-list) for permission to re-use that sentence >> fragment on our website? Or just write a new one-sentence >> description? > > Since the sentence is almost exactly what Trevor suggested > off-list (I condensed it from two sentences), I prefer to > keep the @qq, but if there's any other reason you don't like > the @qq, let me know. A @qq is a quotation. Are we directly quoting their website? Why? Why can't we just write+use our own description -- especially since it sounds like Trevor already did this? I mean, if he said "sure, go ahead and describe it as a foobazzling the bar", then I'm fine with that description -- but just remove the @qq, and write: foo is a program which bazzles the bar. I'm kind-of applying academic thinking here... when you mention a paper in your "related work", you're not supposed to just quote a sentence from their abstract; you're expected to write your own description of the paper. Dunno why this traditional originated. >> While we're at it, could you write a new description for >> [Strasheela]? Again, I'd prefer to avoid a @qq unless >> it's necessary. If not, I'm happy to do this; I used >> strasheela for my Masters degree. > > I wouldn't know what to write; if you want to write it in > your reply, I'll add it to the patch. I've added it to my TODO list, but I won't get to it until tomorrow. If you want, you can move on with the patch, and I'll change it later. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Web: Easier editing: Add link to Abjad website.
Graham Percival wrote:
>> -...@subheading Other programs can export LilyPond code
>> +...@subheading Other programs that can export LilyPond code
>
> This makes it sound as though the previous programs can
> export lilypond code. Only Denemo falls into that
> category; all the other programs are text editor-types.
>
> Could you just omit this change?
How about just "Programs that can export LilyPond code"? If
you don't like that I'll just keep the old version.
>> +...@uref{http://www.projectabjad.org/,Abjad}, a
>> +...@uref{http://www.python.org/,Python} API for
>> Formalized Score +Control, @qq{designed to help
>> composers build up complex pieces of +LilyPond notation
>> in an iterative and incremental way.}
>
> Hmm. I know that the current entry for Strasheela uses
> @qq, but I'd rather avoid that. Could you omit the @qq,
> or if you want to totally play by copyright law, ask
> Trevor (off-list) for permission to re-use that sentence
> fragment on our website? Or just write a new one-sentence
> description?
Since the sentence is almost exactly what Trevor suggested
off-list (I condensed it from two sentences), I prefer to
keep the @qq, but if there's any other reason you don't like
the @qq, let me know.
> While we're at it, could you write a new description for
> [Strasheela]? Again, I'd prefer to avoid a @qq unless
> it's necessary. If not, I'm happy to do this; I used
> strasheela for my Masters degree.
I wouldn't know what to write; if you want to write it in
your reply, I'll add it to the patch. Alternatively, we
could send them a simple request for permission to keep the
quote (unless again you have some other specific objection
to @qq).
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add a way to override the part-combination decision
On 20 September 2010 19:07, Reinhold Kainhofer wrote: > Okay, I have now changed the code to use a new PartCombineForceEvent (had to > add a dummy translator listener to the part-combine engraver to silence > lilypond) Adding the event to `unlistened-music-event-classes' will silence it without having to add a listener. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 20 Sep 2010, at 18:00, Wols Lists wrote: As a related issue, have you considered how (different kinds of) transposition would be handled in your pitch scheme? This is much simpler: the linear combinations are vectors that you just add. For example, if a, b, c, ... are represented by 0, M, m+M, ..., and you want to transpose from b to c, just add m. A sharp is M-m and a flat m-M. If you want transpose from a note x to a note y, just add y - x. What you've missed (and I need to address) is "what is x?". Let's say I want to transpose up three semitones. That's probably easy, it's a minor third, but it could be an augmented second. So, trying to remember the pitch class, is it (0,2,sharp) or (0,3,flat)? The staff system always distinguishes between those, because they have different degrees, which are put in different positions. A minor third m3 = m + M has deg(m + M) = deg m + deg M = 2; an augmented second M + (M - m) = 2M - m has degree 1 as an accidental does not change the degree. The first one will move the notes two steps, and the second one step. And, for your example of that, I've currently got a modified chord engraver on the frogs list that's added a guitar capo property. All the engraver is told is how many semitones to transpose, and it's got to sort out all the keys! Then with this system, you will have to add E12 enharmonic equivalences afterwards. It is not difficult: add or subtract M - 2m. But the degree of M - 2m is -1, so the position on the staff will change, like for example F# <-> Gb. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add a way to override the part-combination decision
On Mon, Sep 20, 2010 at 3:07 PM, Reinhold Kainhofer wrote: > Am Freitag, 17. September 2010, 14:52:50 schrieb Han-Wen Nienhuys: >> On Fri, Sep 17, 2010 at 7:48 AM, Reinhold Kainhofer >> >> wrote: >> > So, you think we should rather extend the parser to cater for that >> > feature? (Or do you know any way to insert an event in simple_music >> > without extending the parser?) >> >> I was thinking of inserting a zero duration music event, similar to >> eg. barcheck, through an identifier. > > Okay, I have now changed the code to use a new PartCombineForceEvent (had to > add a dummy translator listener to the part-combine engraver to silence > lilypond) > > New patch is up at: > http://codereview.appspot.com/1698054/ > > > My only problem now is that when I add definitions like (so that one can also > force other types than the pre-defined ones): > > > Strangely, it does not happen when I define partcombineApart etc. as > > > Any idea what the difference between these two definitions are? I am not sure. The warning comes from generic code in translator.cc. Since the partcombiner passes music through translation twice (once to determine the split list, once to do the actual typesetting), it may be helpful to figure out if this comes from the first or the second run. Without looking more closely I'd suspect that somehow two different force events are delivered to the same context in the second pass. > And the other small issue I have: Is there any way to let a music-function > take a symbol (the forced part-combine strategy) or ##f (to revert to > automatic part-combination) as argument? That would let me combine the > partcombineAutomatic and partcombineApart etc. definitions to one single > definition. I guess you could create a type predicate symbol-or-false? that accepts either a symbol or false. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Add a way to override the part-combination decision
Am Freitag, 17. September 2010, 14:52:50 schrieb Han-Wen Nienhuys: > On Fri, Sep 17, 2010 at 7:48 AM, Reinhold Kainhofer > > wrote: > > So, you think we should rather extend the parser to cater for that > > feature? (Or do you know any way to insert an event in simple_music > > without extending the parser?) > > I was thinking of inserting a zero duration music event, similar to > eg. barcheck, through an identifier. Okay, I have now changed the code to use a new PartCombineForceEvent (had to add a dummy translator listener to the part-combine engraver to silence lilypond) New patch is up at: http://codereview.appspot.com/1698054/ My only problem now is that when I add definitions like (so that one can also force other types than the pre-defined ones): partcombineForce = #(define-music-function (location parser type once) (symbol? boolean?) ) partcombineApart = \partcombineForce #'apart ##f partcombineApartOnce = \partcombineForce #'apart ##t then processing a file containing some part-combine overrides, I often get a warning (not all the time, seems to depend on the music structure...): warning: Two simultaneous part-combine events, junking this one warning: Previous part-combine event here Strangely, it does not happen when I define partcombineApart etc. as #(define (make-part-combine-force type once) (make-music 'EventChord 'elements (list (make-music 'PartCombineForceEvent 'forced-type type 'once once partcombineApart = #(define-music-function (parser location) () (make-part-combine-force 'apart #f)) Any idea what the difference between these two definitions are? And the other small issue I have: Is there any way to let a music-function take a symbol (the forced part-combine strategy) or ##f (to revert to automatic part-combination) as argument? That would let me combine the partcombineAutomatic and partcombineApart etc. definitions to one single definition. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 20/09/10 14:41, Hans Aberg wrote: >> As a related issue, have you considered how (different kinds of) >> transposition would be handled in your pitch scheme? > > > This is much simpler: the linear combinations are vectors that you > just add. For example, if a, b, c, ... are represented by 0, M, m+M, > ..., and you want to transpose from b to c, just add m. A sharp is M-m > and a flat m-M. If you want transpose from a note x to a note y, just > add y - x. What you've missed (and I need to address) is "what is x?". Let's say I want to transpose up three semitones. That's probably easy, it's a minor third, but it could be an augmented second. So, trying to remember the pitch class, is it (0,2,sharp) or (0,3,flat)? And, for your example of that, I've currently got a modified chord engraver on the frogs list that's added a guitar capo property. All the engraver is told is how many semitones to transpose, and it's got to sort out all the keys! Cheers, Wol ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On Mon, Sep 20, 2010 at 5:25 PM, David Kastrup wrote: > Joseph Wakeling writes: > >> Indeed, d-3/4 is not sufficient [1]: in arrow quarter-tone notation you >> want to be able to indicate quarter-tone raising or lowering of any of >> the 12 standard tones. > > One solution would be to allow pitch modifiers to be a list of fractions > rather than just a single fraction. > > Sounds rather messy. Yes. My first thought was to add a fourth value to pitches -- octave, scale-note, normal-alteration, extra-alteration -- but this would also make things messy. I'm not sufficiently familiar with lilypond internals to make any kind of guess as to which is messier, or whether there's any alternate methods of doing this... I'm just trying to help the organization of development, and defining the problem clearly is the first step. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Files for the first phase of Czech translation of documentation
Hi,
thanks for answer, so the e-mail adress, I sent the files is good for
translation issues and I will send the answers there, not directly to
developers. :-)
I think, that I am the only one in this moment, who cares about bringing
LilyPond to Czech language. I´ve already worked on lilypond.po hosted on
Translation Project, but probably due to unchanged header - it tells, that it
is LilyPond in version 1.6 or so - also it is not loaded by LilyPond to
project, because of this misunderstanding (the file was completed to current
version just before one year. Then I am working regularly on Frescobaldi for
abou one year and half.
> Are you sure the German template is up to date? It's good to see what
> other translations do to give you some idea by examples, but it's better
> to start from docs in English, using template generation tools explained
> in the Contributors' Guide, even if these are not perfect. As the docs
> maintenance and development is English-speaking-centric, and it would be
> very hard to change this development model, I'd rather not take files
> from a language other than English, or if I did I would carefully check
> that the translation was up-to-date at last release on
> http://lilypond.org/doc/v2.13/Documentation/web/translated.html
Yes, I think. and when I am not much skilled in texinfo structure and commands,
I am still not much experienced, I can, using German files, just focus on
translation.
> > @ref{Textový vstup}
> > @unnumberedsec Textový vstup
> > @translationof Text input
>
> I guess you mean "@node Textový vstup" instead of "@ref{Textový vstup}"
> here.
Yes, it is. Thanks for manual how to deal with it. I am interested in all, what
you can offer. If I understand, I only have to add "nominative" on proper
places and two commas. The I ask you for manual how to deal with definitions in
"macro" file.
> There is a way to respect cases by defining a value of the third
> argument of @ref command as the text you'd like to make appear, whereas
> the first argument to @ref command should always be the exact node name
> so that a dummy computer program can find where the node was defined,
> that is you should write @ref commands like (note the two commas)
>
> @ref{NODE_NAME_AS_DEFINED,,NODE_NAME_AS_IT_SHOULD_READ}
>
> e.g. in the example you give
>
> @ref{Textový vstup,,Textovém vstupu}
>
> This way of doing things means extra work for you, and it's only up to
> you (and other Czech translators for LilyPond if any) to decide whether
> to use correct cases to node names in cross-references. If you decide
> to do so, macros used for cross-references to other LilyPond manuals
> (@ruser @rlearning etc.) may need this kind of treatment as well, I'll
> explain you how in case you have decided to use correct cases.
Greetings, Pavel Fric
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 20 Sep 2010, at 18:08, Joseph Wakeling wrote: One scan should be fine. The first step is to convince people that the representation needs to be extended, and Stone should be sufficient for that. The next step is for somebody actually code it. Sure. I'll try and follow up with Hans separately, just to explore his code and ideas and see if they might be useful here. The algebraic approach I described solves your problem - that is one reason for doing it. The staff system does not in itself impose enharmonic equivalences. One can add them afterwards, with a method that gives better control. In your example, you start off with a minor second m and a major second M, and adds a neutral second n representing the quarter-tone. The full set of abstract pitches is p m + r M + q n, where p, q, r are integers. In E24, m = 2, M = 4, n = 3. But the problem is that the staff system does not as such take any enharmonic equivalences into account. One can see this by computing degrees: For example, if we are using the very common 'arrow' notation for quarter-tones, there are two distinct accidentals that can be used to represent the alteration +1/4 (i.e. quarter-tone-sharp): the first is a natural sign with an up arrow, the second is a sharp sign with a down arrow. There is currently no effective, well-defined way to indicate which of the two is desired at any given moment. For two pitches or intervals x, y, write the difference y - x more intuitively as x->y. Then a sharp is m->M and a flat M->m. In addition, there are two quarter-tone accidentals m->n, the up arrow, and M->n, the down arrow. There also another pair of accidentals that would be needed if you use up/down arrows meaning a small amount, not necessarily an exact quarter-tone: n->m and n->M. One then also needs arrows indicating a large amount but not fully a flat or sharp, in total four microtonal accidental symbols. Four microtonal accidentals are used in Turkish music, though not Arab and Persian music, which has to do with how intervals are divided. Now compute degrees, to see that applying an E24 enharmonic equivalence changes the degree, and therefore also the position of the note in the staff system: Accidentals are of degree zero, so adding them to a note does not change the degree. So a note x with m->n added has the same degree as x. If you want to write the E24 enharmonic equivalent, a semitone above x lowered a quarter-tone, then this is x + m + M->n, and its degree is one above that of x, as the degree of m is one, and deg(x + y) = deg x + deg y. So these notes are different. If one wants enharmonic equivalencies, then those should be applied afterwards. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
Joseph Wakeling writes: > On 09/20/2010 03:22 PM, Graham Percival wrote: >> Hmm. This is similar to the distinction between cis and des, correct? > > Yes, exactly, it's an enharmonic equivalence. > >> Am I also correct in assuming that d-3/4 is not sufficient? Also, is >> there a frequency difference between c+1/4 and cis-1/4 ? Or is this >> purely a difference in graphical notation? > > Indeed, d-3/4 is not sufficient [1]: in arrow quarter-tone notation you > want to be able to indicate quarter-tone raising or lowering of any of > the 12 standard tones. One solution would be to allow pitch modifiers to be a list of fractions rather than just a single fraction. Sounds rather messy. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 05:27 PM, Graham Percival wrote: >> For arrowed quarter-tones the notation is described (and recommended) in >> Kurt Stone's book "Music Notation in the Twentieth Century". > > Excellent reference! That book is frequently quoted on this list, so > this should settle any question of "is it necessary". Yes. :-) He also explicitly highlights the enharmonic equivalence issue we discussed. > One scan should be fine. The first step is to convince people that > the representation needs to be extended, and Stone should be > sufficient for that. The next step is for somebody actually code it. Sure. I'll try and follow up with Hans separately, just to explore his code and ideas and see if they might be useful here. Thanks & best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Files for the first phase of Czech translation of documentation
Hi Pavel,
Francisco has already replied to you while I was writing this, so the
reply about the node name issue w.r.t. cases in Czech is just a
rewording of his last reply.
Il giorno dom, 19/09/2010 alle 15.36 +0200, Pavel Fric ha scritto:
> I send the files in attachment. The .po file was sent already before.
> The template was taken from German translation files, so I didn't
> handle with the structure of files, only translated texts in German
> language.
Are you sure the German template is up to date? It's good to see what
other translations do to give you some idea by examples, but it's better
to start from docs in English, using template generation tools explained
in the Contributors' Guide, even if these are not perfect. As the docs
maintenance and development is English-speaking-centric, and it would be
very hard to change this development model, I'd rather not take files
from a language other than English, or if I did I would carefully check
that the translation was up-to-date at last release on
http://lilypond.org/doc/v2.13/Documentation/web/translated.html
> I have one question. There are lines with:
>
>
> @ref{Textový vstup}
> @unnumberedsec Textový vstup
> @translationof Text input
I guess you mean "@node Textový vstup" instead of "@ref{Textový vstup}"
here.
> and on other place:
>
> @ref{Textovém vstupu}
>
> "Text input" in braces is in the first case translated in the
> nominative (1. pád), but in the second case in ablative or say
> locative (6. pád)
>
> Does it matter? This "problem" - difference between text strings in
> braces is only on some places, not all. The solution would be somehow
> change the syntax of statement, or force nominative, even if the
> beauty of language would suffer.
There is a way to respect cases by defining a value of the third
argument of @ref command as the text you'd like to make appear, whereas
the first argument to @ref command should always be the exact node name
so that a dummy computer program can find where the node was defined,
that is you should write @ref commands like (note the two commas)
@ref{NODE_NAME_AS_DEFINED,,NODE_NAME_AS_IT_SHOULD_READ}
e.g. in the example you give
@ref{Textový vstup,,Textovém vstupu}
This way of doing things means extra work for you, and it's only up to
you (and other Czech translators for LilyPond if any) to decide whether
to use correct cases to node names in cross-references. If you decide
to do so, macros used for cross-references to other LilyPond manuals
(@ruser @rlearning etc.) may need this kind of treatment as well, I'll
explain you how in case you have decided to use correct cases.
All the best,
John
signature.asc
Description: This is a digitally signed message part
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Files for the first phase of Czech translation of documentation
2010/9/20 Francisco Vila :
>> @ref{Textový vstup}
>> @unnumberedsec Textový vstup
>> @translationof Text input
>>
>> and on other place:
>>
>> @ref{Textovém vstupu}
>> Does it matter? This "problem" - difference between text strings in braces
>> is only on some places, not all. The solution would be somehow change the
>> syntax of statement, or force nominative, even if the beauty of language
>> would suffer.
>
> I'm afraid I don't catch the problem. Is there any obstacle to put
> the best possible translation in every case? You are in charge of
> your language. We trust you. Just don't forget to make all links
> work even when some strings may be different.
Oops, sorry. I got it. No, you have to choose a proper string which
fits on both cases, or links will not work. You could use the named
variant of the ref macro, see macros.itexi for this, whenever you
really need to make a ref with a different text.
Hope this answers your question, ask again if not.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Files for the first phase of Czech translation of documentation
2010/9/19 Pavel Fric :
> Hi,
>
> Francisco Vila. Badajoz (Spain): "From now on, please keep this conversation
> in the translators list."
>
> Could you provide link to this mailing list?
http://lists.lilynet.net/translations/
> I have one question. There are lines with:
>
>
> @ref{Textový vstup}
> @unnumberedsec Textový vstup
> @translationof Text input
>
> and on other place:
>
> @ref{Textovém vstupu}
>
> "Text input" in braces is in the first case translated in the nominative (1.
> pád), but in the second case in ablative or say locative (6. pád)
>
> Does it matter? This "problem" - difference between text strings in braces is
> only on some places, not all. The solution would be somehow change the syntax
> of statement, or force nominative, even if the beauty of language would
> suffer.
I'm afraid I don't catch the problem. Is there any obstacle to put
the best possible translation in every case? You are in charge of
your language. We trust you. Just don't forget to make all links
work even when some strings may be different.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On Mon, Sep 20, 2010 at 3:56 PM, Joseph Wakeling wrote: > On 09/20/2010 03:22 PM, Graham Percival wrote: >> 2) make a scan of some published music that uses this notation. This >> will immediately silence anybody who wants to argue (as I somewhat >> did) that a single fraction is sufficient to show any microtonal >> notation. > > For arrowed quarter-tones the notation is described (and recommended) in > Kurt Stone's book "Music Notation in the Twentieth Century". Excellent reference! That book is frequently quoted on this list, so this should settle any question of "is it necessary". > I don't > own a scanner :-( but will try and take a copy of the relevant page > (it's pp.67-70 IIRC; I was looking at it last night). Wait a few days; many people here own a copy, so somebody might make a scan for you. > There are various other notations to consider that have a similar > character. I'll try and prepare a variety of representative examples. One scan should be fine. The first step is to convince people that the representation needs to be extended, and Stone should be sufficient for that. The next step is for somebody actually code it. The third step is the graphical output, and additional examples would only be necessary if Stone was unclear. But this is probably months off, and needs to be examined by a font person, so don't fuss about it now. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 2.2.1 keyboards, staff changes
Keith E OHara wrote Monday, September 20, 2010 12:38 AM I am suggesting a new @knownissues for the Notation Reference 2.2.1. The corresponding bug tracker issues are 1043, 439, and 36. If issue 1043 is solved, the second paragraph of my suggestion will become obsolete. I wrote the text below based on observed behavior of LilyPond 2.12.3 and 2.13.33 (as opposed to understanding its code). I have been using the workaround for six months, including about three piano pieces where the work-around-able issue came up. Keith Although this would seem to be a valuable addition to the Notation Reference, the policy is not to add bugs which are in the bug tracker to @knownissues. With 420 open bugs, adding each of them to the documentation is both impractical and wasteful of resources, as they would need to be removed as soon as they were fixed, often within a few weeks. An exception might be made for defects marked "postponed", as that means they will not be fixed in the foreseeable future. But that doesn't apply to any of these bugs at present. But thanks for taking the trouble to do this. Even if it doesn't make it to the docs your post will remain available in the archives where it can be found by others. [Graham: I know this is, or at least was, the policy, but I don't see it in the CG.] Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 03:22 PM, Graham Percival wrote: > Hmm. This is similar to the distinction between cis and des, correct? Yes, exactly, it's an enharmonic equivalence. > Am I also correct in assuming that d-3/4 is not sufficient? Also, is > there a frequency difference between c+1/4 and cis-1/4 ? Or is this > purely a difference in graphical notation? Indeed, d-3/4 is not sufficient [1]: in arrow quarter-tone notation you want to be able to indicate quarter-tone raising or lowering of any of the 12 standard tones. There should be no frequency difference between c+1/4 and cis-1/4. Some composers do use the arrow notation to indicate approximate quarter-tones, but many assume that the quarter-tones are exact. I did prepare a "cheat" implementation of quarter-tone arrow notation where there were subtle pitch differences (c+999/4000, cis-999/4000). This kind of works but it generates all sorts of nightmares with transposition and means having to write out a HUGE accidentals list (see discussion in Issue 694). > I believe that this is a valid feature request -- a single > "alteration" value is not sufficient to distinguish between c+1/4 and > cis-1/4. Yes -- but it goes beyond arrowed quarter-tone notation. I was a bit long-winded and abstract because I wanted to stress that it was a general problem for many different microtonal notations, rather than just arrow quarter-tones. > As a general rule -- please take the time to prepare a tiny .ly > example showing what you wanted to do. It took me about 10 minutes to > read your email, think about it, and prepare a good tiny example. > Since you're more familiar with this material, you probably could have > made the example in 2-3 minutes. Having an example makes the > difference between a developer understanding the issue in a matter of > 30 seconds vs. 3 minutes, and when we have over 400 open > bugs+enhancement requests, that difference is significant. Yes, I'll try and do that in future. > 2) make a scan of some published music that uses this notation. This > will immediately silence anybody who wants to argue (as I somewhat > did) that a single fraction is sufficient to show any microtonal > notation. For arrowed quarter-tones the notation is described (and recommended) in Kurt Stone's book "Music Notation in the Twentieth Century". I don't own a scanner :-( but will try and take a copy of the relevant page (it's pp.67-70 IIRC; I was looking at it last night). There are various other notations to consider that have a similar character. I'll try and prepare a variety of representative examples. > 3) send it the bug list so that it gets added to the tracker. > > 4) wait. Maybe offer a bounty to entice somebody to work on it. Hans Aberg's work looks promising. I don't understand it properly yet, but I'll try and prepare a set of examples to test whether it could provide a solution. Best wishes, -- Joe [1] There used to be a "how to do arrow quarter-tone notation" example somewhere in the docs, which "solved" the problem by simply not having a cis-1/4 symbol. That was what got me thinking about the whole issue in the first place. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Files for the first phase of Czech translation of documentation
Hi,
Francisco Vila. Badajoz (Spain): "From now on, please keep this conversation in
the translators list."
Could you provide link to this mailing list?
I send the files in attachment. The .po file was sent already before. The
template was taken from German translation files, so I didn't handle with the
structure of files, only translated texts in German language.
I have one question. There are lines with:
@ref{Textový vstup}
@unnumberedsec Textový vstup
@translationof Text input
and on other place:
@ref{Textovém vstupu}
"Text input" in braces is in the first case translated in the nominative (1.
pád), but in the second case in ablative or say locative (6. pád)
Does it matter? This "problem" - difference between text strings in braces is
only on some places, not all. The solution would be somehow change the syntax
of statement, or force nominative, even if the beauty of language would suffer.
If all right, please, inform me about the creation of patch. Otherwise the
changes should be made.
Note: the code for Czech language should be "cs".
Greetings, Pavel Fric
Dokumentation - czech - 1 phase.tar.gz
Description: GNU Zip compressed data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Docs, keyboards, staff changes, workaround
Friends of LilyPond,
I am suggesting a new @knownissues for the Notation Reference 2.2.1. The
corresponding bug tracker issues are 1043, 439, and 36. If issue 1043 is
solved, the second paragraph of my suggestion would be come obsolete.
I wrote the text below based on observed behavior of LilyPond 2.12.3 and
2.13.33 (as opposed to understanding its code). I have been using the
workaround for six months, including about three piano pieces where the
work-around-able issue came up.
--
Keith OHara
keyboards.itely
at line 215, to become the last section of @node Changing staff manually
@knownissues
Beams that cross staves cannot vertically displace other notation
like normal beams do. Vertical collision resolution is suspended for such
beams,
and their associated stems,
so they might overlap other notation such as dynamics.
A staff change can also prevent proper collision resolution
for a beam that ends immediately before the staff change,
if that beam was created automatically.
Specify beams near staff changes manually with @code{[} and @code{]}
to restore collision resolution in these situations.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR 2.2.1 keyboards, staff changes
Friends of LilyPond,
I am suggesting a new @knownissues for the Notation Reference 2.2.1. The
corresponding bug tracker issues are 1043, 439, and 36. If issue 1043 is
solved, the second paragraph of my suggestion will become obsolete.
I wrote the text below based on observed behavior of LilyPond 2.12.3 and
2.13.33 (as opposed to understanding its code). I have been using the
workaround for six months, including about three piano pieces where the
work-around-able issue came up.
--
Keith OHara
keyboards.itely
at line 215, to become the last section of @node Changing staff manually
@knownissues
Beams that cross staves cannot vertically displace other notation
like normal beams do. Vertical collision resolution is suspended for such
beams,
and their associated stems,
so they might overlap other notation such as dynamics.
A staff change can also prevent proper collision resolution
for a beam that ends immediately before the staff change,
if that beam was created automatically.
Specify beams near staff changes manually with @code{[} and @code{]}
to restore collision resolution in these situations.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 20 Sep 2010, at 14:48, Joseph Wakeling wrote: I saw the post but was not sure quite how to interpret it. I expected someone to ask for details. In the past, I discussed part of it with Graham Breed, who did some LilyPond microtonal implementation, but perhaps he is not working on it anymore. I get the feeling activity is rather focused right now on getting 2.14 released ... :-) So the problem is finding someone willing to have a look at it from the LilyPond side. I also discussed microtonal stuff with Graham Breed a while back, but we weren't really able to bring anything to a satisfactory conclusion. Graham's code is within LilyPond's current model. We discussed a bit this extension, but at that time, I had not made a full generalization. If you want, I can explain it - the algorithm itself is very simple. Writing up it in math style will probably not make it more accessible. It would make it clearer to me, surely. What I'd like to see is for it to be written up in a structured way along the lines of Sure, just get back if you want more details or examples. (i) this is the problem that needs solving, The staff can be an arbitrary scale (see below), and one has music in another. The problem is to compute, for any note, the accidental to use, and the key signature. The latter follows from the former, though. The scales of the staff and the music choose their pitches as integer linear combinations from an abstract set of seconds. In the traditional typesetting, one has a minor second m and a major second M, so it is all combinations p m + q M, where p, q are integers, which can be identified with all pairs (p, q). Mathematically, I am looking the free abelian group generated by the intervals one wants to use. The traditional staff scale is the minor scale: 0, M, m+M, ..., corresponding to a, b, c, This can be extended to other types of accidentals by adding neutral seconds n_1, ... For Persian, Arab, Turkish music, and Just Intonation relative Pythagorean, in each, just one neutral suffices, but it has different values when giving it a value. (ii) this is the approach the algorithm takes to solve the problem, One needs an order between the seconds, which is a choice of preference by the one typesetting the music. (iii) this is the algorithm. Call the sum of the coefficients of a linear combination the degree of the note. A requirement is that the staff provides a note for every degree (also having that degree) one wants to typeset a note for. In order to typeset a note, first compute its degree, and then subtract the staff note of that degree. The result is a note of degree zero, which should be typeset using an accidental. An accidental is represented by a linear combination with positive coefficients of pairs of distinct seconds. Compute its accidental by successively reducing the first (relative the order of the seconds) positive and negative coefficients until it stops (the note is 0). As you can see, there are really no requirements of what scales to use. So it pushes the staff notation to its utmost capabilities. I did wonder if the fact it was Haskell code was part of the reason for the lack of response. I have a lot of admiration for Haskell but I can see there being problems extending Lilypond with yet another language. , It should not be difficult to translate into Scheme - no specific Haskell features are used, only better syntax and type system to help structuring the code. It is just a page. The difficulty is to figure out to put it into LilyPond. Indeed, it sounds like a pretty fundamental major-version-number-changing kind of modification. It might be. But it is a generalization, that is, one builds an interface on top which expresses the current LilyPond model. Then the rest can be changed when one has time. As a related issue, have you considered how (different kinds of) transposition would be handled in your pitch scheme? This is much simpler: the linear combinations are vectors that you just add. For example, if a, b, c, ... are represented by 0, M, m +M, ..., and you want to transpose from b to c, just add m. A sharp is M-m and a flat m-M. If you want transpose from a note x to a note y, just add y - x. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On Sun, Sep 19, 2010 at 11:50 PM, Joseph Wakeling
wrote:
>
> *A key assumption of this approach is that there is a one-to-one
> correspondence between accidental and alteration value.* This clearly
> holds for conventional Western 12-tone notation. However, it does _not_
> hold for many _microtonal_ notations.
>
> For example, if we are using the very common 'arrow' notation for
> quarter-tones, there are two distinct accidentals that can be used to
> represent the alteration +1/4 (i.e. quarter-tone-sharp): the first is a
> natural sign with an up arrow, the second is a sharp sign with a down
> arrow. There is currently no effective, well-defined way to indicate
> which of the two is desired at any given moment.
Hmm. This is similar to the distinction between cis and des, correct?
Am I also correct in assuming that d-3/4 is not sufficient? Also, is
there a frequency difference between c+1/4 and cis-1/4 ? Or is this
purely a difference in graphical notation?
I believe that this is a valid feature request -- a single
"alteration" value is not sufficient to distinguish between c+1/4 and
cis-1/4. For an ideal enhancement request:
1) prepare a Tiny .ly showing what you want to do. Something like:
// made-up syntax
#define qis as "one quarter-tone sharp"
#define qes as "one quarter-tone flat"
\displayMusic {
// these should have different representations!
cqs2 cisqes2
}
err, ok, I already made up the example, so you don't need to do this.
NB: this request is only about the internal representation, not the
graphical output.
As a general rule -- please take the time to prepare a tiny .ly
example showing what you wanted to do. It took me about 10 minutes to
read your email, think about it, and prepare a good tiny example.
Since you're more familiar with this material, you probably could have
made the example in 2-3 minutes. Having an example makes the
difference between a developer understanding the issue in a matter of
30 seconds vs. 3 minutes, and when we have over 400 open
bugs+enhancement requests, that difference is significant.
Please note that I'm not trying to be snarky or lazy here. It's just
that I've honestly seen the difference between well-written (i.e.
small) proposals and vague requests -- better proposals tend to get
action sooner. Recall Pascal's "I apologize that this letter is so
long - I lacked the time to make it short."
2) make a scan of some published music that uses this notation. This
will immediately silence anybody who wants to argue (as I somewhat
did) that a single fraction is sufficient to show any microtonal
notation.
3) send it the bug list so that it gets added to the tracker.
4) wait. Maybe offer a bounty to entice somebody to work on it.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 12:23 PM, Hans Aberg wrote: >> I saw the post but was not sure quite how to interpret it. > > I expected someone to ask for details. In the past, I discussed part of > it with Graham Breed, who did some LilyPond microtonal implementation, > but perhaps he is not working on it anymore. I get the feeling activity is rather focused right now on getting 2.14 released ... :-) I also discussed microtonal stuff with Graham Breed a while back, but we weren't really able to bring anything to a satisfactory conclusion. > If you want, I can explain it - the algorithm itself is very simple. > Writing up it in math style will probably not make it more accessible. It would make it clearer to me, surely. What I'd like to see is for it to be written up in a structured way along the lines of (i) this is the problem that needs solving, (ii) this is the approach the algorithm takes to solve the problem, (iii) this is the algorithm. >> I did wonder if the fact it was Haskell code was part of the reason for >> the lack of response. I have a lot of admiration for Haskell but I can >> see there being problems extending Lilypond with yet another language. > > It should not be difficult to translate into Scheme - no specific > Haskell features are used, only better syntax and type system to help > structuring the code. It is just a page. > > The difficulty is to figure out to put it into LilyPond. Indeed, it sounds like a pretty fundamental major-version-number-changing kind of modification. As a related issue, have you considered how (different kinds of) transposition would be handled in your pitch scheme? Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 20 Sep 2010, at 12:08, Joseph Wakeling wrote: Hence why I say that the issue of effective microtonal support still requires action at the code level, and is not simply a matter of better documentation ... :-( I made a post about this issue last week, but there were no responses. http://lists.gnu.org/archive/html/lilypond-devel/2010-09/ msg00138.html I saw the post but was not sure quite how to interpret it. I expected someone to ask for details. In the past, I discussed part of it with Graham Breed, who did some LilyPond microtonal implementation, but perhaps he is not working on it anymore. Could you write up some more extensive notes on the algorithm and its aims and possibilities? If you want, I can explain it - the algorithm itself is very simple. Writing up it in math style will probably not make it more accessible. I did wonder if the fact it was Haskell code was part of the reason for the lack of response. I have a lot of admiration for Haskell but I can see there being problems extending Lilypond with yet another language. It should not be difficult to translate into Scheme - no specific Haskell features are used, only better syntax and type system to help structuring the code. It is just a page. The difficulty is to figure out to put it into LilyPond. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 09/20/2010 10:47 AM, Hans Aberg wrote: > On 20 Sep 2010, at 00:50, Joseph Wakeling wrote: > >> Hence why I say that the issue of effective microtonal support still >> requires action at the code level, and is not simply a matter of better >> documentation ... :-( > > I made a post about this issue last week, but there were no responses. > > http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00138.html I saw the post but was not sure quite how to interpret it. Could you write up some more extensive notes on the algorithm and its aims and possibilities? I did wonder if the fact it was Haskell code was part of the reason for the lack of response. I have a lot of admiration for Haskell but I can see there being problems extending Lilypond with yet another language. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: separating music and guitar instructions
On Wed 15 Sep 2010, 22:40 Xavier Scheuer wrote: > On 15 September 2010 19:53, Vicente Solsona wrote: > > It probably has something to do with the fact that string numbers and > > right hand fingers must be put inside a chord, but skips cannot, but > > I'm stuck here. > > This limitation that string numbers, right hand fingers > (but fingeringOrientations too!) require to be put inside a chord > construct _is_ annoying. Hi, Xavier! i feel like i can not understand what's wrong (i never typed guitar scores), so i would ask you -- if this issue is still important -- to make "a bit better worded issue report", just for me, i will try again .) Then i'll be able to search tracker or the like; then i'll be able (i hope!) to decide what to do with this. If not --- i'll ask again .) I would not like this "annoying and non-friendly limitation" was lost. Thank you! > I'm sure some devs already tried to struggle with this, I think there > should be at least one open issue about this on the tracker > (although I couldn't find it, maybe I used bad keywords)... > > But this limitation is really annoying and *absolutely not > user-friendly* (not understandable from a user point of view). > > Sorry for this nonconstructive post. -- Dmytro O. Redchuk Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond's internal pitch representation and microtonal notation
On 20 Sep 2010, at 00:50, Joseph Wakeling wrote: Hence why I say that the issue of effective microtonal support still requires action at the code level, and is not simply a matter of better documentation ... :-( I made a post about this issue last week, but there were no responses. http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00138.html ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond's internal pitch representation and microtonal notation
Hello all, This email is an attempt to clarify some outstanding issues regarding support for microtonal notation in Lilypond. It's being written in response to recent discussion with Graham Percival on Lilypond Issue 694: http://code.google.com/p/lilypond/issues/detail?id=694 To begin with, let's review how Lilypond represents pitch. A pitch is represented by a triple of numbers (octave, note, alteration) where "octave" is an integer, "note" is an integer in the range 0 to 6 (corresponding to note names C D E F G A B) and "alteration" is a continuous-valued variable whose unit is the whole tone. With these three values Lilypond is able to represent any pitch in a continuous frequency spectrum. >From a notational perspective, the first two numbers are used to calculate the vertical staff position of the notehead, while the value of the alteration is used to determine the accidental: e.g. (1,1,-1/2) corresponds to the D-flat a semitone above middle C. *A key assumption of this approach is that there is a one-to-one correspondence between accidental and alteration value.* This clearly holds for conventional Western 12-tone notation. However, it does _not_ hold for many _microtonal_ notations. For example, if we are using the very common 'arrow' notation for quarter-tones, there are two distinct accidentals that can be used to represent the alteration +1/4 (i.e. quarter-tone-sharp): the first is a natural sign with an up arrow, the second is a sharp sign with a down arrow. There is currently no effective, well-defined way to indicate which of the two is desired at any given moment. The arrow quarter-tone notation is just one of a whole variety of microtonal notations which operate not on the basis of single symbols per alteration, but on the basis of asuperposition of a successive hierarchy of symbols, each corresponding to smaller and smaller shadings up or down of the pitch. For example: sharp/flat + up/down arrow + plus/minus +/- 1/2 +/- 1/4 +/- 1/8 Lilypond's consideration of pitch alteration as a single number makes it very difficult to adequately represent such hierarchical pitch-alterations, and hence their corresponding notations. Hence why I say that the issue of effective microtonal support still requires action at the code level, and is not simply a matter of better documentation ... :-( Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
